网站数据库慢查询怎么排查：6步索引与读写分离方案

慢查询怎么定位？先开日志，再谈优化

结论：排查慢查询的第一步是开启慢查询日志，一般阈值设为 1 秒，连续观察 7 天后再动手。没有数据支撑的优化，通常只是把压力换个地方。

MySQL 侧可通过 slow_query_log 与 long_query_time 开启记录。拿到日志后按总耗时排序而非单次耗时排序——单次 5 秒但一天只跑一次的 SQL，优先级低于单次 0.8 秒却每分钟跑几百次的 SQL。

同时用 EXPLAIN 看执行计划，重点看三列：type 是否出现 ALL（全表扫描）、rows 是否远大于返回行数、key 是否命中预期索引。

哪些 SQL 需要优先改？6 类典型写法

结论：以下 6 类写法在中小企业网站里常见，一般改完就能看到耗时下降。

1. SELECT * 查询：只取需要的字段，减少回表与网络传输
2. 分页过深：LIMIT 100000, 20 这类深翻页一般改为基于 id 的游标分页
3. 在索引列上使用函数：如 WHERE DATE(create_time) = ...，会导致索引失效
4. 隐式类型转换：字符串字段用数字查询，索引同样失效
5. 联表字段无索引：JOIN 的关联字段两侧都要建索引
6. 高频计数查询：每次 COUNT(*) 扫全表，一般改为定时统计写入缓存

索引怎么加才有效？3 条规则

结论：索引不是加得越多越好，每多一个索引，写入性能就多一份开销。

• 遵循联合索引的左前缀原则：联合索引 (a, b, c) 能加速 a、a+b、a+b+c，单独查 b 用不上
• 区分度高的字段放前面：状态字段只有 2 个取值，索引收益有限
• 控制单表索引数量：一般建议一张表不超过 5 个

加完索引要复跑 EXPLAIN 确认命中，并对比优化前后的扫描行数，而不是凭感觉判断。

什么时候需要读写分离？先看三个信号

结论：读写分离不是性能优化的第一步，而是索引与 SQL 都改到位之后的下一步。

1. 慢查询日志里已没有明显可优化的 SQL，但数据库 CPU 仍长期偏高
2. 读请求量远大于写请求，例如列表页、搜索页访问量远高于提交量
3. 已引入缓存，但命中率提不上去

实现一般是一主多从，写走主库、读走从库，通过中间件或应用层路由。引入后需考虑主从延迟：提交完立刻刷新列表可能读不到刚写入的数据，这类场景要强制走主库。

优化后怎么验证？回归与日常监控

结论：优化效果必须用同一组指标对比，观察周期一般不少于 7 天。

• 对比指标：慢查询条数、响应时间、数据库 CPU 与连接数、接口 P95 耗时
• 回归测试：核心页面与提交流程逐条走一遍
• 日常监控：对慢查询条数设置告警阈值，不要等到用户投诉
• 巡检留痕：记录每次改动内容与时间

玉晗网络（安徽安庆）提供服务器运维托管服务，日常巡检包含慢查询日志分析、索引健康度检查与容量评估。如果网站近期打开变慢、后台卡顿，可先导出近 7 天慢查询日志按上述步骤自查，也可在官网咨询表单里留下站点信息，我们协助做一次性能诊断。