确认慢查询需先查宝塔「数据库→性能状态」中「慢查询数量」是否持续增长；再手动配置mysql的slow_query_log、long_query_time并重启服务，通过explain分析日志中的高频低效sql，针对性添加高基数字段索引。
怎么确认是不是慢查询在拖慢网站
直接看宝塔面板「数据库」→「性能状态」里的「每秒查询数 QPS」和「慢查询数量」，如果后者不是 0，且数值持续增长，基本就是慢查询在作祟。更准的办法是打开 MySQL 的 slow_query_log，配合 long_query_time 设置（比如设为 1 秒），让系统主动把超时 SQL 记下来——别只盯着「页面加载慢」这种表象，很多情况下是某条没走索引的 SELECT 在后台反复执行，把连接池和磁盘 IO 拖垮。
在宝塔里开慢查询日志的实操步骤
宝塔不提供图形化开关，得手动改配置：
- 进入宝塔面板 →「数据库」→ 找到你的 MySQL 实例 → 点击「设置」→「配置修改」
- 在配置文件末尾追加这三行（注意缩进对齐，不要顶格）：
slow_query_log = ON<br>slow_query_log_file = /www/server/data/mysql-slow.log<br>long_query_time = 1
- 保存后必须重启 MySQL：回到「数据库」页点「重启」按钮，不能只重载配置
- 验证是否生效：用命令
mysql -uroot -p -e "SHOW VARIABLES LIKE 'slow_query_log';"，返回ON才算成功
常见坑：日志路径 /www/server/data/mysql-slow.log 要确保目录可写；如果改完重启没反应，大概率是配置语法错误或路径权限不对，查 /www/server/data/error.log 最直接。
从慢日志里快速定位问题 SQL 和缺失索引
别一上来就全文扫日志。先用命令过滤出最“烫手”的几条：
tail -n 200 /www/server/data/mysql-slow.log | grep -A 2 "Query_time"
重点关注三类语句：
-
WHERE条件里用了函数或类型转换（比如WHERE DATE(create_time) = '2026-04-20'），索引直接失效 -
ORDER BY字段没被WHERE覆盖，又没建联合索引，容易触发Using filesort -
JOIN表没加ON条件，或关联字段类型不一致（如VARCHAR对INT），会全表扫描
拿到具体 SQL 后，在 phpMyAdmin 或命令行跑 EXPLAIN：
EXPLAIN SELECT * FROM user_logs WHERE status = 1 AND created_at > '2026-04-01';看
type 是不是 ALL、key 是否为空、rows 是否远大于实际结果数。加索引前必须核对的三个事实
不是所有字段都适合加索引，乱加反而拖慢写入：
- 单表数据量
，且查询频率低，加索引收益极小，还占空间 -
UPDATE/INSERT频繁的字段（比如订单表的updated_at），索引维护成本高，要权衡 - InnoDB 引擎下，主键是聚簇索引，
WHERE条件含主键时优先走主键，别重复建索引
真正该加的，是那些出现在 WHERE、JOIN、ORDER BY 中，且 cardinality（基数）高的字段，比如用户表的 email、日志表的 user_id + created_at 联合索引。建完立刻用 EXPLAIN 对比，rows 下降一个数量级才算有效。
