mysql添加索引后在查询的时候是mysql自动从索引里面查询还是查询的时候有单独的参数查询索引？

MYSQL在创建索引后对索引的使用方式分为两种：\x0d\x0a1 由数据库的查询优化器自动判断是否使用索引；\x0d\x0a2 用户可在写SQL语句时强制使用索引\x0d\x0a\x0d\x0a下面就两种索引使用方式进行说明\x0d\x0a第一种，自动使用索引。数据库在收到查询语句后会查看where语句后面的查询条件，同时查看在表上面有哪些索引，然后根据查询条件和索引进行匹配。\x0d\x0a查询条件和索引的匹配包括查询字段与索引字段的匹配和查询类型和索引类型的匹配。前者很好理解，就是查询条件的属性上要建有索引，后者则是说查询条件必须能够使用索引，比如等值判断和范围查询可以使用B+树索引，而hash索引只能适用于等值判断。\x0d\x0a在找到与查询条件匹配的索引后，就是进行代价估计来决定是否使用索引，代价估计主要根据要访问的就数量，一般来说如果通过索引访问的记录数量占全表记录数量15%以上，则不会使用索引而是使用全表扫描，因为此时使用索引的代价更大。在大多数情况下使用索引是会提高效率的。\x0d\x0a经过优化器的判断，最终会决定是否使用索引\x0d\x0a \x0d\x0a第二种，强制使用索引，主要是通过SQL语句实现的\x0d\x0aselect * from table force index(PRI) limit 2(强制使用主键)\x0d\x0aselect * from table force index(ziduan1_index) limit 2(强制使用索引"ziduan1_index")\x0d\x0aselect * from table force index(PRI,ziduan1_index) limit 2(强制使用索引"PRI和ziduan1_index")\x0d\x0a也可以禁止索引的使用\x0d\x0aselect * from table ignore index(PRI) limit 2(禁止使用主键)\x0d\x0aselect * from table ignore index(ziduan1_index) limit 2(禁止使用索引"ziduan1_index")\x0d\x0aselect * from table ignore index(PRI,ziduan1_index) limit 2(禁止使用索引"PRI,ziduan1_index")

前言

案例取自极客时间《mysql45讲》

案例

模拟执行器分析查询语句

场景复现

奇了怪了，此时没用索引，进行了全表扫描

虽然使用了索引，但是还是扫描了37116行，不妨结合之前的知识分析一下：

1.另一个事务未提交，需要保存之前的数据的数据版本，因此delete10万行数据实际是标记数据，这样每一行数据就有两个数据版本，旧的是delete之前的，新的是标记为delete的，索引a上的数据有两份

2.那还多出来的1万7呢，之前介绍过索引树的叶子节点存的是主键，select * 还要进行回表查询，这里将回表的扫描行数一并算上

为什么会选错索引

选择索引是优化器的工作，优化器要找到最优的执行方案并选择最小的代价去执行，扫描行数是影响执行代价之一（扫描越小，访问磁盘次数越少，消耗CPU资源越少）

mysql执行语句之前需要通过根据信息来统计记录数

这个统计信息就是索引的区分度，即索引上不同的值越多，区分度越高越好（show index t 的 cardinality字段查看），索引的区分度是利用采样统计得到的即取小部分统计信息再乘以整体。

除了使用统计信息，还会计算回表代价(主键不需要回表)

如果是统计信息不对那就修正

另一种场景复现

按理说这是个空集，利用索引a只扫描1000行，利用索引b要扫描50000行，这里优化器竟然选择了索引b！！

mysql又选错了索引

解决办法

2.引导使用a索引

我们知道索引树上的数据是有序的，优化器使用b索引，一方面是认为索引b可以避免排序 ,order by a,b强制按照a,b排序意味着两个都需要排序，因此扫描行数成了影响决策的主要条件

3.删掉索引b

解决mysql选错索引主要有两大方向

1.强制指定索引

2.干涉优化器选择（比如增大limit数量，增加order by ，写成子查询）

MySQL选错索引导致的线上慢查询事故

mysql中走与不走索引的情况汇集(待全量实验)

---