必须先启用performance_schema及wait/lock/innodb%相关instrument，再通过JOIN data_locks与threads表按THREAD_ID分组统计锁实例数并排序取Top 10，WHERE过滤NULL PROCESSLIST_ID以排除后台线程，GROUP BY需包含所有非聚合字段，结果lock_count为锁实例数而非锁对象数。
查 performance_schema.data_locks 前先确认锁采集已开启
很多用户执行 SELECT * FROM performance_schema.data_locks 返回空或只有几行，不是 SQL 写错了，而是锁数据根本没被采集。必须同时满足三个条件：
-
@@performance_schema值为ON -
performance_schema.setup_consumers中global_instrumentation和thread_instrumentation都是YES -
performance_schema.setup_instruments里所有wait/lock/innodb%相关项的ENABLED列必须是YES；若为NO，仅靠 SQL 动态更新无效，需在my.cnf加performance-schema-instrument='wait/lock/innodb%=ON'并重启
用 data_locks 按线程统计锁实例数，而非“锁对象”
data_locks 表里每条记录是一个锁实例（比如同一行上的主键锁 + 二级索引锁 + 间隙锁会算作三条），COUNT(*) 统计的是这个数量，不是“事务持有几个锁对象”。标准查询如下：
SELECT t.PROCESSLIST_ID AS `id`,
t.PROCESSLIST_USER AS `user`,
t.PROCESSLIST_HOST AS `host`,
t.PROCESSLIST_DB AS `db`,
COUNT(*) AS `lock_count`
FROM performance_schema.data_locks dl
JOIN performance_schema.threads t ON dl.THREAD_ID = t.THREAD_ID
WHERE t.PROCESSLIST_ID IS NOT NULL
GROUP BY t.THREAD_ID, t.PROCESSLIST_ID, t.PROCESSLIST_USER, t.PROCESSLIST_HOST, t.PROCESSLIST_DB
ORDER BY lock_count DESC
LIMIT 10;注意：GROUP BY 必须包含所有非聚合字段，否则 MySQL 8.0 严格模式直接报错；WHERE t.PROCESSLIST_ID IS NOT NULL 是为了过滤掉后台线程（如 thread/innodb/io_thread）
结合 INNODB_TRX 看事务持续时间与锁状态
data_locks 告诉你谁拿了锁、拿了多少，但不告诉你这个事务跑了多久、是否卡在锁等待上。此时要补查 INFORMATION_SCHEMA.INNODB_TRX：
-
trx_state = 'LOCK WAIT'表示该事务正因拿不到锁而挂起，需立刻结合INNODB_LOCK_WAITS查阻塞链 -
trx_started和trx_wait_started的时间差能判断锁等待了多久 -
trx_rows_locked是粗略估算值（InnoDB 不实时精确统计），不能替代data_locks的实际锁实例数
别把锁资源和内存占用混为一谈
MySQL 中“锁”本身不直接吃内存——锁元数据（data_locks 记录）只占 KB 级内存，真正影响内存的是长事务拖住的 Undo Log 和未释放的 read view。如果你看到内存飙升且伴随大量锁，大概率是以下组合问题：
- 活跃事务数多 →
Threads_connected高 +INNODB_TRX中trx_state = 'RUNNING'的事务持续超 60 秒 - Undo 表空间
ALLOCATED_SIZE接近FILE_SIZE且长期不收缩 → 执行SELECT NAME, STATE, ALLOCATED_SIZE, FILE_SIZE FROM INFORMATION_SCHEMA.INNODB_TABLESPACES WHERE SPACE_TYPE = 'Undo';验证 - 错误日志中频繁出现
Lock wait timeout exceeded或Deadlock found→ 说明锁争用已传导到业务层
锁统计只是表象入口，背后真正要压下去的，往往是未提交的事务、缺失的索引导致的锁范围扩大，或者隔离级别过高引发的间隙锁膨胀。
