触发器不能替代分库分表中间件，因其仅限单实例内事件响应，无法跨服务器路由或同步数据；所谓“触发器分表”实为同实例伪分片，存在性能下降、DDL维护难、主从延迟放大等严重缺陷。
触发器不能替代分库分表中间件
MySQL 触发器本质上是单库、单实例内的事件响应机制，它无法跨服务器同步数据，也不能自动路由 SQL 到不同物理库表。当你看到“用触发器实现分库分表”，实际往往是：在同一个 MySQL 实例下，对多个同构表（如 order_0、order_1）手工维护插入/更新逻辑——这属于伪分片，不是真正的分库分表。
常见错误现象包括：
- 写入性能急剧下降：每个 INSERT 都要触发额外的 INSERT/UPDATE，事务链路变长
- 无法处理 DDL 变更：新增分表后，所有触发器需手动补全，极易遗漏
- 主从延迟放大：触发器语句在从库上串行执行，加剧复制 lag
- 不支持水平扩容：加新库时，触发器无法自动感知或重路由
触发器适合做哪些同步？明确边界
触发器只应在以下有限场景中用于同步，且必须满足「同实例、低频、强一致性要求不高」三个前提：
- 同一 MySQL 实例下，不同数据库之间的字段级汇总（例如：
user库的log表变更后，向stat库的daily_summary表追加统计行） - 审计日志写入：
AFTER UPDATE向本地audit_log表记录变更前后值 - 状态派生字段维护：如
status字段变化时，自动更新status_text字段
注意：NEW 和 OLD 只能访问当前语句涉及的行，无法 JOIN 其他表；若需关联查询，必须用 SELECT ... INTO @var，但会显著拖慢性能。
真正需要分库分表时，该选什么中间件？
当单表超 2000 万行、QPS 突破 3000、或需跨机器部署时，必须用专业中间件。主流选择中：
-
ShardingSphere-JDBC：适合 Java 应用嵌入式使用，SQL 解析能力强，支持INSERT INTO t_order (id, user_id) VALUES (?, ?)自动路由到t_order_1；但不支持存储过程、部分复杂子查询 -
ShardingSphere-Proxy：独立服务进程，兼容任意语言客户端，DDL 支持更好；但多一层网络跳转，延迟略高 -
Vitess：Google 生产验证，对 MySQL 协议兼容极好，适合已用 MySQL 主从架构并希望平滑演进的团队；但运维需熟悉 Kubernetes
别碰 MyCAT：社区活跃度低，DDL 支持弱，配置 XML 易出错，线上故障排查成本高。
如果硬要用触发器模拟分片，这些坑必须避开
仅作临时方案或学习用途时，务必遵守以下约束：
- 所有分表必须在同一实例、同一账号权限下，否则
INSERT INTO db2.t2会因权限拒绝失败 - 禁用
AFTER DELETE触发器做反向清理：若目标表有外键或唯一索引，可能触发死锁 - 避免在触发器里调用函数或存储过程：MySQL 5.7+ 对触发器内函数调用有严格限制，容易报
ERROR 1442 (HY000): Can't update table in stored function/trigger - 每个触发器体必须用
DELIMITER $$包裹，且结尾必须写$$；否则遇到第一个;就提前提交，语法直接报错
最易被忽略的一点：触发器不参与事务回滚的“原子性保障”。比如主表插入成功、触发器插入失败，主表不会自动回滚——你得自己在应用层补补偿逻辑，而这早已超出触发器能力范围。
