1. 联合索引字段顺序的性能陷阱最近在优化一个会员系统的查询性能时发现一个有趣的现象同样是(is_vip, time)和(time, is_vip)这两个字段组合的联合索引查询性能竟然相差100倍这个发现让我意识到联合索引字段顺序的重要性远超过我的想象。在会员系统中我们经常需要查询特定时间段内的VIP用户数据。最初我创建了(time, is_vip)的联合索引因为我认为时间字段放在前面可以更好地支持范围查询。但实际测试发现当查询条件为is_vip1 AND time BETWEEN 2023-01-01 AND 2023-12-31时这个索引几乎没起作用查询耗时长达2秒。2. 联合索引的工作原理2.1 B树索引结构MySQL的联合索引是基于B树实现的索引字段的顺序决定了数据在B树中的排列方式。以(is_vip, time)索引为例首先按is_vip排序相同is_vip值的记录再按time排序这种结构意味着索引可以高效定位到is_vip1的所有记录在这些记录中time是有序的可以快速进行范围查询2.2 最左前缀原则MySQL使用索引时会遵循最左前缀原则查询必须使用索引的最左列否则索引失效对于范围查询后的列索引将停止使用这就是为什么(time, is_vip)索引在is_vip1 AND time BETWEEN...条件下效果不佳查询条件没有使用最左的time字段即使使用了time范围is_vip也无法有效利用索引3. 实际性能对比测试3.1 测试环境表结构users(id, name, is_vip, time, ...)数据量1000万条测试查询SELECT * FROM users WHERE is_vip1 AND time BETWEEN 2023-01-01 AND 2023-12-313.2 测试结果索引类型执行时间扫描行数索引使用情况(is_vip, time)20ms50,000使用索引(time, is_vip)2000ms1,000,000全表扫描无索引3000ms10,000,000全表扫描从测试结果可以看出(is_vip, time)索引性能最佳(time, is_vip)索引几乎没用性能接近无索引性能差距确实达到100倍4. 索引设计的最佳实践4.1 字段顺序选择原则高选择性字段优先将区分度高的字段放在前面is_vip只有0/1两个值区分度看似不高但在我们的查询中is_vip1只占5%选择性其实很好等值查询字段优先范围查询字段is_vip是等值查询()time是范围查询(BETWEEN)等值查询字段放前面可以最大化利用索引常用查询条件优先分析业务查询模式将最常用的查询条件放在索引前面4.2 实际案例分析假设我们有以下几种常见查询WHERE is_vip1 AND time BETWEEN...(VIP用户查询)WHERE time BETWEEN...(时间范围查询)WHERE is_vip1(所有VIP用户)最优索引方案创建两个索引(is_vip, time) 和 (time)这样三种查询都能高效使用索引5. 常见误区与解决方案5.1 误区一范围查询字段放前面很多开发者认为范围查询字段应该放前面因为范围查询需要索引。实际上范围查询后的索引列将失效应该把等值查询字段放前面5.2 误区二忽略业务查询模式索引设计应该基于实际业务查询而不是表结构。需要收集所有重要查询SQL分析WHERE条件和排序字段根据查询模式设计索引5.3 误区三过度依赖索引合并MySQL支持索引合并(Index Merge)但性能通常不如一个好的联合索引索引合并需要额外的排序和合并操作联合索引可以一次性完成查找6. 高级优化技巧6.1 覆盖索引优化如果查询只需要索引列可以使用覆盖索引避免回表-- 普通查询需要回表 SELECT * FROM users WHERE is_vip1 AND time BETWEEN... -- 覆盖索引优化 SELECT id, is_vip, time FROM users WHERE is_vip1 AND time BETWEEN...6.2 索引条件下推(ICP)MySQL 5.6支持ICP可以在存储引擎层过滤数据对于(is_vip, time)索引即使查询条件为time BETWEEN... AND is_vip1ICP可以提前过滤is_vip1的记录6.3 索引跳跃扫描MySQL 8.0支持索引跳跃扫描对于(is_vip, time)索引即使查询条件只有time也可能使用索引但性能不如直接使用time索引7. 监控与维护7.1 索引使用情况监控定期检查索引使用情况-- 查看未使用的索引 SELECT * FROM sys.schema_unused_indexes; -- 查看索引使用统计 SELECT * FROM sys.schema_index_statistics;7.2 索引维护建议定期分析表更新统计信息ANALYZE TABLE users;删除冗余和未使用的索引考虑索引的写入开销8. 真实业务场景下的索引设计8.1 电商订单系统典型查询查询某用户待付款订单查询某时间段内的订单推荐索引(user_id, status, create_time)(create_time)8.2 社交网络系统典型查询查询用户好友的最新动态查询热门内容推荐索引(user_id, friend_id, post_time)(post_time, like_count)9. 性能问题排查流程当遇到查询性能问题时使用EXPLAIN分析执行计划检查是否使用了正确的索引检查索引字段顺序是否匹配查询条件考虑重写查询或添加新索引10. 个人实践经验分享在实际工作中我发现几个有用的技巧使用pt-index-usage工具分析索引使用情况对于复杂查询考虑使用查询重写定期进行索引审查删除无用索引新功能上线前一定要检查索引设计最后提醒一点索引不是越多越好。每个额外的索引都会增加写入开销和维护成本。理想的索引设计应该是在查询性能和写入性能之间取得平衡。