关键表访问告警需绑定表名、扫描行数激增、查询频次异常三要素，否则90%为误报或漏报；单用show processlist或slow_query_log均不足，须结合pt-query-digest、prometheus+mysqld_exporter及shell脚本多维监控。
直接上结论：关键表访问告警不能只盯“慢查询”，得绑定具体表名 + 扫描行数激增 + 查询频次异常这三要素，否则90%的告警都是误报或漏报。
为什么 SHOW PROCESSLIST 和 slow_query_log 单独用都不够
SHOW PROCESSLIST 只能抓当前活跃会话，查完就丢，没法回溯“过去5分钟 orders 表被扫了37万行”；slow_query_log 默认不记录表名和扫描行数（MySQL 8.0+ 要开 log_slow_extra），且 long_query_time=1.0 会漏掉大量“快但伤表”的高频小查询——比如每秒20次全表扫描 user_profiles，单次才 80ms。
常见错误现象：
- 告警一响，发现是定时脚本在查
backup_log表，不是业务表 - 慢日志里全是
SELECT <em> FROM xxx WHERE id = ?</em>，但真正拖垮实例的是没走索引的SELECT COUNT() FROM orders WHERE status = 'pending' - Prometheus 里的
mysql_global_status_slow_queries在涨，但不知道哪张表在扛压
所以必须把“表级访问强度”从日志和指标里显式抠出来。
用 pt-query-digest 提取关键表的高危查询模式
pt-query-digest 是唯一能把原始慢日志映射到具体表、并量化危害程度的工具。重点不是看“最慢那条”，而是筛出：
-
--filter '$event->{db} && $event->{db} =~ m/^prod_/i && $event->{fingerprint} =~ m/\bFROM\s+(orders|user_profiles|transactions)\b/i'
（限定生产库 + 关键表名，避免测试噪音） -
--limit 50%查累计耗时占比，常发现前3类查询占总慢查时间68%以上 - 看
Rows_examined列：如果某条SELECT的Rows_examined是Rows_sent的 200 倍，基本就是全表扫描
容易踩的坑：
- 不加
--filter直接跑，结果被information_schema或sys库的元数据查询刷屏 - 忽略
Rows_examined，只盯着响应时间，错过“快但脏”的索引失效查询 - 用默认
--report，漏掉# Query 2这种“平均慢+高频”组合（比# Query 1危险得多）
Prometheus + mysqld_exporter 抓表级扫描行数突增
mysqld_exporter 默认不暴露单表扫描量，必须启用收集器：
- 启动时加参数：
--collect.info_schema.innodb_tablestats（MySQL 5.7+）或--collect.info_schema.tablestats（8.0+） - 然后就能拿到指标：
mysql_info_schema_innodb_table_rows{table="orders", db="prod_orders"}
告警规则要写成这样，而不是笼统的“慢查询变多”：
# orders 表5分钟内扫描行数增长超10万，且非备份窗口
(delta(mysql_info_schema_innodb_table_rows{table="orders", db="prod_orders"}[5m]) > 100000)
and on (instance) (hour() not in (2,3,4)) # 避开凌晨备份
性能影响注意点：
-
info_schema.tablestats查询本身有轻微开销，别设成10s抓一次，30s–60s足够 - 如果表太多（>5000），考虑用
--collect.info_schema.processlist配合过滤，替代全量tablestats
Shell 脚本兜底：当 Prometheus 掉线时还能发告警
不要依赖单一链路。写个轻量脚本，每分钟查一次关键表的实时扫描压力：
TABLE="orders" DB="prod_orders" # 查最近1分钟内对该表的全表扫描次数（需提前建好performance_schema配置） SCAN_COUNT=$(mysql -N -s -e "SELECT COUNT(*) FROM performance_schema.events_statements_summary_by_digest WHERE DIGEST_TEXT LIKE '%FROM \`$TABLE\`%' AND ROWS_EXAMINED > 10000 AND LAST_SEEN > DATE_SUB(NOW(), INTERVAL 1 MINUTE);" "$DB") if [ "$SCAN_COUNT" -gt 5 ]; then echo "$(date): ALERT: $TABLE scanned >10k rows $SCAN_COUNT times in 1min" | logger -t mysql-table-alert # 这里加 curl 发钉钉 / 企业微信 fi
关键细节：
- 依赖
performance_schema.events_statements_summary_by_digest，需提前开：UPDATE performance_schema.setup_consumers SET ENABLED = 'YES' WHERE NAME = 'events_statements_digest'; -
ROWS_EXAMINED > 10000是硬门槛，比“是否走索引”更客观（有些索引范围扫描也扫几万行） - 不查
SHOW PROCESSLIST，因为它是瞬时快照，无法统计“频次”
真正难的不是技术落地，而是定义清楚：哪几张表算“关键”、什么程度的扫描算“异常”、谁该在几点收到哪类告警。这些必须和业务方对齐，而不是 DBA 自己拍阈值。比如 orders 表白天允许每分钟扫5万行，但凌晨备份期间扫100万行是正常的——告警规则里不体现这个上下文，再准的指标也会天天吵醒人。
