innodb_status_output 参数从 MySQL 8.0.13 起已被彻底移除，启动时若配置会触发“Unknown variable”警告但不崩溃；其功能由 innodb_status_output_locks 和 log_error_verbosity 协同替代，实际锁监控应依赖 SHOW ENGINE INNODB STATUS 或 performance_schema.data_locks/data_lock_waits。
innodb_status_output 参数在 MySQL 8.0+ 中已废弃
直接说结论：innodb_status_output 这个参数从 MySQL 8.0.13 开始被移除，不再存在。如果你在配置文件里写了它，MySQL 启动时会忽略并报 warning（Unknown variable 'innodb_status_output'），但不会崩溃。
它原本的作用是控制是否将 SHOW ENGINE INNODB STATUS 的输出写入错误日志，但这个行为已被更细粒度的 innodb_status_output_locks 和日志级别机制取代。
替代方案：用 innodb_status_output_locks + error log level 控制锁信息输出
真正影响锁监控内容的是这两个配合项：
-
innodb_status_output_locks=ON：让SHOW ENGINE INNODB STATUS在输出中包含当前所有事务持有的锁、等待的锁（即 LOCK WAIT 部分） - 错误日志是否记录该输出，取决于
log_error_verbosity和是否手动触发SHOW ENGINE INNODB STATUS
注意：innodb_status_output_locks 默认是 OFF，必须显式设为 ON 才能看到锁详情。仅靠调高日志等级（如 log_error_verbosity=3）并不会自动 dump 锁信息到 error log —— 它只影响常规错误/警告的详细程度，不触发 InnoDB 状态快照。
如何实际获取锁信息？别依赖自动日志，用 SHOW ENGINE INNODB STATUS + grep
生产环境最可靠、最常用的方式是主动执行命令，而不是指望参数“自动写入日志”：
- 连接 MySQL 后运行：
SHOW ENGINE INNODB STATUS\G（注意\G让输出可读） - 重点关注输出末尾的
TRANSACTIONS和LOCK WAIT小节 - 若需快速筛选锁等待，可结合 shell：
mysql -e "SHOW ENGINE INNODB STATUS\G" | grep -A 20 "LOCK WAIT" - MySQL 8.0.17+ 还支持
performance_schema.data_locks表，比SHOW ENGINE更结构化，但需确保performance_schema开启且相关 consumer 已启用（如setup_consumers中的events_transactions_current）
容易踩的坑：误以为开启某个参数就能“持续监控锁”
没有哪个参数能让 MySQL 持续、高频地把锁状态写进日志。InnoDB status 是快照，不是流式日志：
-
innodb_status_output_locks=ON只影响SHOW ENGINE输出内容，不改变其触发方式 - MySQL 不会定时自动执行
SHOW ENGINE INNODB STATUS并写日志 —— 这得靠外部脚本或监控工具（如 pt-deadlock-logger）轮询 - 频繁执行
SHOW ENGINE INNODB STATUS本身有性能开销（尤其高并发下），不建议间隔短于 5 秒 - error log 里即使看到 InnoDB status 输出，也只代表某次手动或内部诊断触发，不代表实时锁流
真要长期观察锁行为，优先用 performance_schema.data_locks + data_lock_waits 表查实时锁关系，再辅以定期抓取 SHOW ENGINE 做上下文快照。
