理解mysql 数据库覆盖索引
2017-07-13 19:59
323 查看
话说有这么一个表:
看AUTO_INCREMENT就知道数据并不多,75万条。然后是一条简单的查询:
很简单对不对?怪异的地方在于:
如果换成MyISAM做存储引擎的时候,查询耗时只需要0.01s,用InnoDB却会是0.15s左右
如果只是就这么点差距其实不是什么大不了的事,但是真实的业务需求比这个复杂,造成的差距也很大:MyISAM只需要0.12s,InnoDB则需要2.2s.,最终定位到问题症结是在这条SQL。
Explain的结果是:
看起来已经用上索引了,而这条SQL语句已经简单到让我无法再优化了。最后请前同事Gaston诊断了一下,他认为:数据分布上,group_id相同的比较多,uid散列的比较均匀,加索引的效果一般,但是还是建议我试着加了一个多列索引:
然后,不可思议的事情发生了……这句SQL查询的性能发生了巨大的提升,居然已经可以跑到0.00s左右了。经过优化的SQL再结合真实的业务需求,也从之前2.2s下降到0.05s。
再Explain一次:
原来是这种叫覆盖索引(covering index),MySQL只需要通过索引就可以返回查询所需要的数据,而不必在查到索引之后再去查询数据,所以那是相当的快!!但是同时也要求所查询的字段必须被索引所覆盖到,在Explain的时候,输出的Extra信息中如果有“Using Index”,就表示这条查询使用了覆盖索引。
原文出处:http://xiaobin.net/201109/strange-sql-performance-problem/
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”,就表示这条查询使用了覆盖索引。
原文出处:http://xiaobin.net/201109/strange-sql-performance-problem/
相关文章推荐
- sql优化之:数据库索引创建原则,or/in/union与索引优化,聚集索引/非聚集索引/联合索引/索引覆盖,MySQL冗余数据的三种方案,MySQL双主一致性架构优化(来源:架构师之路)
- 数据库_MySQL_由浅入深理解索引的实现
- 数据库索引原理理解
- MySQL里建立索引应该考虑数据库引擎的类型
- [转]快速理解数据库中的索引(Indexes in Database)
- 数据库管理进阶,MySQL索引分析和优化
- 理解MySQL数据类型 避免数据库设计出现混乱
- MySQL里建立索引应该考虑数据库引擎的类型
- 来全面认识与理解MySQL的索引类型
- mysql查看数据库大小,索引大小
- 理解MySQL数据类型 避免数据库设计出现混乱
- MySQL 联合索引与Where子句的优化 提高数据库运行效率
- 理解MySQL数据类型 避免数据库设计出现混乱
- 理解MySQL——索引与优化
- 理解MySQL——索引与优化
- 理解MySQL的索引与优化
- 理解MySQL数据类型 避免数据库设计出现混乱
- 理解MySQL——索引与优化
- MySQL笔记(覆盖索引)
- MySQL 联合索引与Where子句的优化 提高数据库运行效率