mysql触发器禁止直接调用外部命令，因无fork能力、不加载网络栈；sys_exec()是危险的第三方udf，易致db崩溃；应解耦为触发器写日志表、外部程序轮询异步执行。
不能直接调用，任何尝试都会失败或引发严重问题。 MySQL 触发器运行在服务线程内，没有 fork 能力、不加载 libc 网络栈、不提供标准 I/O 句柄——这不是配置没开，而是设计上就禁止。
为什么 sys_exec() 看似能用，实际不该用
sys_exec() 是第三方 UDF（如 lib_mysqludf_sys.so），本质是 C 封装的 system()。它需要手动编译、CREATE FUNCTION 注册，并依赖 mysqld 进程用户（通常是 mysql）有执行权限。
- 常见报错：
ERROR 1126 (HY000): Can't open shared library 'lib_mysqludf_sys.so'（plugin_dir 权限/属主不对） -
sys_exec()返回值只是 shell 退出码，不是 HTTP 状态码；0只代表命令启动成功，不代表脚本跑通、网络可达、API 返回 200 - 高并发下大量
fork容易触发ulimit -n或max_connections限制，导致整个 DB 连接夯住 - 脚本输出到
stderr会被 MySQL 吞掉，调试只能靠echo >> /tmp/debug.log，而线上环境通常禁写盘 - 从库上若未判断
@@read_only，可能意外执行系统命令，造成主从行为不一致
触发器里写 INSERT 比调用 curl 安全十倍
真正可行的方案是把“触发”和“执行”解耦：触发器只做一件事——写日志表；外部程序轮询这张表，再异步调用脚本或 API。
- 建一张轻量表：
CREATE TABLE trigger_alert_log (id BIGINT PRIMARY KEY AUTO_INCREMENT, table_name VARCHAR(64), op VARCHAR(10), payload JSON, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP); - 触发器中只用
INSERT INTO trigger_alert_log，避免DECLARE、SELECT ... INTO等易错语法 - 确保触发器用
SQL SECURITY DEFINER，且定义者账户对日志表有INSERT权限 - 不要在触发器里做复杂逻辑或条件判断，比如
IF NEW.status = 'ALERT' THEN ...应该前置到业务 SQL，减少触发器负担
外部轮询程序怎么写才稳
轮询不是简单 while true + sleep，得防重复、控频率、可监控。
- 用
SELECT ... FOR UPDATE SKIP LOCKED（MySQL 8.0+）或加状态字段（如status ENUM('pending','processing','done')）避免多实例重复消费 - 每次只取固定条数（如
LIMIT 100），处理完再UPDATE ... SET status='done'，别用DELETE——出错时还能查 - HTTP 请求必须设超时（
timeout=5）、重试（最多 2 次）、错误写入单独错误表（如alert_failure_log） - 轮询间隔别死写 60 秒，可根据积压量动态调整：积压 > 1000 条时缩到 5 秒，空闲时拉长到 300 秒
- Python 示例核心逻辑：
cursor.execute("SELECT * FROM trigger_alert_log WHERE status='pending' LIMIT 100")→ 遍历调requests.post(...)→ 成功则UPDATE ... SET status='done'
最常被忽略的一点：轮询程序本身没有高可用保障，单点故障就会中断告警链路。至少得配 systemd restart=on-failure + 监控进程存活，或者用消息队列（如 Kafka）替代轮询——但那就不再是“MySQL 触发器驱动”的架构了。
