首页
登录 | 注册

覆盖索引

一次神奇的MySQL优化

话说有这么一个表:

CREATE TABLE `user_group` ( `id` int(11) NOT NULL auto_increment, `uid` int(11) NOT NULL, `group_id` int(11) NOT NULL, PRIMARY KEY (`id`), KEY `uid` (`uid`), KEY `group_id` (`group_id`), ) ENGINE=InnoDB AUTO_INCREMENT=750366 DEFAULT CHARSET=utf8

看AUTO_INCREMENT就知道数据并不多,75万条。然后是一条简单的查询:

SELECT SQL_NO_CACHE uid FROM user_group WHERE group_id = 245;

很简单对不对?怪异的地方在于:

  • 如果换成MyISAM做存储引擎的时候,查询耗时只需要0.01s,用InnoDB却会是0.15s左右

如果只是就这么点差距其实不是什么大不了的事,但是真实的业务需求比这个复杂,造成的差距也很大:MyISAM只需要0.12s,InnoDB则需要2.2s.,最终定位到问题症结是在这条SQL。

Explain的结果是:

+----+-------------+------------+------+---------------+----------+---------+-------+------+-------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+-------------+------------+------+---------------+----------+---------+-------+------+-------+ | 1 | SIMPLE | user_group | ref | group_id | group_id | 4 | const | 5544 | | +----+-------------+------------+------+---------------+----------+---------+-------+------+-------+

看起来已经用上索引了,而这条SQL语句已经简单到让我无法再优化了。最后请前同事Gaston诊断了一下,他认为:数据分布上,group_id相同的比较多,uid散列的比较均匀,加索引的效果一般,但是还是建议我试着加了一个多列索引:

ALTER TABLE user_group ADD INDEX group_id_uid (group_id, uid);

然后,不可思议的事情发生了……这句SQL查询的性能发生了巨大的提升,居然已经可以跑到0.00s左右了。经过优化的SQL再结合真实的业务需求,也从之前2.2s下降到0.05s。

再Explain一次:

+----+-------------+------------+------+-----------------------+--------------+---------+-------+------+-------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+-------------+------------+------+-----------------------+--------------+---------+-------+------+-------------+ | 1 | SIMPLE | user_group | ref | group_id,group_id_uid | group_id_uid | 4 | const | 5378 | Using index | +----+-------------+------------+------+-----------------------+--------------+---------+-------+------+-------------+

原来是这种叫覆盖索引(covering index),MySQL只需要通过索引就可以返回查询所需要的数据,而不必在查到索引之后再去查询数 据,所以那是相当的快!!但是同时也要求所查询的字段必须被索引所覆盖到,在Explain的时候,输出的Extra信息中如果有“Using Index”,就表示这条查询使用了覆盖索引。

不过,还有一个无法解释的问题就是,不用覆盖索引的情况下,为什么用MyISAM就快那么多,而InnoDB就慢这么多呢?求真相……

转自:http://xiaobin.net/201109/strange-sql-performance-problem/


相关文章

  • 博客文章除注明转载外,均为原创.转载请注明出处. 本文链接地址: Oracle普通索引是一种B树结构,在数据查询方面有很高的效率.但是有些时候需要重建索引. 1.什么时候需要重建索引 (1)索引失效,比如ORA-01502错误; (2)索引 ...
  • 创建一个测试文件夹 您的计算机 C 驱动器上创建一个新的文件夹.命名文件夹 myCatalogFolder. 启动文本编辑器 (如记事本),然后在一个空白文档中粘贴以下文本: 这是测试索引服务器查询测试文档,此文件的名称是 IndexTex ...
  • //java版 class A {      public static int i =10;      public void show()      {      System.out.printf("%d\n",t ...
  • 上面说过,经过分析得出百度的分词系统采用双向最大匹配分词,但是后来发现推理过程中存在一个漏洞,而且推导出来的百度分词算法步骤还是过于繁琐,所以进一步进行分析,看看是否前面的推导有错误. 那么以前的分析有什么漏洞呢?我们推导百度分词有反向最大 ...
  • Spider引擎分布式数据库解决方案(最全的spider教程)
    最近开始负责财付通的数据库的相关维护工作,其中有几套系统使用的spider引擎,为了以后能更好地对这套系统进行维护,对spider做了一些功课,将spider引擎的功能.使用场景.部署.实战测试等做个简单的总结,希望不了解spider引擎的 ...
  • 综述 UBI全称Unsorted Block Images,是一种原始flash设备的卷管理系统.这个系统能在一个物理的flash设备上管理操纵多个卷并且能在整个flash芯片上实现损耗均衡. 从某种意义上说,UBI和LVM有点相似,LVM ...

2019 unjeep.com webmaster#unjeep.com
12 q. 0.012 s.
京ICP备10005923号