MySQL触发器不支持动态表名，INSERT等语句的表名必须写死；分表路由须在应用层或存储过程中实现，后者是唯一支持PREPARE动态执行的内置机制。
触发器里不能直接执行 INSERT INTO table_name 动态表名
MySQL 触发器不支持预编译语句（PREPARE/EXECUTE），也不能用变量拼接表名后直接 INSERT。你写 INSERT INTO CONCAT('user_', MOD(NEW.id, 4)) VALUES (...) 会报错：ERROR 1351 (HY000): View's SELECT contains a 'UNION' or 'UNION ALL' or 'subquery' or 'variable' —— 实际上更常见的是 ERROR 1356 (HY000): View references invalid table(s) or column(s)，因为表名必须是字面量。
这意味着：分表路由逻辑必须在应用层或存储过程里做，触发器只适合做数据校验、字段补全、日志记录等“非路由型”操作。
- 触发器中
INSERT、UPDATE、DELETE的目标表名必须写死，不能动态计算 - 哪怕用
SET @tbl = CONCAT(...); INSERT INTO @tbl ...也无效——变量表名在触发器中语法不被接受 - 试图用
SELECT ... INTO @sql; SET @sql = ...; PREPARE stmt FROM @sql;同样失败：触发器内禁止使用PREPARE
替代方案：用存储过程封装路由逻辑，再由应用调用
真正可行的自动路由，得把分表判断和插入拆出来，放到存储过程中。触发器退居二线，只负责辅助工作（比如生成 ID、打时间戳）。
例如，定义一个分片存储过程：
DELIMITER $$
CREATE PROCEDURE insert_user_shard(IN p_id BIGINT, IN p_name VARCHAR(50))
BEGIN
SET @shard_id = MOD(p_id, 4);
SET @sql = CONCAT('INSERT INTO user_', @shard_id, ' (id, name) VALUES (?, ?)');
SET @name = p_name;
PREPARE stmt FROM @sql;
EXECUTE stmt USING p_id, @name;
DEALLOCATE PREPARE stmt;
END$$
DELIMITER ;
然后应用不再直接 INSERT INTO user，而是调用 CALL insert_user_shard(123, 'alice')。这样路由逻辑可控，也能复用。
当代理已经知道网站路由或内容URL，并且在启动前需要有效的sitemap XML、sitemap索引或robots.txt引用时，请使用sitemap。这是一个发布构件技能，而不是爬虫或SEO平台。
- 存储过程支持
PREPARE，是 MySQL 中唯一能安全实现动态表名写入的内置机制 - 注意参数类型要严格匹配，否则
USING会隐式转换失败 - 如果分表依据是时间（如按月分表），可用
DATE_FORMAT(NOW(), '%Y%m')拼表名，但需提前建好目标表，否则EXECUTE报ERROR 1146
如果坚持用触发器，只能靠“冗余主表 + 定期归档”模拟路由
有些团队会建一张逻辑主表（如 user_master），所有写入都走它，再用触发器把数据复制到对应分表。但这不是“自动路由”，而是“自动分发”，且有严重隐患：
- 触发器内对其他表的
INSERT属于“跨表写入”，会显著拖慢主表写入性能，尤其高并发时 - 一旦某个分表写入失败（如磁盘满、约束冲突），整个主表
INSERT回滚，业务感知为写失败 - 无法处理分表间外键、事务一致性；
NEW只反映当前行，无法批量路由 - 若分表结构未来有差异（如某张加了字段），触发器必须同步改，维护成本陡增
这种模式仅适合低频、离线、可容忍延迟的场景，比如日志归档，不适合在线交易。
真正落地时，最容易被忽略的是分表键变更与迁移兼容性
哪怕你用存储过程实现了路由，只要业务后期想换分表策略（比如从 MOD(id, 4) 改成 HASH(name) % 8），所有历史数据就得重分布，而触发器/存储过程不会自动适配旧数据。
所以实际工程中，分表路由必须满足两个前提：
- 分表键（sharding key）在首次写入时就确定，且永不变更（如
user_id） - 所有读写入口（包括后台脚本、ETL、运维工具）都必须经过同一套路由函数，不能有直连分表的“后门”
否则很快就会出现数据散落、查询遗漏、统计不准的问题——而这些，触发器本身完全无能为力。
