触发器不能替代分库分表中间件
触发器不能替代分库分表中间件
先说一个核心判断：MySQL触发器，本质上就是个单库、单实例内的事件响应器。它既没法跨服务器同步数据，也不能自动把SQL路由到不同的物理库表里去。所以，当你听到“用触发器实现分库分表”这种说法时，可得留个心眼。这背后通常的操作是：在同一个MySQL实例下，手动维护多个结构相同的表（比如order_0、order_1），通过触发器来写插入或更新逻辑——这充其量算是个“伪分片”，离真正的分库分表差得远。
这么做的代价，市场上不乏这样的案例，通常表现为：
- 写入性能断崖式下跌：每一次INSERT操作，都可能触发额外的INSERT或UPDATE，导致事务链路被拉长，吞吐量自然上不去。
- DDL变更成了噩梦：一旦需要新增分表，所有相关的触发器都得手动补全，遗漏一两个简直是家常便饭。
- 主从延迟被急剧放大：触发器产生的语句会在从库上串行执行，很容易成为复制延迟的罪魁祸首。
- 水平扩容根本无从谈起：想加新库？对不起，触发器可不会自动感知，更别提帮你做数据重路由了。
触发器适合做哪些同步？明确边界
那么，触发器到底该用在哪儿？它的适用场景其实非常有限，必须同时满足三个前提：同实例、低频操作、对强一致性要求不高。
经验表明，下面这几种情况算是它的“舒适区”：
- 同实例下的字段汇总：比如，在
user库的logstat库的daily_summary表追加一行统计记录。 - 审计日志记录：利用
AFTER UPDATE触发器，把数据变更前后的值，写入本地的audit_log表。 - 状态派生字段的维护：例如，当
status字段变化时，自动更新与之关联的status_text字段。
需要警惕的是，触发器里的NEW和OLD只能访问当前语句涉及的那一行数据，无法JOIN其他表。如果非得关联查询，只能用SELECT ... INTO @var这种办法，但这会显著拖慢性能，得不偿失。
真正需要分库分表时，该选什么中间件？
当你的单表数据量逼近2000万行、QPS突破3000、或者业务确实需要跨机器部署时，就别再折腾触发器了，专业的事情必须交给专业工具。目前主流的方案有这么几种：
- ShardingSphere-JDBC：适合Ja va应用嵌入式集成。它的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 $$包裹，并且以$$结尾。不然，遇到第一个;就会被提前提交，直接导致语法错误。
最后，也是最容易被忽略的一点：触发器并不享受事务的“原子性”保护。举个例子，如果主表插入成功了，但触发器里的插入操作失败了，主表那条数据是不会自动回滚的。这意味着，你不得不在应用层自己补上补偿逻辑——而这，早就远远超出触发器所能负责的范畴了。
