为什么网站变慢要先看慢查询日志
网站响应越来越慢时，很多人第一反应是升级配置或加缓存，但如果拖慢页面的是一条没走索引的 SQL（结构化查询语言，与数据库交互的标准语言），这些动作的收益都很有限。慢查询日志是 MySQL（最流行的开源关系型数据库）内置的”体检记录仪”：它把执行时间超过阈值的每一条 SQL 原样记下来，附带扫描行数、返回行数和执行时长。解决”网站为什么慢”这个问题，正确的顺序是先开日志、拿到证据、再动手优化——本文按”开启 → 设置阈值 → 采样验证 → 汇总解读”四个步骤展开，所有命令在[虚拟主机](https://cn.hostease.com/web-hosting/)的 phpMyAdmin 或 SSH 环境下均可执行，帮助你在半小时内把数据库的真实瓶颈找出来。
开始前确认两个前提：一是你有数据库的管理权限（虚拟主机环境下通常是 cPanel 里创建的数据库用户，操作自己的库足够了）；二是清楚当前 MySQL 版本（5.7 与 8.0 的部分变量名有差异，下文会分别说明）。改任何全局变量前不需要重启数据库，本文所有设置都可以在线生效，风险很低。
第一步：开启慢查询日志并设置 long_query_time
开启动作只涉及几个变量，先在 phpMyAdmin 的 SQL 窗口或命令行执行 SHOW VARIABLES LIKE 'slow_query%'; 确认当前状态：大多数环境默认 slow_query_log 为 OFF。开启并设置阈值：
SET GLOBAL slow_query_log = ON;—— 打开慢查询日志开关SET GLOBAL long_query_time = 1;—— 记录执行超过 1 秒的查询；默认值 10 秒太宽松，多数 Web 场景下 0.5-1 秒是比较合适的采样起点SET GLOBAL log_queries_not_using_indexes = ON;—— 把没走索引的查询也记下来，即使它执行很快；这一项能提前暴露”数据量小所以暂时不慢”的隐患 SQL- 验证：
SHOW VARIABLES LIKE 'long_query_time';确认新值生效，SELECT SLEEP(2);故意执行一条 2 秒的语句，然后查看日志文件确认被记录
阈值怎么选是个值得展开的问题：long_query_time 设得太宽（如默认 10 秒），日志里只会出现极端故障语句，平时拖慢页面的 0.8 秒查询全部漏掉；设得太严（如 0.1 秒），高峰期日志量会膨胀，分析成本上升。实操建议是从 1 秒开始观察一周，如果日志条目很多就降到 0.5 秒继续收窄。注意 SET GLOBAL 在数据库重启后会失效，虚拟主机用户无法改配置文件时，可以每月重新执行一次这几条语句，或使用支持事件调度的环境固化设置。
第二步：采样验证与 mysqldumpslow 汇总解读
日志开起来之后，需要真实流量跑一段时间才有分析价值，这个采样窗口建议不少于 24 小时——覆盖一整个业务日，才能看到高峰时段的完整画像。采样结束后有两条分析路径：
- 有 SSH 权限：直接用 MySQL 自带的汇总工具
mysqldumpslow -s t -t 10 /日志路径/主机名-slow.log，参数-s t表示按总耗时排序、-t 10表示只看最差的前 10 条，输出会把同类查询归并计数，比肉眼翻日志高效得多 - 只有 phpMyAdmin：MySQL 5.5 以上可以把慢查询写入系统表：先
SET GLOBAL log_output = 'TABLE';再开启日志，之后在mysql.slow_log表里直接 SELECT 查询分析；分析完记得把 log_output 改回 FILE，避免系统表无限增长
解读日志时按三个字段判断严重程度：Query_time（执行时长）反映用户等待时间；Rows_examined 与 Rows_sent 的比值是关键指标——扫描 10 万行只返回 10 行，几乎可以断定缺索引；出现频率同样重要，一条 0.6 秒但每分钟执行 200 次的查询，总代价远超一条 3 秒但每天一次的报表查询。mysqldumpslow 的汇总输出已经把相同结构的查询按出现次数合并，优先处理”次数 × 时长”乘积最大的那几条，优化收益最大。
第三步：从日志到优化的落地路径
定位到问题 SQL 后，优化动作按投入从低到高排序。第一优先级是加索引：把 Rows_examined/Rows_sent 比值高的查询拿出来，用 EXPLAIN SELECT ...; 查看执行计划，如果 type 列显示 ALL（全表扫描），在 WHERE 和 ORDER BY 涉及的列上建索引，通常能把扫描行数降低几个数量级。第二优先级是改写查询本身：避免在索引列上套函数、把 SELECT * 改成只取需要的列、大分页改成基于 ID 的游标分页，这几类改写不依赖 DBA（数据库管理员）权限，开发侧就能完成。
改完之后必须做回归验证：重新执行这条 SQL 并对比 Query_time，再观察第二天慢查询日志中它的出现次数是否清零。优化是一个闭环——日志发现、EXPLAIN 定位、修改、回归验证，四步缺一不可，只做前三步等于没有闭环。如果日志显示数据库整体负载已经高到虚拟主机的共享资源无法承载（例如高峰期大量无关查询集体变慢），那就是迁移的信号，可以考虑升级到 VPS 主机获得独立的数据库资源配额。
总结与行动建议
回顾完整流程：SET GLOBAL slow_query_log = ON 打开记录仪，long_query_time 从 1 秒起步校准阈值，真实流量采样不少于 24 小时，用 mysqldumpslow 或 slow_log 表汇总出”次数 × 时长”最高的 SQL，按”加索引 → 改写语句 → 资源升级”的顺序落地，最后回归验证闭环。整套动作的成本不到一小时，却能把你从”凭感觉优化”切换到”凭证据优化”。
建议把这套流程纳入每月例行维护：月初开启日志采样一周，月中集中分析并优化，配套的备份和面板操作可以参考本站 服务器分类的系列教程，WordPress 站点的数据库日常维护还可以延伸阅读 WordPress 分类中的实践文章；虚拟主机环境的选择与资源评估，可参考 虚拟主机产品页的配置说明。如果你需要现成的分析工具，除了 mysqldumpslow 之外，pt-query-digest（Percona Toolkit 套件的一部分）提供更细的统计维度，适合查询量大、需要长期跟踪的场景。