共计 1133 个字符，预计需要花费 3 分钟才能阅读完成。

这期内容当中丸趣 TV 小编将会给大家带来有关为什么 MySQL 偶尔会选错索引，文章内容丰富且以专业的角度为大家分析和叙述，阅读完这篇文章希望大家可以有所收获。

在此之前，我做过不少 ToC 的项目，在 ToC 的应用场景中，业务一般都是比较简单，基本上没有多少复杂的查询 (基本上，只要建立用户 ID 为索引，就能够大大提升查询效率了。) 这两年，也逐渐接触到一些 ToB 的业务，发现 ToB 的业务，真的是比 ToC 的要复杂一些。举个简单的例子，ToB 应用中，最痛苦的事情就是组织架构，原本查询一个人的数据，可能变成查询一个小组，一个部门，甚至是一个分公司的数据。

不仅如此，由于不同职级的员工的查询权限可能不一样。查询条件比 ToC 场景中复杂得多，所以有时候一张表，会建立好多个不同的索引。后时候我们就会发现，怎么查询莫名其妙就变得很慢了。按道理说，如果命中了我们想要的索引，应该很快才对。

于是，我们就对 Sql 语句进行分析，发现 Mysql 使用的是另外一个索引，但是在这个业务下，使用另外一个索引会得到更好的结果，为什么 Mysql 会选错索引呢? 很显然，存储很难会去理解业务的实际情况，Mysql 也需要一定的算法才能评估出索引的优劣，Mysql 是这样进行评分的。

Mysql 对索引的评分的首要原则，就是索引的差异度最大，举个例子，假如是一个小学生信息查询系统，我们以出生日期建立索引，那么大概就有 365* 7 个不同的值，假如我们以学生的性别作为索引，那么基本上就只有 2 个不同的值了，假如一个查询条件同时包含出生日期跟性别，那么 Mysql 必然优先选基数更大的作为索引，也就是出生日期作为索引。

那但是，Mysql 实际上并不理解什么是出生日期，什么是性别，他们是判断哪一个基数更大的呢? 非常简单，把索引扫一遍不就知道结果了么? 我们只要在索引树上扫一遍，就能够知道不同的 Key 有多少个。但是，假如我们的数据越来越多，每次都把所有的索引树都扫描一遍并不现实。基于大多数的互联网应用都是读多写少的，Mysql 会把索引的评分记录一段时间，但是，每次触发重新评估的时候，仍要花费不少的时间。

Mysql 采用抽样调查的方式，随机从各个索引树上面取一定的页数，通过统计这些页数对索引进行评估。现在回到我们现实的开发中，不知道你有没有遇到过这样的问题，一些异常状态占总数量非常少，例如退货退款的订单只占总订单的少数，但是你使用 Mysql 查询的时候却很命中这个索引。就是因为在 Mysql 评估分数的时候，大多数时候都会觉得这个索引上面不同数据量很少，所以打了低分。

上述就是丸趣 TV 小编为大家分享的为什么 MySQL 偶尔会选错索引了，如果刚好有类似的疑惑，不妨参照上述分析进行理解。如果想知道更多相关知识，欢迎关注丸趣 TV 行业资讯频道。