生产环境基本不碰存储过程和触发器，因其使数据库沦为逻辑黑盒：业务逻辑脱离Git版本控制、无diff不可审、监控日志无法追踪隐式执行路径，批量操作性能断崖下跌，分库分表与多活架构下天然失效，且严重阻碍数据库迁移与升级。
生产环境里，存储过程和触发器不是“慎用”，而是基本不碰——它们会让数据库从数据仓库变成逻辑黑盒，出问题时连日志都找不到源头。
存储过程让业务逻辑脱离版本控制和可观测性
代码写在数据库里，就等于没进 Git。CREATE OR REPLACE PROCEDURE 直接覆盖，没有 diff、不能 Code Review、CI 无法校验。一次上线后发现状态流转异常，你得连上数据库查 mysql.proc 表，再人工拼接 SQL_TEXT 字段（它默认截断），最后靠猜还原逻辑分支。
-
CALL transfer_funds()超时？performance_schema.events_statements_history只记这一行，内部 12 条 UPDATE/INSERT 的耗时、锁等待、执行计划全丢 - OUT 参数值无法被
mysqld_exporter抓取，Prometheus 告警只能判断“是否调用成功”，没法感知余额是否真扣减了 - MySQL 5.7 的
DECLARE CONTINUE HANDLER在 8.0 中语义变更，创建时不报错，某次调用才静默失败，线上复现成本极高 - 云厂商如阿里云 RDS 默认禁用
EXECUTE权限，ERROR 1370 (42000) 是开发能跑、上线即跪的第一道墙
触发器把数据变更路径彻底隐藏
一次 UPDATE orders SET status = 'shipped' 看似简单，背后可能隐式触发库存扣减、风控校验、审计写入三张表——这些动作不会出现在应用日志、APM 链路或慢 SQL 监控里。DBA 查到的永远只是“620ms 的 UPDATE”，根本不知道瓶颈在触发器里那条没索引的 SELECT COUNT(*) FROM sku_info WHERE sku_id = NEW.sku_id。
- 批量导入 5 万行，触发器逐行执行 → 事务持续几十秒，
INFORMATION_SCHEMA.INNODB_TRX里TRX_ROWS_MODIFIED瞬间飙高，锁不释放、undo log 不 purge - 触发器内调用
NOW()或RAND()，binlog 可能退化为 SBR 模式，主从复制直接报 ERROR 1592 (HY000) - 分库分表中间件（如 ShardingSphere）不解析触发器 SQL，硬编码表名如
INSERT INTO audit_log_001会绕过分片路由，写到错误分片甚至失败 - 多活架构下双向同步，同一触发器在两边重复执行，导致计数翻倍、状态错乱，ERROR 1442 却只报“不能在触发器中更新本表”，不指明是哪个触发器、哪一行惹的祸
二者共同放大数据库的扩展与迁移风险
存储过程和触发器都依赖 MySQL 特定语法和执行引擎，一旦要换库、升版本、上云、分库，它们就是第一批被淘汰的代码。
- Oracle/PostgreSQL 的存储过程语法差异极大，
DECLARE v_id INT DEFAULT 0vsDECLARE v_id INTEGER := 0，跨源适配必须重写 - TiDB、Aurora、GaussDB(MySQL版) 对存储过程支持有限甚至完全禁用，
CALL语句基本不可用 - 读写分离下，从库不执行触发器逻辑，但主库生成的审计记录不会同步过去；而存储过程混着 SELECT 和 INSERT，从库回放时可能因缺失数据直接报错
- ALTER TABLE 会被几十个触发器拖慢 metadata lock 等待，连加个字段都卡住
真正棘手的不是语法限制，是它们把本该在应用层可灰度、可热替换、可跨技术栈迁移的业务逻辑，钉死在单点数据库里——而现代系统要求的是链路透明、故障可溯、演进可持续。这点，任何 DELIMITER $$ 都救不了。
