当前位置: 首页 > 面试题库 >

避免使用INNER JOIN + ORDER BY进行文件排序

袁旻
2023-03-14
问题内容

我一直在阅读其他文章,但没有设法解决我的查询。

使用DESC顺序查询要慢20倍,我必须改进它。这是查询:

SELECT posts.post_id, posts.post_b_id, posts.post_title, posts.post_cont, posts.thumb, posts.post_user, boards.board_title_l, boards.board_title
FROM posts
INNER JOIN follow ON posts.post_b_id = follow.board_id
INNER JOIN boards ON posts.post_b_id = boards.board_id
WHERE follow.user_id =1
ORDER BY posts.post_id DESC 
LIMIT 10

这些是表(已更新):

CREATE TABLE IF NOT EXISTS `posts` (
`post_id` int(11) NOT NULL AUTO_INCREMENT,
`post_b_id` int(11) unsigned NOT NULL,
`post_title` varchar(50) COLLATE utf8_bin NOT NULL,
`post_cont` text COLLATE utf8_bin NOT NULL,
`post_mintxt` varchar(255) COLLATE utf8_bin NOT NULL,
`post_type` char(3) COLLATE utf8_bin NOT NULL,
`thumb` varchar(200) COLLATE utf8_bin NOT NULL,
`post_user` varchar(16) COLLATE utf8_bin NOT NULL,
`published` enum('0','1') COLLATE utf8_bin NOT NULL,
`post_ip` varchar(94) COLLATE utf8_bin NOT NULL,
`post_ip_dat` int(11) unsigned NOT NULL,
`post_up` int(10) unsigned NOT NULL DEFAULT '0',
`post_down` int(10) unsigned NOT NULL DEFAULT '0',
 PRIMARY KEY (`post_id`),
 KEY `post_b_id` (`post_b_id`)
) ENGINE=InnoDB  DEFAULT CHARSET=utf8 COLLATE=utf8_bin AUTO_INCREMENT=405 ;

CREATE TABLE IF NOT EXISTS `boards` (
`board_id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`board_title_l` varchar(19) COLLATE utf8_bin NOT NULL,
`board_user_id` int(10) unsigned NOT NULL,
`board_title` varchar(19) COLLATE utf8_bin NOT NULL,
`board_user` varchar(16) COLLATE utf8_bin NOT NULL,
`board_txt` tinyint(1) unsigned NOT NULL,
`board_img` tinyint(1) unsigned NOT NULL,
`board_vid` tinyint(1) unsigned NOT NULL,
`board_desc` varchar(100) COLLATE utf8_bin NOT NULL,
`board_mod_p` tinyint(3) unsigned NOT NULL DEFAULT '0',
`board_ip` varchar(94) COLLATE utf8_bin NOT NULL,
`board_dat_ip` int(11) unsigned NOT NULL,
 PRIMARY KEY (`board_id`),
 UNIQUE KEY `board_title_l` (`board_title_l`),
 KEY `board_user_id` (`board_user_id`)
) ENGINE=InnoDB  DEFAULT CHARSET=utf8 COLLATE=utf8_bin AUTO_INCREMENT=89 ;

CREATE TABLE IF NOT EXISTS `follow` (
`user_id` int(10) unsigned NOT NULL,
`board_id` int(10) unsigned NOT NULL,
 PRIMARY KEY (`user_id`,`board_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin;

使用默认ASC顺序时,它仅使用 index和where ,并DESC使用
index,where,temporary和filesort。

id  select_type table   type    possible_keys   key         key_len  ref                rows    filtered    Extra   
 1  SIMPLE      follow  ref     user_id         user_id     4        const              2       100.00      Using index; Using temporary; Using filesort
 1  SIMPLE      boards  eq_ref  PRIMARY         PRIMARY     4   xxxx.follow.board_id    1       100.00  
 1  SIMPLE      posts   ref     post_b_id       post_b_id   4   xxxx.boards.board_id    3       100.00      Using where

如何使查询按DESC顺序接收结果,而无需文件排序和临时排序。

更新: 我进行了一个新的查询,没有临时或文件排序,但 类型:索引
,已筛选:7340.00。ASC如果帖子位于表的末尾,则几乎与顺序一样快,但是如果要搜索的帖子位于表的开头,则慢于顺序。因此看起来更好,但这还不够。

SELECT posts.post_id, posts.post_b_id, posts.post_title, posts.post_cont, posts.thumb, posts.post_user, boards.board_title_l, boards.board_title 
FROM posts INNER JOIN boards ON posts.post_b_id = boards.board_id
WHERE posts.post_b_id
IN (
 SELECT follow.board_id
 FROM follow
 WHERE follow.user_id = 1
)
ORDER BY posts.post_id DESC 
LIMIT 10

解释:

id  select_type        table    type    possible_keys   key        key_len   ref                rows    filtered    Extra   
 1  PRIMARY            posts    index   post_b_id       PRIMARY        8     NULL                10     7340.00    Using where
 1  PRIMARY            boards   eq_ref  PRIMARY         PRIMARY        4    xxxx.posts.post_b_id 1      100.00  
 2  DEPENDENT SUBQUERY  follow  eq_ref  user_id         user_id        8     const,func          1      100.00     Using index

更新: 解释来自dened答案的查询:

id  select_type table   type    possible_keys    key       key_len  ref              rows   filtered    Extra   
1   PRIMARY     <derived2>ALL   NULL             NULL      NULL     NULL             10     100.00  
1   PRIMARY     posts   eq_ref  PRIMARY,post_b_id PRIMARY  4        sq.post_id       1      100.00      
1   PRIMARY     boards  eq_ref  PRIMARY          PRIMARY   4    xxxx.posts.post_b_id 1      100.00  
2   DERIVED     follow  ref     PRIMARY          PRIMARY   4                         1      100.00      Using index; Using temporary; Using filesort
2   DERIVED     posts   ref     post_b_id        post_b_id 4    xxxx.follow.board_id 6      100.00      Using index

时间:

Original query no order (ASC):              0.187500 seconds
Original query DESC:                        2.812500 seconds
Second query posts at the end (DESC):       0.218750 seconds
Second query posts at the beginning (DESC): 3.293750 seconds
dened's query DESC:                         0.421875 seconds 
dened's query no order (ASC):               0.323750 seconds

有趣的是,如果我添加ORDER BY ASC的速度与一样慢DESC

更改表的顺序将是一个很不错的方法,但是正如我在评论中说的那样,我无法做到这一点。


问题答案:

您可以通过将所有过滤工作移到仅访问索引的子查询(处理索引通常比处理其他数据快得多),并在最外层的查询中获取其余数据来帮助MySQL优化器:

SELECT posts.post_id,
       posts.post_b_id,
       posts.post_title,
       posts.post_cont,
       posts.thumb,
       posts.post_user,
       boards.board_title_l,
       boards.board_title
FROM   (SELECT post_id
        FROM   posts
               JOIN follow
                 ON posts.post_b_id = follow.board_id
        WHERE  follow.user_id = 1
        ORDER  BY post_id DESC
        LIMIT  10) sq
       JOIN posts
         ON posts.post_id = sq.post_id
       JOIN boards
         ON boards.board_id = posts.post_b_id

请注意,我ORDER BY posts.post_idDESC从外部查询中省略了,因为在代码中对最终结果进行排序通常比使用MySQL查询进行排序要快(MySQL通常使用 filesort 进行排序)。

PS您可以用follow主键替换表中的唯一键。



 类似资料:
  • 问题内容: 我目前使用Zend_Db来管理查询。我已经编写了执行以下查询的代码: 假设Zend_Db可以,我在不清理输入的情况下完成了此操作。Zend会这样做吗? 另一个问题:Zend_Db是否清除并查询? 谢谢。 问题答案: 当我是该项目的团队负责人(直到1.0版)时,我在Zend Framework中编写了很多用于数据库参数和引用的代码。 我尽力鼓励最佳做法,但必须在易用性之间取得平衡。 请注

  • 问题内容: 我目前正在开发一种微分运算符,可以将其以矩阵形式放置。在这种情况下,创建对象时列表的顺序非常重要,以确保仅在需要时才执行区分。 问题是,完成以下操作后: 之所以返回,是因为进行了一些重排。如何避免被排序? 问题答案: 为什么arg的顺序对正确来说很重要? 防止这种情况的唯一方法是将符号设置为不可交换的()。SymPy对象通过比较进行比较,因此要正常工作,必须对args进行规范排序。有一

  • 我在<code>java.text.RuleBasedCollator中遇到线程阻塞问题。getCollationKey()当我的服务器负载过重时。 下面是出现问题的类: 下面是来自线程转储的一个片段,显示了有问题的阻塞: " xxxhttp 227 " prio = 5 tid = 0x 355 NID = 0x 163 BLOCKED归hybrishttp 109 Id = 236-stats

  • componentWillMount() 在组件将要挂载时被立即调用. 这个调用发生在render()函数执行之前, 所以如果在componentWillMount里面设置了state, 这个设置的state是不会触发重新渲染的. 同样我们也需要注意不要在componentWillMount()中引入其他可能会导致问题的代码. 如果你有类似的需求, 请在componentDidMount里面完成.

  • 问题内容: 如何避免使用HttpClient 4.1.1进行循环重定向。当我得到这样的错误:- 这是我的代码… 问题答案: 您可以将ClientPNames.ALLOW_CIRCULAR_REDIRECTS设置为true,这将允许重定向到同一位置。 在这里查看更多信息

  • 问题内容: 我有这样的代码: 实例化B可以按预期工作,但是实例化C无限递归并导致堆栈溢出。我该如何解决? 问题答案: 实例化C调用时,仍然是C,因此super()调用将其带回B。 调用super()时,请直接使用类名。因此,在B中,请致电,而不是(最好在C中使用)。在Python 3中,您可以仅使用不带参数的super()来实现同一目的