先确认慢日志是否开启并调低long_query_time，用mysqldumpslow分析慢日志定位问题SQL，再通过EXPLAIN重点查看type、key、rows三列判断索引使用情况，按最左前缀原则合理创建复合索引，并验证索引是否生效。
怎么快速定位 MySQL 慢查询在哪个表、哪条语句
宝塔面板本身不直接分析 SQL 执行计划，得靠 MySQL 自带的 slow_query_log 和 mysqldumpslow 配合看。先确认慢日志开了没——进宝塔「数据库」→「配置修改」，搜 slow_query_log，它得是 ON；再看 long_query_time，默认 10 秒太宽松，线上建议调成 1 或 0.5（单位秒）。
常见错误现象：slow_query_log_file 路径权限不对，MySQL 启动后日志写不进去，但面板里显示“已开启”；或者日志文件被 logrotate 清空了，却没重启 MySQL，导致新慢查不记录。
- 用
SHOW VARIABLES LIKE 'slow_query_log%';现场验证开关和路径 - 日志路径通常在
/www/server/data/mysql-slow.log，用tail -f /www/server/data/mysql-slow.log实时盯几分钟 - 别直接打开大日志文件，用
mysqldumpslow -s at -t 10 /www/server/data/mysql-slow.log按平均耗时排前 10 条
EXPLAIN 看不懂？重点盯这三个字段就够了
在宝塔「phpMyAdmin」或命令行执行 EXPLAIN SELECT ...，不是看整张表，只盯 type、key、rows 这三列——它们直接暴露索引是否生效、扫了多少行。
使用场景：比如查用户订单，WHERE user_id = ? AND status = ? ORDER BY created_at DESC，但 EXPLAIN 显示 type: ALL、key: NULL、rows: 248912，说明完全没走索引，全表扫描。
-
type是ALL或index→ 基本没走有效索引，优先优化 -
key是NULL→ 当前查询没命中任何索引，哪怕表上有索引也白搭 -
rows数值远大于实际返回行数（比如查 1 条却扫 10 万行）→ 索引区分度差或条件没用上索引列顺序
建复合索引时，字段顺序为什么不能随便换
MySQL 的 B+ 树索引是按定义顺序逐列排序的，INDEX (a, b, c) 能加速 WHERE a=1、WHERE a=1 AND b=2、WHERE a=1 AND b=2 AND c=3，但对 WHERE b=2 或 WHERE c=3 完全无效。
性能影响：错序的复合索引不仅没用，还会拖慢 INSERT/UPDATE，因为每次写入都要维护多一倍的索引树节点。
- 把等值查询字段放最左（如
user_id），范围查询字段（如created_at > '2024-01-01'）放右边 - ORDER BY 字段如果和 WHERE 共用，必须严格匹配索引顺序，否则无法避免
Using filesort - 别为每个字段单独建单列索引，
INDEX(a)+INDEX(b)≠INDEX(a,b)，后者才能覆盖联合查询
宝塔里改完索引，为什么慢查还在继续
加了索引不等于立刻生效——旧查询计划可能还缓存在 MySQL 的 query cache（已弃用）或 prepared statement 缓存里；更常见的是应用层用了连接池，复用的老连接没重解析 SQL。
容易踩的坑：ALTER TABLE ADD INDEX 成功后，误以为万事大吉，但没检查该索引是否被真正用上；或者索引建了，但查询里用了函数包裹字段，比如 WHERE DATE(created_at) = '2024-01-01'，导致索引失效。
- 强制刷新执行计划：执行
SELECT * FROM table_name WHERE ...前，先跑一次EXPLAIN确认key列非NULL - 检查是否有隐式类型转换：
WHERE user_id = '123'（字符串）对比INT字段，会丢索引 - 宝塔「数据库」→「性能调整」里如果开了
query_cache_type，建议关掉，MySQL 5.7+ 默认已禁用，留着反而干扰
索引不是加得越多越好，每多一个索引，INSERT 就多一次 B+ 树分裂；真正难的不是建索引，是判断哪条慢查值得优化、哪条只是偶发抖动——得结合 slow_query_log 的频次和 EXPLAIN 的 rows 值一起看。
