我一直在阅读其他文章,但没有设法解决我的查询。
使用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()来实现同一目的