普通用户默认无权访问performance_schema库；mysql禁止对performance_schema库使用grant授权；云数据库基本禁用data_locks等锁表且无法启用；本地部署需root配置参数、开启采集器并授部分视图权限。
普通用户默认无权访问performance_schema库
MySQL启动时自动创建performance_schema系统库，但它的表（如session_variables、data_locks）默认只对root或拥有SUPER权限的用户开放。普通用户即使能连上数据库，执行SELECT * FROM performance_schema.session_variables也会报错ERROR 1146 (42S02): Table 'performance_schema.session_variables' doesn't exist——这不是表真没了，而是权限不足导致该库在当前会话中“不可见”。
GRANT无法直接授权performance_schema表级权限
你不能用GRANT SELECT ON performance_schema.* TO 'user'@'%'这类语句成功授权。MySQL明确禁止对performance_schema、information_schema和sys库使用GRANT语法，强行执行会报错ERROR 1044 (42000): Access denied for user ... to database 'performance_schema'。这是硬性限制，不是配置疏漏。
云数据库环境下基本无解
阿里云RDS、腾讯云CDB等主流云服务默认禁用performance_schema锁相关表（data_locks、data_lock_waits），且不开放UPDATE performance_schema.setup_instruments权限。即使你有root账号，也无法启用锁采集器。此时唯一可用的是INFORMATION_SCHEMA.INNODB_TRX，但它的字段如TRX_WEIGHT在云环境常为0，TRX_QUERY也可能被截断。
本地部署可尝试的有限绕过方式
仅适用于你完全控制MySQL服务器（非云托管）且版本≥5.7：
- 确认
performance_schema已启用：SELECT @@performance_schema;返回1 - 检查关键参数是否为
0：SHOW VARIABLES LIKE 'performance_schema_max%_classes';，若全为0，需在my.cnf中补全（如performance_schema_max_mutex_classes = 200），重启生效 - 给用户加
SELECT权限仅对部分视图有效（如events_statements_summary_by_digest），但必须由root执行：GRANT SELECT ON performance_schema.events_statements_summary_by_digest TO 'user'@'%'; FLUSH PRIVILEGES; - 仍无法查
data_locks？说明wait/lock/%类采集器未启用，需root执行：UPDATE performance_schema.setup_instruments SET ENABLED='YES' WHERE NAME LIKE 'wait/lock/%';，且setup_consumers中对应项也要开
真正难的从来不是SQL怎么写，而是你根本不知道自己缺的是权限、配置、还是厂商的“功能阉割”。云数据库里连SHOW ENGINE INNODB STATUS都看不到LOCK INFO，这时候翻文档不如看控制台的“锁等待数”曲线。
