这篇文章资料来自于网络和AI，是对部分知识整理，这里只是记录一下，仅供参考
现象
复合索引 (item1, item2, item3) 使用 > 比较三个字段时索引失效（type=ALL，全表扫描）。
一、核心原因
复合索引的「最左前缀匹配原则」与范围查询的限制
- 复合索引的匹配规则 ：MySQL 复合索引遵循「最左前缀匹配原则」，索引的生效是从左到右依次匹配的，一旦遇到范围查询（
>、<、>=、<=、between、like %xxx等），该字段后续的索引列将无法被有效利用（无法进行等值匹配，只能放弃后续索引列）。 - 你的查询问题本质：
(item1, item2, item3) > (?, ?, ?)这种多列同时范围比较的写法，MySQL 无法将其拆解为符合最左前缀原则的有效匹配，会判定为无法利用该复合索引，最终退化为全表扫描（type=ALL）。
补充说明：这种多列并行 > 比较，逻辑上不等于 item1 > ? and item2 > ? and item3 > ?，也不等于 item1 > ? or (item1 = ? and item2 > ?) or (...)，MySQL 优化器无法对其进行高效索引解析。
二、可行解决方案（按推荐优先级排序）
方案 1：重写查询，遵循最左前缀原则，实现「等值 + 范围」的索引有效利用
这是最推荐的方案，无需修改索引，仅需调整查询语句，让复合索引逐步生效，核心思路是：左侧列先等值匹配，右侧列再做范围查询（只有最右侧的列适合做范围查询，前面的列尽量等值匹配）。
示例场景与改写
假设你原查询（失效）：
-- 原查询：多列同时 > ，索引失效 type=ALL
SELECT * FROM your_table
WHERE (item1, item2, item3) > (100, 'abc', '2026-01-12')
ORDER BY item1, item2, item3;改写后（索引有效利用）：
-- 改写后：遵循 等值匹配→后续列范围 的逻辑，充分利用复合索引 (item1, item2, item3)
SELECT * FROM your_table
WHERE
-- 第1步：item1 大于目标值（范围查询，后续列需嵌套在该条件内）
item1 > 100
OR
-- 第2步：item1 等值匹配，item2 大于目标值
(item1 = 100 AND item2 > 'abc')
OR
-- 第3步：item1、item2 均等值匹配，item3 大于目标值
(item1 = 100 AND item2 = 'abc' AND item3 > '2026-01-12')
ORDER BY item1, item2, item3;效果说明：
- 该查询完全符合复合索引的最左前缀原则，MySQL 会依次利用
item1、item2、item3索引列，type会从ALL提升为range或ref（视数据分布而定），大幅提升查询效率。 - 改写后的查询逻辑与原
(item1, item2, item3) > (?, ?, ?)完全一致（多列组合排序的大于判断）。
方案 2：创建「虚拟列」+ 单列索引，适配多列组合比较
如果无法改写查询语句，可通过 MySQL 5.7+ 支持的「虚拟列（Generated Column）」将多列组合为一个单列，再创建索引，适配组合比较场景。
操作步骤：
-
给表添加虚拟列（组合
item1, item2, item3，注意字段类型兼容，需做合理转换）：-- 新增虚拟列（不占用实际存储，仅在查询/索引时计算） ALTER TABLE your_table ADD COLUMN combo_item VARCHAR(255) GENERATED ALWAYS AS (CONCAT_WS('|', item1, item2, item3)) STORED; -- STORED 占用存储，查询更快；VIRTUAL 不占存储，更新更快
注意：CONCAT_WS 用分隔符（如 |）避免字段值拼接后混淆（例如 item1=12, item2=3 与 item1=1, item2=23 拼接差异），字段类型为数值 / 日期时，需先转换为字符串（如 CAST(item3 AS CHAR)）。
-
给虚拟列创建单列索引：
CREATE INDEX idx_combo_item ON your_table (combo_item); -
改写查询，利用虚拟列索引：
-- 虚拟列组合值比较，可有效利用 idx_combo_item 索引 SELECT * FROM your_table WHERE combo_item > CONCAT_WS('|', 100, 'abc', '2026-01-12') ORDER BY combo_item;
注意事项：
- 虚拟列的组合排序规则需与原
(item1, item2, item3)组合排序规则一致，否则查询结果会有差异。 - 若表数据量极大，新增
STORED虚拟列会占用额外存储，且 ALTER TABLE 会锁表（InnoDB 8.0+ 支持在线 DDL 可缓解）。
方案 3：调整业务逻辑，避免多列同时范围比较
如果业务场景允许，可简化查询条件，例如：
- 优先用
item1做范围筛选（利用复合索引最左列），缩小结果集后，再在应用层过滤item2、item3。 - 若多列组合是唯一标识，可将其转换为单一排序键（如自增 ID、时间戳 + 序号），避免多列比较。
三、验证索引是否生效的方法
修改查询后，可通过以下方式验证索引是否被有效利用，避免仍出现 type=ALL：
-
使用
EXPLAIN分析查询执行计划：-- 替换为你的改写后查询 EXPLAIN SELECT * FROM your_table WHERE item1 > 100 OR (item1 = 100 AND item2 > 'abc') OR (item1 = 100 AND item2 = 'abc' AND item3 > '2026-01-12'); -
关键判断指标：
type列：不为ALL，理想值为ref、range（复合索引范围查询常见）。key列：显示你创建的复合索引名（idx_item1_item2_item3）或虚拟列索引名（idx_combo_item）。Extra列：无Using filesort、Using temporary（避免额外排序 / 临时表开销），最好显示Using index condition（索引条件下推，高效利用索引）。
四、如何进行 SQL 调优
1. 分析和优化SQL 语句
- 分析查询计划: 使用 EXPLAIN 关键字分析SQL 语句的执行计划，找出潜在的性能瓶颈。
- 避免函数和运算: 避免在 WHERE 子句的索引列上使用函数或进行运算，例如 WHERE function(column) = 'value'，可以考虑将运算结果存储在新的列并建立索引。
- 选择正确的列: 仅选择需要的列，避免使用 SELECT *。
- 优化JOIN: 确保JOIN 操作时小表在前，大表在后，以提高效率。
- 简化查询: 尽量避免不必要的子查询和 JOIN。 对于 OR 条件，可以考虑使用 UNION ALL 替代（如果不需要去重）。
- 避免模糊查询: 尽量避免在字段开头进行模糊查询，这可能导致数据库放弃使用索引。
- 其他: 使用 TRUNCATE 代替 DELETE 来清空表（如果不需要回滚）。
2. 使用和优化索引
- 创建索引: 在经常用于 WHERE 条件、JOIN 和 ORDER BY 的字段上创建索引。
- 选择性高的列: 选择具有高选择性的列（不重复值多的列）创建索引，以更快缩小搜索范围。
- 复合索引: 当多个列经常同时用于查询条件时，创建复合索引可以减少索引数量。
- 避免过多索引: 过多的索引会降低 INSERT 和 UPDATE 的性能。
- 按需创建: 权衡索引的数量和性能提升，只创建必要的索引。
- 定期维护: 定期对索引进行维护和重建，以保持其效率。
3. 优化数据库设计和配置
- 合理设计表结构: 避免冗余字段，使用合适的字段类型。
- 选择合适的数据类型: 避免使用过大的数据类型，以减少存储和查询的开销。
- 调整数据库参数: 调整缓存设置等数据库配置参数，如 innodb_buffer_pool_size。
- 使用查询缓存: 启用查询缓存，对于相同的查询，直接从缓存中获取结果。
4. 其他优化方法
- 避免长事务: 长事务会导致锁竞争，增加死锁风险。
- 批量操作: 对于大量插入或更新操作，使用批量操作。
- 定期维护: 定期进行数据库的维护和清理。
总结
- 核心问题：复合索引多列同时
>违反最左前缀原则，优化器无法解析，导致全表扫描。 - 最优方案：改写查询为「等值 + 范围」的嵌套逻辑，充分利用现有复合索引，无需额外修改表结构。
- 备选方案：虚拟列 + 单列索引，适配无法改写查询的场景，需注意存储和排序规则一致性。
- 验证关键：用
EXPLAIN查看type和key列，确认索引生效。
参考
https://www.cnblogs.com/crazymakercircle/p/17496844.html