sys Schema是Performance Schema的可读化封装，能直接定位全表扫描表、未用索引、锁等待及高毛刺SQL，但依赖performance_schema启用与消费者配置。
sys Schema不是万能诊断器，但它能把Performance Schema里杂乱的原始数据变成可读结论——直接告诉你“哪张表在全表扫描”“哪个SQL最拖慢系统”，而不是让你自己算平均延迟。
查全表扫描：哪些表正在被暴力遍历
全表扫描是I/O瓶颈最常见源头，sys.schema_tables_with_full_table_scans会直接列出当前库中所有存在全表扫描行为的表，连WHERE条件都没用上那种。
- 执行前确保
performance_schema已启用（MySQL 5.6+默认开），否则视图返回空 - 结果里的
table_schema和table_name字段要重点看，别只盯着rows_full_scanned数值——哪怕单次扫10行，如果每秒执行100次，照样压垮磁盘 - 如果某张小表（比如
user_config）也出现在结果里，大概率是没加索引的WHERE status = ?查询，不是数据量问题，是SQL写法问题
找未用索引：别让索引躺在那里吃灰
sys.schema_unused_indexes列出的是长期没被任何查询命中的索引，不是“没被优化器选中”的索引——后者可能是正常情况（比如覆盖索引更优），前者才是真冗余。
- 删除前先用
SHOW INDEX FROM table_name核对索引字段和类型，避免误删唯一约束或外键依赖的索引 - 注意
schema_name和index_name字段，有些索引名带前缀（如idx_2024_status），得结合业务确认是否已下线 - 执行
DROP INDEX idx_name ON table_name后，观察Innodb_buffer_pool_read_requests是否下降——如果没变，说明这索引本来就没被用过
看锁等待：谁在堵住别人
sys.schema_lock_waits把performance_schema里分散的锁等待事件聚合成“谁等谁、等多久、等什么资源”的直观视图，比手动JOIN一堆表快得多。
- 重点关注
waiting_trx_id和blocking_trx_id列，直接对应INFORMATION_SCHEMA.INNODB_TRX里的事务ID，可快速定位阻塞源头 -
waiting_lock_mode为X（排他锁）且blocking_lock_mode也是X时，大概率是两个UPDATE语句在更新同一行，不是死锁但持续阻塞 - 该视图不包含历史锁信息，只反映当前活跃等待，需配合
SELECT * FROM performance_schema.events_statements_current查阻塞方正在执行的SQL
抓最耗时SQL：别只看平均延迟
sys.statement_analysis按DIGEST_TEXT聚合相同模式SQL，给出avg_latency和max_latency——后者往往比前者高10倍以上，意味着某次执行因锁或I/O卡顿严重。
- 排序用
ORDER BY max_latency DESC比avg_latency更有效，能暴露偶发性毛刺 -
exec_count低于10但max_latency极高，通常是大事务或跨分片JOIN导致，不是优化单条SQL能解决的 - 结果里的
DIGEST_TEXT会被截断，需用SELECT DIGEST, DIGEST_TEXT FROM performance_schema.events_statements_summary_by_digest查完整SQL
sys Schema的视图本质是预定义查询，它不采集新数据，只加工performance_schema已有内容。如果你发现某个视图始终为空，第一反应不是“工具坏了”，而是检查setup_consumers里对应消费者是否启用——比如statements_digest关了，statement_analysis就永远没数据。
