云数据库默认禁用performance_schema锁表访问，需通过innodb_trx查lock wait事务，并结合processlist、慢日志及应用日志交叉定位阻塞源头。
云数据库（如阿里云RDS、腾讯云CDB、AWS RDS）默认禁用或限制直接访问 INFORMATION_SCHEMA 和 performance_schema 中的锁相关表，导致你执行 SELECT * FROM performance_schema.data_locks 时返回空或报错 —— 这不是你的SQL写错了，是权限/配置被云厂商主动阉割了。
为什么云数据库不让查 data_locks 和 data_lock_waits
云厂商出于安全与资源隔离考虑，通常会：
- 关闭 performance_schema 的部分 instrument（如 wait/lock/innoDB）
- 移除普通账号对 performance_schema 表的 SELECT 权限（即使你有 SUPER 权限也不行）
- 禁用 SHOW ENGINE INNODB STATUS 中的 LOCK INFO 部分（只保留 TRANSACTIONS 和 BUFFER POOL）
- 不允许修改 innodb_status_output_locks 等参数
替代方案：用云平台提供的监控指标 + 有限 SQL 组合定位锁问题
你无法直接看“谁锁了谁”，但可以交叉验证以下三类可观测信号：
- 云控制台的“锁等待数”和“活跃事务数”曲线：突增即代表锁堆积，结合时间点反查应用日志
-
慢查询日志中带
FOR UPDATE或LOCK IN SHARE MODE的语句：它们是锁争用高发点，尤其 WHERE 条件未走索引时 -
手动触发
SELECT * FROM INFORMATION_SCHEMA.INNODB_TRX（多数云环境仍开放此表）：能拿到TRX_STATE = 'LOCK WAIT'的事务、TRX_MYSQL_THREAD_ID、TRX_QUERY和等待时长TRX_WAIT_STARTED
例如发现某事务卡在 UPDATE order SET status='paid' WHERE user_id=12345 超过 30 秒，就说明该行被另一个未提交事务持有了排他锁 —— 此时去查应用侧是否有个漏掉 COMMIT 的订单支付流程。
如何让 INNODB_TRX 输出更有效信息
云数据库虽限制多，但 INNODB_TRX 仍是唯一可用的实时事务视图。关键在于补充关联信息：
- 用
TRX_MYSQL_THREAD_ID去查information_schema.PROCESSLIST，获取对应连接的USER、HOST、TIME和完整INFO（注意：部分云环境会截断INFO字段） - 用
TRX_ID关联performance_schema.events_statements_current（若开放），看该事务最后执行的语句 - 对长时间
TRX_STATE = 'RUNNING'的事务，检查其TRX_ROWS_LOCKED是否异常高（>1000 行常意味着全表扫描加锁） - 避免依赖
TRX_WEIGHT：云环境该字段常为 0 或不可信，不建议用于排序
真正难的不是“看不到锁”，而是云环境把上下文（如阻塞者线程、锁对象地址、索引名）全藏起来了。所以必须把数据库信号和应用层日志、链路追踪 ID 对齐 —— 比如发现某个 TRX_QUERY 在等锁，立刻去查对应 traceID 的服务日志里，上一步是不是刚执行完一个没提交的 BEGIN。
