mysql原生不支持insert自动路由到不同物理表，所谓“自动分表”实为应用层或触发器干预的设计模式：需在执行前计算目标表名并显式拼入sql，如按user_id%16插入user_09；分区（partitioning）属单表逻辑，非真正分表，且不支持动态建表、跨库及强灵活性分片。
MySQL 中 INSERT 时无法自动分表，必须由应用层或触发器干预
SQL 标准和 MySQL 原生不支持 INSERT INTO table_name 自动路由到不同物理表（如 user_001、user_002）。所谓“自动分表”不是语法能力，而是设计模式——你得在执行 INSERT 前算出目标表名，并显式写进去。
常见误解是以为加个函数或分区键就能让 MySQL 自己选表，但 MySQL 的 PARTITION BY 是**水平分区（partitioning）**，不是分表（sharding），它仍属单表逻辑，底层仍是同一个 table_name，无法跨库、跨实例，也不支持按算法（如一致性哈希）分散到独立表。
- 分区表的分区字段必须是主键/唯一键的一部分，约束强、灵活性低
- 分区数上限受引擎限制（如 InnoDB 最多 8192 个分区），且无法动态增减
- 分区不解决连接、事务跨分片问题，也不能替代应用层分表
应用层拼接表名是最直接、可控的分表方式
在代码里根据分片键（如 user_id）计算后缀，再拼进 SQL。这是线上主流做法，稳定、可调试、易灰度。
例如：按 user_id % 16 落到 16 张表，user_id = 12345 → 12345 % 16 = 9 → 插入 user_09：
INSERT INTO user_09 (id, name, created_at) VALUES (12345, 'Alice', NOW());
- 分片算法要幂等：同一
user_id每次都算出相同后缀，避免数据错乱 - 表名格式统一（如固定两位数字后缀），避免字符串比较或前导零问题
- 务必提前建好所有分表（如
user_00到user_15），MySQL 不会自动建表 - 注意 ORM 是否支持动态表名；MyBatis 可用
${tableName}，但需校验合法性，防 SQL 注入
触发器 + PRECEDE 视图？不可靠，仅限极简场景
有人试图用视图 + INSTEAD OF 触发器模拟自动分表，但 MySQL 不支持 INSTEAD OF 触发器（仅 PostgreSQL 支持），MySQL 的触发器只能是 BEFORE/AFTER INSERT，且不能改写目标表名。
强行用触发器做分发表，典型失败写法：
CREATE TRIGGER user_insert_split BEFORE INSERT ON user_view
FOR EACH ROW
BEGIN
SET @target_table = CONCAT('user_', LPAD(NEW.id % 16, 2, '0'));
-- ❌ 下面这句语法错误：不能在触发器里执行动态 INSERT 到变量表名
SET @sql = CONCAT('INSERT INTO ', @target_table, ' VALUES (', NEW.id, ', ...)');
PREPARE stmt FROM @sql;
EXECUTE stmt;
END;
- MySQL 触发器中不允许
PREPARE/EXECUTE - 即使绕过，触发器内动态 SQL 无法回滚，破坏事务原子性
- 性能差：每次 INSERT 都要解析、拼接、执行新语句
- DBA 很难审计和优化，线上基本不用
分表后查询、关联、分页的代价常被低估
分表不是一劳永逸，它把复杂度从存储层转移到访问层：
-
SELECT * FROM user WHERE id = ?变成先算表名再查，没问题；但SELECT * FROM user WHERE name LIKE '%bob%'就得扫 16 张表 - 跨分表
JOIN必须在应用层做两次查询+内存关联，或改用宽表冗余 -
ORDER BY created_at LIMIT 20 OFFSET 1000需各表取 top 1020，合并后重排，成本陡增 - 唯一约束（如手机号唯一）无法靠数据库保证，得依赖分布式 ID 或额外全局索引表
真正该问的不是“怎么 INSERT 自动分表”，而是“当前数据量和 QPS 是否真的需要分表”——很多场景用归档、读写分离、列存加速或 TiDB 这类分布式数据库更省事。
