分库分表中间件不解析、不支持触发器，因其仅路由标准DML语句，忽略DDL如CREATE TRIGGER；触发器为实例级对象，无法跨节点同步；手动创建仍不可控，易致逻辑分裂、路由失败、维护灾难；应将分表逻辑上移至应用层或代理层，用CDC解耦审计同步。
分库分表中间件根本不解析触发器定义
ShardingSphere、MyCat、Vitess 这类中间件在 SQL 入口层做路由解析，只识别 INSERT、UPDATE、SELECT 等标准语句结构，对 CREATE TRIGGER 这类 DDL 完全忽略或直接报错。它们不加载、不存储、也不转发触发器元数据——因为触发器是 MySQL 实例级对象，中间件无权、也无法在多个物理节点上同步维护这些逻辑。
常见现象：
- 执行
CREATE TRIGGER t1_ins AFTER INSERT ON order_001 ...，中间件可能透传给某个分片节点，但其他节点完全不知情 - 你手动在每个分片上都建了同名触发器，中间件仍不会感知——它只管路由原始 SQL，不管后续在目标节点上是否执行了触发器
- 某些中间件（如旧版 MyCat）遇到
CREATE TRIGGER会直接返回语法错误，因为它压根没实现该 DDL 的解析分支
触发器行为在分片环境下天然不可控
即使你绕过中间件、直连各分片 MySQL 手动创建触发器，其执行效果也完全脱离中间件的治理能力：
-
AFTER INSERT在主库触发后往audit_log写日志，但该表若未分片，就会被路由到默认库；若已分片，又面临跨库写入报ERROR 1442或路由失败 - 触发器里查
config表——如果该表是广播表，各节点查到的数据可能不一致；如果是单库表，只有部分节点能查到，逻辑分裂 - 主从复制中，从库只回放原始 DML（如
INSERT INTO order_001），而触发器产生的衍生操作（如INSERT INTO stat_summary）是主库直写 binlog 的，从库上的对应触发器根本不会运行
动态分表 + 触发器 = 维护灾难
想用触发器实现“按 user_id % 4 自动写入 order_0~order_3”，只能硬编码 IF 分支：
IF NEW.user_id % 4 = 0 THEN INSERT INTO order_0 (...) VALUES (...); ELSEIF NEW.user_id % 4 = 1 THEN INSERT INTO order_1 (...) VALUES (...); -- ... 重复 4 次 END IF;
问题立刻暴露：
- 新增分片要改所有触发器并
DROP/CREATE，线上不能热更 - 字段变更（如加一列）需同步改全部 4 个
INSERT语句，漏一个就ERROR 1136（Column count doesn't match） - 中间件本可自动处理的路由逻辑，被锁死在每个节点的触发器里，失去统一管控能力
替代方案其实很明确：把分表逻辑移出数据库
真正落地的分库分表，从来不是靠触发器拼凑出来的：
- 应用层分表：插入前计算
t_order_202610表名，生成完整INSERT语句直连目标分片执行——逻辑清晰、可灰度、可监控 - 代理层分表：让 ShardingSphere-Proxy 解析 SQL 并自动路由，触发器退化为仅做本地校验（如非空检查），不碰 DML
- 审计/同步类动作改用 CDC（如 Debezium）捕获 binlog，再由外部服务投递到目标系统——解耦、异步、可观测
最常被忽略的一点：一旦用了中间件，你就默认放弃了单实例数据库的“自治性”。触发器那种隐式、强耦合、难调试的执行路径，在分布式上下文中只会放大故障面，而不是解决问题。
