触发器不能直接监控QPS，因其仅响应单条DML语句，无法感知单位时间内的语句总数；QPS统计必须依赖外部采样（如mysqladmin extended-status）与阈值比对，触发器仅可作为告警写入的执行单元。
触发器不能直接监控QPS，必须换思路
QPS是单位时间内的语句总数，而触发器只响应单条DML（INSERT/UPDATE/DELETE），它本身不感知“每秒多少次”。想用触发器“监控QPS异常波动”，本质是误用了触发器的定位——它适合记录变更事件、打点耗时、写审计日志，但不适合做速率统计。真要捕获QPS突增或骤降，得靠外部采样+阈值比对，触发器最多当“告警执行器”。
用触发器作为QPS异常的落地执行单元
你可以让外部脚本（比如每5秒跑一次的Shell）计算出 Questions 差值，发现QPS超过阈值（如 > 200）后，调用一个存储过程，由该存储过程触发写入告警日志——这个写入动作可以封装在触发器里，但不是由数据变更触发，而是由显式 INSERT INTO alert_log 触发。
- 先建一张告警表：
CREATE TABLE alert_log (id INT AUTO_INCREMENT PRIMARY KEY, trigger_time DATETIME, qps_value DECIMAL(10,2), reason VARCHAR(100)) - 再建一个AFTER INSERT触发器，仅负责格式化落库、加时间戳、写入归档路径等固定动作，不参与判断逻辑
- 判断QPS是否异常、要不要告警，必须放在外部：比如Shell脚本里用
mysqladmin extended-status -r -i5拿差值，算完再决定是否执行INSERT INTO alert_log (qps_value, reason) VALUES (248.6, 'QPS surge')
为什么不能在触发器里统计QPS？
触发器每次只看到一条语句，无法知道“这一秒总共来了多少条”。即使你在BEFORE INSERT里查 SHOW GLOBAL STATUS LIKE 'Questions'，也只会得到累计值；两次查询之间没有可靠的时间锚点，且并发下多个触发器实例会互相干扰计数器读取。
-
Questions是全局变量，触发器内读它不保证原子性，不同连接看到的值可能错位 - 触发器执行期间MySQL会禁用部分状态更新，
Questions在触发器内部不会自增，导致读到旧值 - 如果用临时表存“当前秒计数”，需加锁或用
GET_LOCK()，但高并发下极易阻塞主业务，违背监控初衷
真正可行的轻量级替代方案
与其硬套触发器，不如用更稳、更透明的方式把QPS异常和关键表关联起来：
- 用
performance_schema.events_statements_summary_by_digest查最近1分钟内访问关键表（如orders）的SQL频次，按SUM(COUNT_STAR)排序，直接定位哪类语句拖高了QPS - 在外部采集脚本中加条件：当总QPS超标 &&
Com_select增量中来自orders表的占比 > 70%，才写入告警，并附上 top SQL 的DIGEST_TEXT - 若必须留痕到表，直接
INSERT INTO qps_alert_history即可，不需要触发器绕一圈——多一层触发器反而增加延迟和失败风险
触发器适合干的事是：某行被删了就记一笔、某字段被改了就发MQ、某状态变成‘paid’就更新关联表。拿它算QPS，就像用温度计测风速——工具和问题根本不对口。
