MYSQL-如何正确使用索引

索引最左前缀匹配
如何正确使用索引及索引的原因

索引的数据结构

每次查找数据时把磁盘IO次数控制在一个很小的数量级，最好是常数数量级。那么我们就想到如果一个高度可控的多路搜索树是否能满足需求呢？就这样，b+树应运而生（B+树是通过二叉查找树，再由平衡二叉树，B树演化而来）。

如上图，是一颗b+树，关于b+树的定义可以参见B+树，这里只说一些重点，浅蓝色的块我们称之为一个磁盘块，可以看到每个磁盘块包含几个数据项（深蓝色所示）和指针（黄色所示），如磁盘块1包含数据项17和35，包含指针P1、P2、P3，P1表示小于17的磁盘块，P2表示在17和35之间的磁盘块，P3表示大于35的磁盘块。真实的数据存在于叶子节点即3、5、9、10、13、15、28、29、36、60、75、79、90、99。非叶子节点只不存储真实的数据，只存储指引搜索方向的数据项，如17、35并不真实存在于数据表中。

b+树的查找过程

如图所示，如果要查找数据项29，那么首先会把磁盘块1由磁盘加载到内存，此时发生一次IO，在内存中用二分查找确定29在17和35之间，锁定磁盘块1的P2指针，内存时间因为非常短（相比磁盘的IO）可以忽略不计，通过磁盘块1的P2指针的磁盘地址把磁盘块3由磁盘加载到内存，发生第二次IO，29在26和30之间，锁定磁盘块3的P2指针，通过指针加载磁盘块8到内存，发生第三次IO，同时内存中做二分查找找到29，结束查询，总计三次IO。真实的情况是，3层的b+树可以表示上百万的数据，如果上百万的数据查找只需要三次IO，性能提高将是巨大的，如果没有索引，每个数据项都要发生一次IO，那么总共需要百万次的IO，显然成本非常非常高。

b+树性质

1.索引字段要尽量的小：通过上面的分析，我们知道IO次数取决于b+数的高度h，假设当前数据表的数据为N，每个磁盘块的数据项的数量是m，则有h=㏒(m+1)N，当数据量N一定的情况下，m越大，h越小；而m = 磁盘块的大小 / 数据项的大小，磁盘块的大小也就是一个数据页的大小，是固定的，如果数据项占的空间越小，数据项的数量越多，树的高度越低。这就是为什么每个数据项，即索引字段要尽量的小，比如int占4字节，要比bigint8字节少一半。这也是为什么b+树要求把真实的数据放到叶子节点而不是内层节点，一旦放到内层节点，磁盘块的数据项会大幅度下降，导致树增高。当数据项等于1时将会退化成线性表。

索引的最左匹配特性

当b+树的数据项是复合的数据结构，比如(name,age,sex)的时候，b+数是按照从左到右的顺序来建立搜索树的，比如当(张三,20,F)这样的数据来检索的时候，b+树会优先比较name来确定下一步的所搜方向，如果name相同再依次比较age和sex，最后得到检索的数据；但当(20,F)这样的没有name的数据来的时候，b+树就不知道下一步该查哪个节点，因为建立搜索树的时候name就是第一个比较因子，必须要先根据name来搜索才能知道下一步去哪里查询。比如当(张三,F)这样的数据来检索时，b+树可以用name来指定搜索方向，但下一个字段age的缺失，所以只能把名字等于张三的数据都找到，然后再匹配性别是F的数据了， 这个是非常重要的性质，即索引的最左匹配特性。

---

举例

在 MySQL 中，当你使用分区表（Partitioned Table）并且有一个唯一索引定义为 UNIQUE KEY unique_key (content_id, task_id, partition_date) 时，查询的执行方式会受到分区键和索引的影响。

分区键 partition_date 决定了数据如何在物理上被分隔存储。当执行查询时，MySQL 首先会根据分区键的条件来确定需要搜索的分区。在你的例子中，查询条件包含 partition_date <= ?，MySQL 会识别出所有的分区，其 partition_date 小于或等于给定的值，并只在这些分区中查找数据。

接下来，MySQL 会在这些已经确定的分区中，根据查询条件使用索引来查找数据。由于你的查询条件中还包括 content_id in (...)，MySQL 将会使用 content_id 作为索引的一部分来查找数据。这是因为索引是按照 content_id, task_id, partition_date 的顺序创建的，所以 MySQL 会尝试使用最左前缀的原则进行索引查找，即先查找 content_id，然后是 task_id，最后是 partition_date。

然而，因为 task_id 没有在你的查询条件中被提及，所以索引可能不会完全按照最左匹配原则被利用。MySQL 会尽可能利用索引来加速查询，但如果没有提供完整的索引列，查询性能可能不会最优。

总结来说，查询的方式是：

1. 根据 partition_date 确定需要搜索的分区。
2. 在这些分区中，尽可能根据 content_id 和 task_id 使用索引进行数据查找。

为了确保查询效率，最好是查询条件中包含所有索引列的值，这样可以最大程度地利用索引进行快速查找。如果查询性能是关键考虑因素，可能需要根据实际查询模式调整索引策略。