MySQL存储过程与触发器在运维中被刚性禁用，因其与自动化部署、分库分表、主从切换等现代运维体系根本冲突：触发器不可控、无法禁用；存储过程不支持跨分片路由；二者均破坏可观测性、版本管理与权限隔离。
MySQL 存储过程与触发器在运维中不是“慎用”，而是有明确、刚性的使用禁忌。这些禁忌源于其底层机制与现代运维体系（如自动化部署、灰度发布、高可用切换、分库分表、审计合规）存在根本性冲突，强行使用会放大故障风险、拖慢响应速度、阻碍问题定位。
禁止在生产环境启用触发器做核心业务逻辑
触发器自动执行、不可跳过、无开关控制，一旦上线就无法按需关闭——这与运维要求的“可控变更”直接矛盾。例如批量修正数据时，本应静默更新，却因触发器自动生成日志或校验失败而中断；又如主从切换期间，触发器在主库执行但不复现在从库，导致数据错位或丢失。运维人员无法通过配置或命令临时禁用，只能删重建，风险极高。
- MySQL 8.0+ 不支持 DISABLE TRIGGER 语法，
ALTER TRIGGER ... DISABLE直接报错 - 临时方案（如重命名或会话变量开关）仅适用于测试环境，生产环境严禁依赖
- 所有触发逻辑必须能在应用层被等价替代，且具备幂等、可重试、可观测能力
禁止在分布式或分库分表架构中使用存储过程
存储过程绑定单库连接和固定 schema，完全无法适配分片路由。当表被拆分为 order_001、order_002 等物理分片后，过程内写的 UPDATE orders 会直接报错 Table 'db.orders' doesn't exist。中间件（如 ShardingSphere）不解析过程体内的 SQL，也无法重写或路由。
- 跨分片操作（如更新用户库 + 订单库）在存储过程中无法协调，XA 事务支持弱、性能差、易死锁
- 调用含 SELECT 的自定义函数时，若该表已分片，函数执行失败但错误可能被静默吞掉（尤其未启用 STRICT_TRANS_TABLES）
- 与 Seata/Saga 等分布式事务框架无法集成，触发的副作用无法纳入全局回滚
禁止在触发器中执行耗时或外部依赖操作
触发器运行在主事务上下文中，任何延迟都会阻塞原 SQL，拖慢整个写入链路。运维监控难以区分是业务 SQL 慢，还是触发器拖累——它没有独立 trace ID，不打日志，不出错栈。
- 禁止发起 HTTP 请求、调用远程服务、读取大表、写入慢日志表（如未建好索引的 audit_log）
- 禁止使用
NOW()、RAND()、UUID()等不确定函数，会导致主从复制异常或 binlog 解析失败 - 禁止在 AFTER INSERT 中尝试修改同一张表（触发 ERROR 1442），也禁止在触发器里调用修改原表的存储过程
禁止将业务规则耦合进数据库对象
存储过程和触发器代码散落在数据库中，无法纳入 Git 版本管理、CI/CD 流水线、Code Review 或自动化测试。一次误删、漏备份、权限变更，就可能导致线上逻辑静默失效。
- 无变更记录：谁改了？何时改？为什么改？全靠人工记笔记或 DBA 记忆
- 无回滚能力：修改触发器逻辑后出问题，无法一键回退到上一版本
- 无权限隔离：开发能写触发器，意味着能绕过应用层鉴权直接操作数据，违反最小权限原则
