MySQL触发器不能调用存储过程发预警，因硬性限制禁止CALL、网络请求、写文件或发邮件；可靠方案是触发器仅写alert_event表，由外部服务拉取并通知。
MySQL里用触发器调用存储过程发预警，行不通
MySQL触发器不能执行CALL语句调用存储过程，也不能做网络请求、写文件或发邮件——这是硬性限制。你看到的“触发器+存储过程发通知”方案，99%是误传或混淆了数据库版本（比如把SQL Server当MySQL用了）。
常见错误现象：ERROR 1422: Explicit or implicit commit is not allowed in stored function or trigger，或者直接报TRIGGER cannot invoke stored procedures。
- 触发器只允许做简单数据校验、字段改写、插入日志表等副作用可控的操作
- 想“发预警”，必须把通知逻辑挪到应用层，或靠轮询+事件表+外部服务协同
- MySQL 8.0+虽支持
CREATE EVENT，但它和触发器无关，也不能响应单条DML实时触发
PostgreSQL可以用函数+触发器组合发通知，但得绕开事务锁
PostgreSQL支持在触发器里调用NOTIFY，这是它和MySQL最实际的差异点。但NOTIFY只是发个消息给监听客户端，不是发邮件/钉钉/短信——真要落地预警，还得配一个常驻进程收LISTEN并转发。
使用场景：订单状态变'shipped'时，通知下游物流系统；库存低于阈值时推消息给运营看板。
- 触发器函数里必须用
PERFORM pg_notify('alert_channel', payload_json::text)，不能用SELECT pg_notify(...)（会多返回结果集） - payload最好控制在8000字节内，超长会被截断，且
pg_notify不保证送达，只保证发出去 - 监听端要用
LISTEN alert_channel并保持连接，断连期间消息丢失——别指望它做可靠队列
SQL Server里用sp_send_dbmail发邮件预警，但默认禁用
SQL Server是少数能从触发器里“直接发通知”的主流数据库，靠sp_send_dbmail。但它默认关闭数据库邮件功能，而且一旦触发频繁，容易拖慢事务甚至填满msdb日志。
参数差异：@recipients必须是字符串，不能拼变量（防SQL注入），@body建议用CONCAT构造，别用+连空值（会变NULL）。
- 启用前先跑
EXEC sp_configure 'show advanced options', 1; RECONFIGURE，再开'Database Mail XPs' - 触发器里调用
sp_send_dbmail是同步阻塞的，INSERT卡住3秒，用户就等着——务必加IF UPDATE(status) AND (SELECT status FROM inserted) = 'failed'精准过滤 - 别在高并发表（如访问日志）上用，优先考虑用Service Broker异步解耦
真正靠谱的预警链路：数据库只埋点，其他交给外部服务
所有试图让数据库“自己发通知”的方案，最终都会撞上可靠性、可观测性、权限隔离三堵墙。生产环境里，最稳的做法是：触发器只往一张alert_event表里插记录，由独立服务（Python脚本、K8s Job、Flink任务）定时拉取、去重、组装模板、调用企业微信API。
-
alert_event表必须有processed_at字段和唯一索引（event_type, source_id, created_at），避免重复消费 - 外部服务拉取用
SELECT ... FOR UPDATE SKIP LOCKED（PostgreSQL）或SELECT TOP 100 ... WITH (ROWLOCK, READPAST)（SQL Server），别用OFFSET分页 - MySQL没
SKIP LOCKED？那就用UPDATE ... SET processed_at = NOW() WHERE id IN (SELECT id FROM ... LIMIT 100)先占位再查
复杂点在于“怎么确保每条预警只发一次”，而不是“怎么让触发器多发几次”。这个边界划不清，后面全是坑。
