MySQL大量Sleep进程通常不是问题根源，真正瓶颈是未结束的Query长连接或未走索引的高频查询；应开启慢查询日志、用mysqldumpslow分析、结合EXPLAIN优化索引，并调优连接池与缓存配置。
查 MySQL 进程列表时 SHOW PROCESSLIST 显示大量 Sleep 状态？别急着杀进程
这通常不是问题本身，而是表象。真正拖慢 MySQL、推高 CPU 的，往往是那些没结束的 Query 状态长连接，或者频繁执行但没走索引的语句。宝塔面板自带的“慢日志”开关默认关闭，光看进程列表容易漏掉执行快但频率极高的劣质查询。
实操建议：
- 先在宝塔「数据库」→「性能优化」里打开
慢查询日志，设置long_query_time = 1（单位秒），并确认日志路径是/www/server/mysql/log/slow-query.log - 用命令实时观察活跃查询：
mysql -uroot -p -e "SHOW FULL PROCESSLIST;" | grep -E "(Query|State)"，重点关注Time列 >5 秒且Info非空的行 - 避免直接
KILL大量Sleep进程——它们可能是应用连接池维持的正常空闲连接，杀完会立刻重建，还可能引发应用重连风暴
从慢日志里提取真实慢查询，用 mysqldumpslow 快速归类
手动翻 slow-query.log 效率低，且重复 SQL 被打散成多条，看不出模式。宝塔环境默认已安装 mysqldumpslow，它是比正则 grep 更可靠的聚合工具。
实操建议：
- 执行：
mysqldumpslow -s at -t 10 /www/server/mysql/log/slow-query.log，按平均执行时间倒序取前 10 类 - 重点看输出中带
Count高、Time长、且Query_plan里含Using filesort或Using temporary的条目——这些基本等于没走好索引 - 注意区分：同一条 SQL 因参数不同被记录多次，
mysqldumpslow会自动参数化（如把WHERE id=123归为WHERE id=N），更易识别共性瓶颈
EXPLAIN 执行计划里出现 type=ALL 或 rows 远超表总行数？马上建索引
type=ALL 是全表扫描信号灯，哪怕表只有 1 万行，QPS 高了 CPU 也会顶不住。但不是所有 WHERE 字段都适合建索引——顺序、选择性、覆盖度都得看。
实操建议：
- 对慢日志中定位到的 SQL，用
EXPLAIN FORMAT=TRADITIONAL SELECT ...确认扫描行数和实际用到的索引 - 优先给
WHERE条件中最左前缀字段建联合索引，例如WHERE status=1 AND created_at > '2024-01-01'，建INDEX idx_status_created (status, created_at)比单建created_at有效得多 - 避免在低选择性字段（如
gender只有 'M'/'F'）上单独建索引；若必须过滤，考虑加到联合索引后部，而非开头 - 建索引后务必验证：
EXPLAIN中rows应明显下降，type提升到ref或range，且Extra不再含Using filesort
宝塔下 MySQL 配置调优不能只改 my.cnf，要同步检查连接池与查询缓存
很多用户调完 innodb_buffer_pool_size 就以为搞定，结果发现 CPU 还是高——其实应用层连接没控住，或 MySQL 自身查询缓存（Query Cache）在高并发下反而成负担。
实操建议：
- 在宝塔「数据库」→「配置修改」里，确认
query_cache_type = 0（MySQL 8.0+ 已移除，但宝塔装的 5.7 默认可能开着），开启反而增加锁竞争 - 检查应用连接池配置（如 PHP 的
mysqlnd或 PDO 的mysql.allow_persistent），避免短连接滥用；宝塔 PHP 设置里可调max_children限制并发数 -
wait_timeout和interactive_timeout建议设为60～120，防止空闲连接长期占着线程资源 - 修改配置后必须重启 MySQL（宝塔界面点「重启」），仅重载配置（
service mysqld reload）不生效部分参数
索引不是越多越好，一个表超过 5 个二级索引就要警惕维护开销；而最常被忽略的是：慢查询往往藏在业务低峰期批量任务里，比如凌晨 3 点跑的统计脚本——它不卡前台，但 CPU 占满一整夜。排查时记得看时间维度，别只盯白天流量高峰。
