高频查询性能瓶颈在于索引与真实查询模式不匹配；需基于慢日志分析执行频次、选择率和组合规律，按高区分度字段在前、范围字段在后设计复合索引，并避免隐式转换、NULL干扰及函数写法不匹配等问题。
高频条件查询的性能瓶颈，往往不在SQL写法，而在索引是否匹配真实查询模式。盲目加索引或照搬单字段索引，反而拖慢写入、浪费空间、甚至让优化器选错执行计划。
识别真正的高频查询条件
不能只看“WHERE里写了哪些字段”，要看实际执行频次、过滤选择率和组合规律：
- 查慢查询日志或数据库性能监控（如MySQL的slow_log、pg_stat_statements），提取执行次数多、平均耗时高的WHERE片段
- 注意谓词顺序不等于执行顺序：(status = 'done' AND create_time > '2024-01-01') 和 (create_time > '2024-01-01' AND status = 'done') 在语义上等价，但索引设计必须按高区分度字段在前、范围查询字段靠后的原则组织
- 警惕隐式类型转换：比如varchar字段用数字查询（WHERE order_no = 123）会导致索引失效，需统一数据类型
复合索引设计的核心原则
一个索引能否覆盖高频查询，取决于字段顺序、是否包含查询/排序/分组字段，以及是否避免回表：
- 等值条件字段放最左：如常查 WHERE dept_id = ? AND status = ?，则索引应为 (dept_id, status)，而非反过来
- 范围条件字段只能放最后：WHERE dept_id = ? AND create_time > ?，适合 (dept_id, create_time)；若再加 ORDER BY update_time，则考虑 (dept_id, create_time, update_time) —— 但需确认update_time是否真的参与过滤
- 覆盖索引优先：SELECT id, name, amount WHERE status = ? AND type = ?，可建 (status, type, id, name, amount)，避免回主键查找
避免常见索引陷阱
很多“看似合理”的索引，在报表场景下实际无效：
- 单独为ORDER BY字段建索引无意义：除非该字段也在WHERE中作为等值条件，否则仅靠 (order_time) 索引无法加速带WHERE的排序查询
- NULL值影响选择率：status字段若大量为NULL，即使建了索引，优化器也可能放弃使用——可考虑用默认值替代NULL，或加表达式索引（如 PostgreSQL 的 (COALESCE(status, 'unknown'))）
- 函数索引要匹配写法：WHERE DATE(create_time) = '2024-01-01' 无法走 create_time 普通索引，应改写为 create_time >= '2024-01-01' AND create_time
验证与迭代：别信“建完就快”
索引效果必须用真实数据+真实SQL验证：
- 用EXPLAIN ANALYZE（PostgreSQL）或EXPLAIN FORMAT=JSON（MySQL 8.0+）看是否命中索引、是否回表、是否使用索引排序
- 关注rows_examined是否明显下降，而不仅是“type=ref”这种表面信息
- 上线后持续观察：索引会增加INSERT/UPDATE开销，尤其写多读少的报表库，建议在低峰期灰度+对比QPS、延迟、IO等待
