在mysql的查询优化场景中，覆盖索引是提升查询性能的重要手段，但很多时候执行计划并不会按照预期选择覆盖索引，同时索引下推ICP技术也会对优化器的路径选择产生影响，理解其中的逻辑能帮助开发者更好地优化查询。
核心概念说明
覆盖索引
覆盖索引指的是查询所需要的所有字段都包含在某个索引的叶子节点中，不需要回表查询聚簇索引获取额外字段，能大幅减少IO操作。比如表user有索引idx_name_age(name,age)，查询SELECT name,age FROM user WHERE name='张三'就可以走覆盖索引。
索引下推ICP
索引下推ICP是mysql5.6引入的优化技术，指的是在存储引擎层利用索引中包含的字段对where条件进行过滤，减少回表次数。比如查询SELECT * FROM user WHERE name LIKE '张%' AND age>20，如果有idx_name_age索引，存储引擎会先利用索引过滤name和age条件，再回表查询剩余字段，而不是先回表再过滤。
执行计划不走覆盖索引的常见原因
1. 查询字段不在索引中
如果查询的字段没有被索引覆盖，优化器自然不会选择覆盖索引。比如表user只有idx_name索引，查询SELECT name,age FROM user WHERE name='张三'，age字段不在索引中，需要回表获取，就不会走覆盖索引。
2. 优化器评估成本更高
mysql优化器会基于统计信息评估不同执行路径的成本，如果走覆盖索引的成本比全表扫描或者其他索引的成本更高，就不会选择覆盖索引。比如当符合条件的记录占表总记录的比例很高时，全表扫描的成本可能更低。
3. 索引下推的影响
当查询可以使用索引下推时，优化器可能会选择非覆盖索引但支持ICP的索引，因为ICP能减少回表次数，整体成本可能比覆盖索引更低。比如查询需要返回所有字段，即使有覆盖索引，但如果另一个索引支持ICP且回表次数更少，优化器也可能选择后者。
索引下推与优化器路径选择的关联
优化器在选择执行路径时，会把索引下推的收益纳入成本计算。如果某个索引支持ICP，能过滤掉大量不符合条件的记录，减少回表次数，即使该索引不是覆盖索引，优化器也可能优先选择它。
我们可以通过执行计划查看是否使用了ICP，在Extra列中如果出现Using index condition就表示使用了索引下推，出现Using index表示使用了覆盖索引。
示例验证
先创建测试表和索引：
-- 创建用户表
CREATE TABLE `user` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`name` varchar(50) DEFAULT NULL,
`age` int(11) DEFAULT NULL,
`address` varchar(100) DEFAULT NULL,
PRIMARY KEY (`id`),
KEY `idx_name_age` (`name`,`age`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
-- 插入测试数据
INSERT INTO `user` (`name`,`age`,`address`) VALUES
('张三',20,'北京'),
('张三',25,'上海'),
('李四',22,'广州'),
('王五',30,'深圳');
执行查询查看执行计划：
-- 查询1：走覆盖索引的情况 EXPLAIN SELECT name,age FROM user WHERE name='张三' AND age>20; -- 查询2：使用索引下推的情况 EXPLAIN SELECT * FROM user WHERE name LIKE '张%' AND age>20;
查询1的执行计划中Extra列会显示Using index，表示走了覆盖索引；查询2的执行计划中Extra列会显示Using index condition，表示使用了索引下推，此时优化器没有选择覆盖索引，因为查询需要返回所有字段，覆盖索引无法覆盖address字段，但ICP减少了回表次数。
优化建议
- 尽量让查询的字段被索引覆盖，减少回表操作
- 设计联合索引时，把where条件中常用的字段放在前面，同时尽量包含查询需要的字段，兼顾覆盖索引和ICP的收益
- 定期更新表统计信息，让优化器能做出更准确的成本评估
- 通过执行计划分析具体查询的路径选择，针对性调整索引或者sql语句