MySQL触发器中禁止跨库INSERT，会报ERROR 1442；应改用AFTER触发器写入本地中间表，由外部服务消费，避免硬编码分片逻辑、动态SQL无效、性能瓶颈及事件调度器延迟等问题。
触发器里不能直接写跨库 INSERT
MySQL 触发器执行时处于当前会话的事务上下文中，INSERT INTO other_db.table_name 这种跨库写入在多数版本（尤其是 5.7 及之前）会报错 ERROR 1442 (HY000): Can't update table 'xxx' in stored function/trigger because it is already used by statement which invoked this stored function/trigger。本质是 MySQL 禁止在触发器中修改“正在被主语句读写”的表关联的其他表——哪怕只是另一个库里的表，只要涉及同一实例、同一事务，就可能被判定为冲突。
实操建议：
- 改用
AFTER INSERT触发器 + 写入本地中间表（如dispatch_queue），再由外部服务轮询消费 - 如果必须用纯数据库方案，可考虑 MariaDB 10.3+ 的
CONNECT引擎或 MySQL 8.0+ 的 FEDERATED 表（但稳定性差、权限配置复杂、不支持事务回滚） - 避免在触发器里调用存储过程做跨库操作——同样受 1442 限制，不是绕过而是重蹈覆辙
路由逻辑写在触发器里容易硬编码失焦
比如按 user_id % 4 分到 4 张子表，写成 INSERT INTO user_0 VALUES (...) 就把分片规则和数据写入耦合死了。一旦要扩容到 8 个分片，所有触发器都得手动改、逐个 DROP/CREATE，线上不敢动。
实操建议：
- 触发器只负责“记录意图”，例如插入
dispatch_queue表，字段含target_table、payload_json、route_key - 把
user_id % 4 → user_0这类映射逻辑抽到应用层或独立存储（如配置表shard_rule），方便热更新 - 若坚持用触发器做路由，至少用
PREPARE+EXECUTE拼接表名，但注意：MySQL 触发器中不支持动态 SQL，这条路走不通——这是常踩的坑
触发器性能瓶颈比想象中来得快
每条 INSERT 都额外触发一次甚至多次查询+写入，QPS 上千后，延迟毛刺明显，且 dispatch_queue 表本身会成为新热点。
实操建议：
- 给
dispatch_queue加上status字段（'pending'/'done'），消费者用UPDATE ... LIMIT 1争抢任务，避免全表扫描 - 定期归档或清空已处理记录，别依赖
DELETE FROM——锁表时间长 - 监控
INFORMATION_SCHEMA.PROCESSLIST中触发器相关线程的Time值，超过 100ms 就得怀疑逻辑过重
MySQL 8.0 的事件调度器不适合做实时分发
有人想用 CREATE EVENT 每秒扫一次 dispatch_queue，但这不是“自动路由”，是“定时搬运”。延迟至少 1 秒起，且无法保证顺序、易丢任务（事件执行失败不重试）。
实操建议：
- 用轻量级后台进程（如 Python +
mysql-connector-python）监听dispatch_queue，支持失败重试、并发控制、日志追踪 - 若已有消息队列（Kafka/RabbitMQ），直接让触发器写入
queue_topic，比维护自建轮询更可靠 - 别在触发器里调用
SLEEP()或循环等待——会阻塞整个事务，连SELECT都卡住
真正难的不是写触发器，是让路由规则可维护、失败可追溯、扩容不改库。很多团队卡在“第一版能跑”和“三个月后不敢动”之间，问题往往出在把临时方案当架构用了。
