<p>执行 SELECT * FROM sys.user_summary 报错“references invalid table(s)”主因是缺失 sys.format_bytes 函数或 EXECUTE 权限，需先验证函数存在性、授权或重装 sys 库；真正反映账号风险的是 current_memory、table_scans、file_io_latency 和 statement_avg_latency 等资源消耗指标；分析须用 x$user_summary 做数值过滤排序，并关联 PROCESSLIST 定位具体会话。</p>
查 user_summary 前先确认权限和视图可用性
直接执行 SELECT * FROM sys.user_summary 报错 View 'sys.xxx' references invalid table(s) or column(s) or function(s) 很常见，不是语句写错了，而是底层依赖缺失。最典型的是 sys.format_bytes 函数不存在——这个函数被多个带单位格式化的视图（如 user_summary、memory_global_total）调用。
验证方式很简单：
- 用同个账号手动执行
user_summary的原始定义 SQL（可通过SHOW CREATE VIEW sys.user_summary查到），看是否卡在sys.format_bytes(...) - 检查该用户是否有
EXECUTE权限：SHOW GRANTS FOR CURRENT_USER，缺了就加：GRANT EXECUTE ON FUNCTION sys.format_bytes TO 'your_user'@'%' - 如果函数真没了，别折腾授权，直接重建
sys库（MySQL 自带脚本sys_schema.sql可重装）
user_summary 里哪些字段真正反映账号风险
别只盯着 statements（执行语句数）或 total_connections（总连接数）——这两个值高未必代表危险，可能是定时任务或健康检查流量。真正值得警觉的是资源消耗型指标：
-
current_memory：当前内存占用，单位是易读格式（如85.34MiB）。单个用户持续占 >100MiB 就该查会话了 -
table_scans：全表扫描次数。如果某用户占比超全局 30%，且statement_avg_latency> 100ms，大概率存在未加索引的慢查询 -
file_io_latency：I/O 等待总时长。突然飙升（比如从秒级跳到分钟级）往往对应大结果集导出或误操作 -
statement_avg_latency：平均语句延迟。超过 500ms 且current_connections> 1，说明有长事务或锁等待在拖慢整体响应
用 x$user_summary 做精确排序和阈值过滤
user_summary 是人眼友好版，所有数值都经过格式化；但排序、WHERE 条件、聚合计算必须用原始数据视图 x$user_summary，否则会因字符串比较出错（比如 '1.2GiB' > '512MiB' 永远为 false）。
例如，快速揪出内存占用前 3 的活跃账号：
SELECT user, current_memory, statement_avg_latency FROM sys.x$user_summary WHERE current_connections > 0 ORDER BY current_memory DESC LIMIT 3;
注意点：
-
current_memory在x$视图里是字节数（如89381384），可直接参与数值运算 -
statement_avg_latency单位是皮秒（picosecond），除以1000000000000才是秒，别直接当秒用 - 过滤条件必须写在
WHERE，不能靠应用层后过滤——x$视图本身不带索引，全表扫成本高
关联 processlist 定位具体会话
user_summary 只告诉你“谁有问题”，不告诉你“哪个会话在作怪”。这时候要结合 sys.session 或原生 INFORMATION_SCHEMA.PROCESSLIST：
比如发现 admin 用户 table_scans 异常高，立刻查它的活跃会话：
SELECT ID, USER, HOST, TIME, STATE, INFO FROM INFORMATION_SCHEMA.PROCESSLIST WHERE USER = 'admin' AND COMMAND != 'Sleep' ORDER BY TIME DESC;
关键细节：
- 优先看
STATE是Sending data还是Locked，前者大概率是大结果集扫描，后者是锁冲突 -
INFO字段可能被截断，用SELECT TRIM(TRAILING '\0' FROM INFO)清理脏字符 - 如果
PROCESSLIST为空但user_summary数据还在涨，说明是短连接高频请求，得去慢日志或events_statements_summary_by_user_by_event_name查明细
真正难的不是查出哪个用户数值高，而是判断这个高到底是业务增长、配置错误，还是攻击行为。比如 current_connections 高，得区分是连接池没复用，还是被恶意建连；file_io_latency 高，得看是读多还是写多，再对应查磁盘 I/O 负载。这些上下文，user_summary 不会告诉你，得自己补。
