最左前缀原则指MySQL联合索引需从最左列开始匹配，遇范围查询则停止使用后续索引列，其设计基于B+树结构，确保查询效率与索引维护成本的平衡。
最左前缀原则简单来说，就是MySQL利用联合索引进行查询时，会从索引的最左列开始匹配，直到遇到范围查询（>、
联合索引的生效就像叠积木，必须一块一块往上叠，如果中间断了，后面的就用不上了。
联合索引应用的核心在于理解索引的结构和查询条件如何与索引匹配。
为什么MySQL需要最左前缀原则？
想象一下，你要在一本电话簿里找人。电话簿是按照姓氏、名字、电话号码的顺序排列的。如果你只知道电话号码，你肯定没法用电话簿快速找到这个人，因为电话簿不是按照电话号码排序的。
联合索引也是一样。MySQL的B+树结构决定了联合索引的存储方式，它必须按照索引列的顺序进行排序。如果你的查询条件跳过了前面的列，MySQL就无法利用索引来加速查询。
这种设计并非缺陷，而是效率和空间利用的权衡。如果允许任意顺序的索引查找，那么索引的维护成本和空间占用将大大增加。
索引失效的常见场景有哪些？
- 跳过最左列： 比如索引是(a, b, c)，查询条件直接从b开始，那么索引就失效了。
- 中间断裂： 索引是(a, b, c)，查询条件是a和c，缺少b，c的部分索引失效。
- 范围查询： 索引是(a, b, c)，查询条件是a > 1 and b = 2 and c = 3，那么只有a能用到索引，b和c都无法使用。
-
函数操作： 在索引列上使用函数，比如
WHERE UPPER(a) = 'ABC'
，索引失效。 -
类型转换： 比如a是字符串类型，查询条件是
WHERE a = 123
，MySQL会进行类型转换，导致索引失效。 - OR条件： 除非OR连接的每个条件都用到了索引，否则索引失效。
需要注意的是，索引失效并不意味着查询一定慢。MySQL的查询优化器会评估各种执行计划，选择最优的方案。有时候，即使索引失效，全表扫描可能比使用索引更快。
如何设计高效的联合索引？
设计联合索引的关键在于考虑查询的频率和查询条件的顺序。
- 将最常用的列放在最左边： 这样可以最大程度地利用索引。
- 考虑列的选择性： 选择性高的列（即不同值的数量多）放在前面，可以更快地过滤数据。
- 避免过度索引： 索引越多，维护成本越高。只创建必要的索引。
举个例子，假设你的表有一个用户表，有
user_id、
username、
username和
(username, email)。
CREATE INDEX idx_username_email ON users (username, email);
如果你的查询条件是
WHERE username = 'xxx'，那么这个索引也能生效。但如果你的查询条件是
WHERE email = 'xxx'，那么这个索引就无法生效。
-- 可以使用索引 SELECT * FROM users WHERE username = 'test'; -- 也可以使用索引 SELECT * FROM users WHERE username = 'test' AND email = 'test@example.com'; -- 无法使用索引 SELECT * FROM users WHERE email = 'test@example.com';
如何避免索引失效？
避免索引失效，说白了就是让你的查询条件尽可能地匹配索引。
- 避免在索引列上使用函数： 如果必须使用函数，可以考虑创建函数索引。
- 避免隐式类型转换： 保持查询条件和索引列的数据类型一致。
- 尽量避免使用OR： 可以考虑使用UNION ALL或者将OR条件拆分成多个查询。
- 注意范围查询的位置： 将范围查询放在联合索引的最后面。
例如，假设你有一个订单表，有
order_id、
user_id、
order_time三个字段，你经常需要根据
user_id和
order_time进行查询。那么，你可以创建一个联合索引
(user_id, order_time)。
CREATE INDEX idx_user_order_time ON orders (user_id, order_time);
如果你的查询条件是
WHERE user_id = 123 AND order_time BETWEEN '2023-01-01' AND '2023-01-31'，那么这个索引可以生效。但如果你的查询条件是
WHERE order_time BETWEEN '2023-01-01' AND '2023-01-31' AND user_id = 123，那么只有
order_time能用到索引，
user_id无法使用。
总的来说，理解最左前缀原则，需要理解索引的底层结构，并结合实际的查询场景进行分析。只有这样，才能设计出高效的索引，提升查询性能。
