再来吐槽一个关于 MySQL 的索引合并问题

红薯 发布于 2012/11/20 15:16
阅读 2K+
收藏 5

osc_answers 表的索引如下:

现在执行一个非常简单的查询语句:

SELECT COUNT(id) FROM osc_answers WHERE question = 78473 AND parent = 0

这个 SQL 语句居然要 100 多毫秒,EXPLAIN 看看居然是:

Using intersect(idx_answer_question,idx_answer_parent); Using where; Using index

这 MySQL 有点自作主张了吧??

关闭优化器开关:

SET optimizer_switch = 'index_merge_intersection=off'
再次执行上述 SQL 后,只需要几毫秒甚至是0,而 EXPLAIN 信息只有:

Using where

还有奇怪的问题是,本地和服务器上表结构和索引都一样的,本地就不会出现这种情况。

另外上述关闭优化器开关仅限于当前连接,如何永久关闭,关闭后会不会有其他影响?

加载中
0
我是尤里

四个列上都做索引是不太好的设计啊,

“直接添加 question 和 parent 的复合索引”, 只能针对 WHERE question = 78473 AND parent = 0 这种情况

我猜测是不是你的parent重复太多了(cardinality),这样使用了索引反而效率不高,因为大量的重复索引还得做一些额外的工作,针对你的查询我想是不是只在question 上建立一个索引就够了,你可以自己测试一下


你给出的http://stackoverflow.com/questions/4526686/why-mysql-would-use-index-intersection-instead-of-combined-index 当中也有人回答了这一点

0
红薯
红薯
刚做了索引的调整,直接添加 question 和 parent 的复合索引,删除 question 和 parent 单独的索引
0
loki_lan
loki_lan

原来是这个问题。

返回顶部
顶部