PS:原创文章,如需转载,请注明出处,谢谢!
本文地址:http://flyer0126.iteye.com/blog/2410145
最近开发中需查询系统id,随手写了两条sql,发现查询结构不同。
select * from apps limit 1;
id | city_code | short_name | company_code |
1 | 410100 | zz | ZZXJ8888 |
select id from apps limit 1;
id |
2 |
最终发现,两次查询结果竟然不一致!
为了一探究竟,查阅一下表数据及相关索引如下:
id | city_code | short_name | company_code |
1 | 410100 | zz | ZZXJ8888 |
2 | 410100 | zz | HNFG6666 |
索引如下:
那来看看MySQL本身是如何解释的:
explain select * from apps limit 1;
explain select id from apps limit 1;
由此可见,第一条没有用到索引,按主键排序取到了第一条;第二条用到了uniq_company_code索引,按索引排序,取到了第二条。
总结一下:根据select的字段不同,MySQL选取的策略不同,导致查询结果不同。
但是存在几个疑问点
1、为什么语句2中并没有出现company_code字段,却会使用其索引(uniq_company_code)? 2、为什么语句1中就不会使用uniq_company_code索引?
回答以上问题之前,先了解一下MySQL常用表引擎索引的实现方式
示例表如下:
id | company_code | city_code | ... |
10 | ZZXJ8888 | 410100 | ... |
21 | HNFD6666 | 410100 | ... |
32 | WH9999 | 420100 | ... |
43 | CS9999 | 430100 | ... |
不同表引擎索引的实现:
至此,以上问题有了定论
1、因为uniq_company_code索引中包含id字段,语句2可以从uniq_company_code索引中直接取得数据,所以优化器选择走uniq_company_code索引; 2、而语句1中select * 选取了在uniq_company_code索引中不包含的列,所以无法使用uniq_company_code这个索引。
为了验证上面的结论,进一步实验:
explain select id, company_name from apps limit 1;
至此,验证了索引覆盖问题(company_name不在uniq_company_code索引覆盖范围内,无法使用其索引)。
那么,为什么要使用索引覆盖呢?MySQL是如下这么解释的。
It is possible that key will name an index that is not present in the possible_keys value. This can happen if none of the possible_keys indexes are suitable for looking up rows, but all the columns selected by the query are columns of some other index. That is, the named index covers the selected columns, so although it is not used to determine which rows to retrieve, an index scan is more efficient than a data row scan.主要就是:假如索引覆盖覆盖了所选取的字段,会优先使用索引覆盖,因为效率更快。
相关推荐
第十部-老男孩MySQL常用引擎及优缺点-应用场景-调优详解(14节) 01-MySQL服务存储引擎介绍 02-MySQL服务存储引擎体系结构 03-MySQL服务MyISAM引擎介绍及磁盘文件格式 04-MySQL服务事务详细介绍及ACID特性说明 05-...
MySQL遇到的死锁问题、如何排查与解决 索引类别(B+树索引、全文索引、哈希索引)、索引的原理 什么是自适应哈希索引(AHI) 遇到过索引失效的情况没,什么时候可能会出现,如何解决 如何选择合适的分布式主键方案 ...
在小伙伴们开发的项目中,对于MySQL排查问题找出性能瓶颈来说,最容易发现并解决的问题就是MYSQL的慢查询以及没有得用索引的查询。 接下来教大家如何开启MySQL5.0版本以上的慢查询日志记录; OK,一起开始找出mysql...
MySQL拥有庞大的开发者社区和丰富的第三方插件、库、中间件支持,提供了丰富的文档、教程、论坛以及专业服务,极大地简化了开发、运维和故障排查过程。 关键组件与日志 系统数据库 MySQL内部包含几个特殊的系统...
文章目录推荐阅读索引建立选择适合建立索引不适合建立索引索引失效原因使用索引注意索引不能使用排查不会用到索引 推荐阅读 MySql性能优化之JOIN连接(有图,最全,最详细) 数据库索引(Index)实现原理,面试官常问~...
最近在做zabbix的数据库MySQL5.6升级5.7时,出现主从延迟问题,这个问题困扰了很久没有解决,昨天终于解决了,整理了一下整个排查过程,分享给大家。 环境说明: mysql主库为5.6的版本,有四个从库,三个为5.6的...
资源包括:1、mysql的架构介绍;2、索引优化分析;3、查询优化分析;4、mysql锁机制;...以及如何建立高效的索引、索引在哪些情况下会失效、生产环璋下,如果进行sql问题排查及优化。属于非常干货的内容。
MySQL拥有庞大的开发者社区和丰富的第三方插件、库、中间件支持,提供了丰富的文档、教程、论坛以及专业服务,极大地简化了开发、运维和故障排查过程。 关键组件与日志 系统数据库 MySQL内部包含几个特殊的系统...
MySQL拥有庞大的开发者社区和丰富的第三方插件、库、中间件支持,提供了丰富的文档、教程、论坛以及专业服务,极大地简化了开发、运维和故障排查过程。 关键组件与日志 系统数据库 MySQL内部包含几个特殊的系统...
MySQL拥有庞大的开发者社区和丰富的第三方插件、库、中间件支持,提供了丰富的文档、教程、论坛以及专业服务,极大地简化了开发、运维和故障排查过程。 关键组件与日志 系统数据库 MySQL内部包含几个特殊的系统...
MySQL拥有庞大的开发者社区和丰富的第三方插件、库、中间件支持,提供了丰富的文档、教程、论坛以及专业服务,极大地简化了开发、运维和故障排查过程。 关键组件与日志 系统数据库 MySQL内部包含几个特殊的系统...
5、如何排查因为MySQL导致CPU占用高的问题? 6、MySQL数据库磁盘IO使用高,请问如何进行排查? 7、如何批量插入大量数据? 8、数据备份和恢复 1、如何更新给一个大表建索引 出现概率: ★★★★ 这个问题考察的点: ...
MySQL拥有庞大的开发者社区和丰富的第三方插件、库、中间件支持,提供了丰富的文档、教程、论坛以及专业服务,极大地简化了开发、运维和故障排查过程。 关键组件与日志 系统数据库 MySQL内部包含几个特殊的系统...
MySQL拥有庞大的开发者社区和丰富的第三方插件、库、中间件支持,提供了丰富的文档、教程、论坛以及专业服务,极大地简化了开发、运维和故障排查过程。 关键组件与日志 系统数据库 MySQL内部包含几个特殊的系统...
MySQL拥有庞大的开发者社区和丰富的第三方插件、库、中间件支持,提供了丰富的文档、教程、论坛以及专业服务,极大地简化了开发、运维和故障排查过程。 关键组件与日志 系统数据库 MySQL内部包含几个特殊的系统...
MySQL拥有庞大的开发者社区和丰富的第三方插件、库、中间件支持,提供了丰富的文档、教程、论坛以及专业服务,极大地简化了开发、运维和故障排查过程。 关键组件与日志 系统数据库 MySQL内部包含几个特殊的系统...
MySQL拥有庞大的开发者社区和丰富的第三方插件、库、中间件支持,提供了丰富的文档、教程、论坛以及专业服务,极大地简化了开发、运维和故障排查过程。 关键组件与日志 系统数据库 MySQL内部包含几个特殊的系统...
MySQL拥有庞大的开发者社区和丰富的第三方插件、库、中间件支持,提供了丰富的文档、教程、论坛以及专业服务,极大地简化了开发、运维和故障排查过程。 关键组件与日志 系统数据库 MySQL内部包含几个特殊的系统...
MySQL拥有庞大的开发者社区和丰富的第三方插件、库、中间件支持,提供了丰富的文档、教程、论坛以及专业服务,极大地简化了开发、运维和故障排查过程。 关键组件与日志 系统数据库 MySQL内部包含几个特殊的系统...
MySQL拥有庞大的开发者社区和丰富的第三方插件、库、中间件支持,提供了丰富的文档、教程、论坛以及专业服务,极大地简化了开发、运维和故障排查过程。 关键组件与日志 系统数据库 MySQL内部包含几个特殊的系统...