mysql 8.0 无法关闭锁监控，因 innodb_row_lock% 状态变量是轻量级内存计数器；真正需处理的是误配的 query_cache_type（导致启动失败）、长事务及锁争用问题。
MySQL 8.0 中没有“关闭锁监控”的配置项——锁监控本身不消耗可观资源，真正该关的是查询缓存（但它在 8.0 已被物理删除），而你实际想优化的，很可能是锁争用或无效监控行为。
SHOW STATUS LIKE 'innodb_row_lock%' 不可禁用，也不该禁用
这个命令读取的是 InnoDB 内置的计数器，属于轻量级状态统计，不触发锁、不扫描数据、不产生额外开销。它只是返回内存中已有的聚合值。
-
innodb_row_lock_waits、innodb_row_lock_time等变量由引擎自动维护，无法关闭或禁用 - 试图通过配置项屏蔽它们（如
performance_schema相关开关）会影响其他关键诊断能力，得不偿失 - 如果你发现执行
SHOW STATUS本身变慢，问题不在锁监控，而在服务器负载高或连接数过多
真正该检查和关闭的：query_cache_type 配置会直接导致 MySQL 8.0 启动失败
很多运维仍沿用 5.7 习惯，在 my.cnf 里保留 query_cache_type = 0，这在 8.0+ 是致命错误。
- MySQL 8.0 源码中已彻底移除所有 query_cache 相关变量，启动时遇到
query_cache_type或query_cache_size会报错：Unknown system variable 'query_cache_type' - 哪怕只写了一行，也会导致 mysqld 拒绝启动，日志里找不到明显提示，容易误判为配置语法错误
- 验证方法：执行
SELECT @@global.query_cache_type;—— 会直接报错，不是返回 NULL 或 0
KILL TRANSACTION 不是“关锁”，而是终止事务释放锁
有人把 KILL TRANSACTION xxx 理解成“关闭某个锁”，这是概念混淆。InnoDB 没有独立的“锁对象”可被单独关闭。
-
KILL TRANSACTION实际作用是强制回滚指定事务，从而释放它持有的所有行锁、间隙锁、MDL 锁等 - 必须配合
SELECT * FROM performance_schema.events_transactions_current WHERE STATE = 'ACTIVE'或INFORMATION_SCHEMA.INNODB_TRX找到真正阻塞源，不能凭Command: Sleep就杀 - 对
State: Sleep的连接执行KILL只是断开连接，不涉及锁释放——除非它正持有一个未提交的长事务
唯一可调的“锁相关监控开关”是 performance_schema 中的事件采集
如果你真想降低监控粒度，只能关掉 performance_schema 里某些锁事件的记录，但需明确代价：
- 关闭
wait/lock/table/sql/handler可减少 MDL 锁等待跟踪，但将丢失表级阻塞链路（比如 ALTER TABLE 被卡住时无法定位源头） - 关闭
wait/lock/instrumented会影响所有锁等待分析，sys.innodb_lock_waits视图将返回空 - 操作示例：
UPDATE performance_schema.setup_consumers SET ENABLED = 'NO' WHERE NAME = 'events_waits_current'; - 注意：
setup_consumers修改是动态生效的，但已有等待事件不会补录，重启后恢复默认开启
最容易被忽略的一点：所谓“锁监控资源占用”，99% 情况下是误判。真正吃资源的是长事务、未提交的 UPDATE、低效索引导致的锁范围过大——盯住 INNODB_TRX 里 trx_started 时间早于 10 秒的记录，比纠结关不关监控实在得多。
