sql慢查询主因是数据访问路径低效、资源争用明显、执行计划偏差；需从语句、索引、表结构、配置四层面协同优化，如避免在索引列用函数、禁用select *、添加有效过滤条件。
SQL慢查询通常不是单一问题，而是多个环节叠加导致的性能衰减。核心原因集中在数据访问路径低效、资源争用明显、执行计划偏差这三类，优化需从语句、索引、表结构、配置四个层面协同推进。
查询语句本身存在硬伤
很多慢查询直接源于写法不当，比如在WHERE条件中对字段做函数操作、使用SELECT *、关联多张大表却没加有效过滤条件等。这些写法会绕过索引、增加网络传输和内存消耗。
- 避免在索引列上使用函数或表达式：如WHERE YEAR(create_time) = 2023应改为WHERE create_time >= ‘2023-01-01’ AND create_time
- 只查需要的字段，禁用SELECT *，尤其在宽表或含TEXT/BLOB字段时
- 分页深度较大时（如OFFSET 10000 LIMIT 20），改用游标分页或延迟关联优化
缺少合适索引或索引失效
索引不是越多越好，但关键查询路径上没有覆盖索引，就只能全表扫描。常见失效场景包括：最左前缀未匹配、隐式类型转换、OR条件未统一走索引、范围查询后列无法被索引覆盖。
- 用EXPLaiN分析执行计划，重点看type是否为ALL/INDEX，key是否为NULL，rows是否远超实际返回行数
- 复合索引设计要按“过滤性高→排序/分组→SELECT列”顺序排列，例如查询WHERE status=1 AND category_id=5 ORDER BY created_at DESC，推荐索引(status, category_id, created_at)
- 对高频更新的字段谨慎建索引，避免写放大；对低区分度字段（如gender、is_deleted）单独建索引意义不大
表结构与数据分布不合理
大单表（千万级以上）、宽表（上百字段）、存在大量TEXT/BLOB、历史数据未归档，都会拖慢查询。mysql的B+树索引在数据量激增后，树高增加，I/O次数上升，响应自然变长。
- 考虑垂直拆分：把不常查的大字段（如content、description）移到附表
- 按时间或业务维度水平分表（如按月分表orders_202301），配合路由逻辑或分区表（PARTITION BY RANGE）
- 定期归档冷数据，删除无业务价值的历史记录，保持主表体量可控
数据库配置与运行环境瓶颈
即使SQL和索引都合理，如果buffer pool太小、连接数不足、磁盘I/O饱和、CPU长期90%+，照样会慢。这类问题往往在流量高峰集中暴露。
- InnoDB buffer pool建议设为物理内存的60%~75%，确保热数据尽量驻留内存
- 监控long_query_time、slow_query_log、Threads_running等指标，结合pt-query-digest分析慢日志
- 检查是否出现锁等待（如show engine innodb status中的SEMAPHORES段），排查事务过长、未提交或间隙锁冲突