数据库复合索引设计：为什么等值查询列应该放在范围查询列前面？
前言
作为后端开发工程师，我们经常会遇到数据库查询性能问题。在一次系统优化中，我发现一个简单的索引顺序调整竟然让查询速度提升了10倍！这让我意识到复合索引列顺序的重要性。今天，我就来分享一下这个经验，希望能帮助大家避免类似的性能陷阱。
一次真实的性能优化经历
上周，我接手优化一个运行缓慢的订单查询接口。原查询如下：
SELECT * FROM orders
WHERE create_time > '2023-01-01'
AND status = 'completed'
ORDER BY amount DESC
LIMIT 100;这个查询在百万级数据表中需要3秒多才能返回结果，明显不符合要求。
问题分析
我先用EXPLAIN查看了执行计划：
EXPLAIN SELECT * FROM orders
WHERE create_time > '2023-01-01'
AND status = 'completed'
ORDER BY amount DESC
LIMIT 100;结果显示数据库进行了全表扫描，使用了filesort排序。原来表上只有一个索引：
INDEX idx_create_time_status (create_time, status)解决方案
根据复合索引的最佳实践，我调整了索引列的顺序：
DROP INDEX idx_create_time_status ON orders;
CREATE INDEX idx_status_create_time ON orders(status, create_time);再次执行查询，响应时间从3秒多降到了300毫秒左右！
为什么这样有效？
1. 等值条件优先原则
status = 'completed'是等值查询create_time > '2023-01-01'是范围查询
数据库能更高效地使用等值条件过滤数据。在我们的案例中，completed状态的订单只占总量的10%，先过滤这部分数据大大减少了需要处理的数据量。
2. 范围查询的"阻断"效应
当范围查询列在前时，后面的列通常无法有效使用索引。而等值列在前时，范围查询仍然可以利用索引。
3. 覆盖索引优势
新索引还能支持这样的查询：
SELECT status, create_time FROM orders
WHERE status = 'completed'
AND create_time > '2023-01-01';这个查询可以完全通过索引完成，无需访问表数据。
实际应用建议
分析查询模式：使用慢查询日志找出高频查询
检查执行计划：EXPLAIN是必备工具
考虑选择性：高选择性的等值条件列应该靠前
权衡索引数量：不是越多越好，每个索引都有维护成本
常见误区
盲目添加单列索引：不如设计好的复合索引有效
忽视列顺序：以为只要包含这些列就行
过度索引：为每个查询都创建独立索引
总结
通过这个案例，我深刻理解了复合索引列顺序的重要性。记住这个简单的原则：等值查询列在前，范围查询列在后，往往能带来意想不到的性能提升。
你在索引优化方面有什么经验或问题？欢迎在评论区分享交流！