innodb_purge_threads 设置多少才合理
MySQL 5.6+ 默认是 1，但多数生产环境需要调高 —— 不是因为“越多越好”，而是 purge 线程跟不上 DML 压力时，ibdata1 文件会持续膨胀、历史版本堆积导致 SELECT 变慢、甚至触发 Lock wait timeout exceeded。
实操建议：
- 观察
SHOW ENGINE INNODB STATUS\G中的PURGE PROCESSED和HISTORY LIST LENGTH：如果后者长期 > 10000，说明 purge 落后 - 写密集场景（如高频 DELETE/UPDATE）建议设为 2～4；纯读场景保持 1 即可
- 不要设 > 8：线程间锁竞争反而降低 purge 效率，且可能挤占 buffer pool 刷脏页资源
- 必须配合
innodb_purge_batch_size（默认 300）一起调优；增大线程数时，可同步把 batch_size 提到 500～1000，但别超 2000
动态修改 innodb_purge_threads 的风险点
这个参数支持在线修改（SET GLOBAL innodb_purge_threads = N），但不是“改完立刻生效”——它只影响下一次 purge 循环启动的新线程，旧线程不会被回收，也不会立即终止。
常见错误现象：
- 执行
SET GLOBAL后查SHOW VARIABLES LIKE 'innodb_purge_threads'显示已变，但SHOW PROCESSLIST里看不到新增线程 → 实际要等当前 purge batch 结束后才拉起新线程 - 从 4 改回 1，旧的 3 个 purge 线程仍会跑完当前任务，可能持续几分钟 → 不是配置失效，是设计如此
- MySQL 5.7.20 之前存在 bug：
SET GLOBAL后若立即重启，配置会丢失（因为没写入 my.cnf）
为什么 purge 线程卡住会导致 SELECT 变慢
这不是线程“挂了”，而是历史版本（undo log）没及时清理，导致 MVCC 快照链过长。InnoDB 在做 SELECT 时，要沿着 undo 链往前找可见版本，链越长，扫描开销越大。
典型表现：
-
SHOW ENGINE INNODB STATUS\G里HISTORY LIST LENGTH持续上涨（> 50000 就很危险） - 慢查询日志中大量简单
SELECT * FROM t WHERE id = ?出现，执行时间波动大 -
INFORMATION_SCHEMA.INNODB_TRX里有长时间未提交的事务（哪怕只是空闲连接），会拖住 purge 进度
注意：innodb_purge_threads 本身不解决长事务问题，它只加速清理；真正要治本，得查 trx_started 时间过长的事务并干预。
my.cnf 里配置 innodb_purge_threads 的注意事项
必须放在 [mysqld] 段下，且不能加引号或单位（比如不能写 innodb_purge_threads = "4" 或 innodb_purge_threads = 4s）。
容易踩的坑：
- 配置文件里写了但 MySQL 启动后没生效 → 先确认是否拼错成
innodb_purge_thread（少 s）或innodb_purge_workers（5.7+ 已废弃） - 用 Docker 启动时，环境变量覆盖了 my.cnf（如
MYSQL_INNODB_PURGE_THREADS=4不合法，Docker 官方镜像不识别这种变量） - Percona Server 或 MariaDB 对该参数名/行为有差异：MariaDB 10.3+ 改用
innodb_purge_rseg_truncate_frequency配合控制，别直接套用
最稳妥的做法：先在 my.cnf 设值，启动后立刻执行 SELECT @@innodb_purge_threads 核对，再观察 status 输出里的 purge 线程数量和 history list 变化趋势。
