MySQL存储过程和触发器在分布式架构中基本不可用，因其依赖单库单表强一致性假设，无法适配分库分表、读写分离、多实例协同等场景，导致路由失败、主从不一致、事务失控及隐蔽错误频发。
MySQL 的存储过程和触发器在分布式架构中基本不可用，不是“慎用”，而是设计上就无法支撑分库分表、读写分离、多实例协同等常见分布式场景。
分库分表后，存储过程根本找不到目标表
存储过程运行时绑定的是单个数据库连接和默认 schema。一旦业务表被水平拆分到 order_001、order_002 等多个物理库表，而存储过程里写的还是 UPDATE orders SET status = ?，MySQL 就会报错 Table 'db.orders' doesn't exist——它压根不知道该去哪个分片查。
- ShardingSphere、MyCat 等中间件不解析或重写存储过程内部 SQL，只代理客户端发来的原始语句
- 即使硬编码分片名（如
UPDATE order_001 SET ...），也无法动态路由，失去分片逻辑的统一管控 - 跨分片事务（比如同时更新用户库 + 订单库）在存储过程中无法协调，
XA支持弱且性能极差
触发器在主从/多活架构下行为不一致
触发器只在主库执行，从库不会复现触发逻辑。如果业务依赖触发器填充日志、校验字段或生成关联数据，从库数据就会缺失或错位。
-
AFTER INSERT触发器生成的审计记录，在从库上不会出现，导致 binlog 解析或 CDC 工具漏数据 - 主库触发器修改了本表某字段，从库回放的是原始 DML，没走触发路径 → 主从数据不一致
- 多活架构（如基于 GTID 的双向同步）下，触发器可能在两边重复执行，造成计数翻倍、状态错乱
ERROR 1442 在分布式事务链路中更难规避
这个错误本身是单机 MySQL 的硬限制：触发器不能修改“正在被操作的同一张表”。但在分布式场景下，它常以更隐蔽的方式爆发。
- 你在一个分片上写入
payment表，触发器试图调用另一个分片的user_balance表做校验 → 跨库查询不被允许，直接报错 - 触发器内调用自定义函数，而该函数又含
SELECT ... FROM order_detail—— 如果该表已分片，函数执行失败，但错误被静默吞掉（尤其sql_mode不含STRICT_TRANS_TABLES） - 应用层用 Seata 或 Saga 做分布式事务时，触发器逻辑无法纳入全局事务上下文，回滚时无法撤回触发器已做的副作用
真正麻烦的不是语法写不出来，而是所有这些机制都建立在“单库单表强一致性”的假设上。一旦拆库拆表、引入中间件、对接消息队列或异地多活，存储过程和触发器就成了系统里最不可观测、最难调试、最易出错的黑盒部分——它们不是被“禁用”，而是自然失效了。
