分表逻辑必须由应用层显式实现，orm不支持自动分表；需封装表名计算函数，避免dao层隐藏逻辑；id取模或时间范围分表各有适用场景；跨表join和事务不可行，须重构数据访问模式。
分表逻辑必须在应用层做，ORM 不会帮你自动分
Go 没有内置的“分表”能力，database/sql 和主流 ORM（如 gorm、sqlx）都只面向单张表操作。你写的 INSERT INTO user 就是往 user 表插，不会自动变成 user_2024 或 user_0。分表决策必须由你显式计算并拼出目标表名。
常见错误现象：sql.ErrNoRows 突然变多、写入数据查不到、跨表 JOIN 报错——往往是因为查询时用了原表名，但数据实际在 user_1 里。
- 所有
INSERT/SELECT/UPDATE/DELETE都要先算表名，再拼 SQL 或传给 ORM 的Table()方法 - 不要把分表逻辑藏在 DAO 层深处；建议封装成
GetTableNameByUserID(id int64) string这类纯函数，方便测试和复用 - 如果用
gorm，务必调用db.Table(tableName)，而不是db.Model(&User{})—— 后者永远绑定 struct 标签里的table名
ID 取模分表：简单但扩容痛苦，慎用于增长快的主键
按 id % N 决定存哪张表，实现最直白，但有两个硬伤：一是无法预估单表数据量（ID 可能跳跃），二是扩容时必须迁移历史数据。
使用场景：用户量稳定、ID 分布均匀、且能接受停机或双写迁移的小型系统。
-
id % 4得到 0~3，对应表user_0~user_3；注意负数 ID 要先转正：abs(id) % 4 - 别用
int(id) % len(tables)直接索引切片——表名顺序变了就全乱，应始终用确定性哈希（如取模结果映射到固定表名） - 性能影响小，但要注意 MySQL 对
user_0、user_1这类表名不走预编译缓存，prepare 失效，高并发下可能轻微增加解析开销
时间范围分表：适合日志、订单等强时间序数据
按年/月/天建表（如 order_202409、log_20241001），天然支持 TTL 删除、归档和冷热分离。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
关键点不是“怎么格式化时间”，而是“如何应对跨月写入和查询”——比如用户下单时间是 9 月 30 日 23:59，但支付成功回调在 10 月 1 日 00:02，该写哪张表？
- 统一以业务发生时间（非系统时间）为准，字段必须有明确语义，例如
created_at或event_time - 表名生成推荐用
time.Format("200601")（年月），避免用"2006-01"——横杠在表名里虽合法，但某些备份工具或权限系统会误判为分隔符 - 查询跨时间段数据时，不能只查一张表；需动态生成多条 SQL 并
UNION ALL，或用 Go 循环查后 merge 结果；gorm不支持跨表UNION，得手写db.Raw()
分表后 JOIN 和事务几乎不可行，提前放弃幻想
MySQL 原生不支持跨物理表的外键或分布式事务。所谓“跨表 JOIN”，本质是应用层多次查询 + 内存关联，或数据库层暴力 UNION ALL + 子查询，性能和语义都打折。
容易踩的坑：在分表后还写 SELECT * FROM user u JOIN order o ON u.id = o.user_id——这只会查 user 和 order 两张基础表，而真实数据在 user_2、order_202409 里，结果为空。
- 关联查询必须先查主表得到分片键（如
user_id），再根据该键算出对方表名，单独查；没有银弹 - 事务只能局限在单表内；涉及多表更新（如扣库存+写订单）必须拆成最终一致性方案（消息队列 + 本地事务表）
- 唯一能缓解的，是设计时尽量让高频关联的数据落在同一分片：比如用
user_id % 16分用户表，订单表也用user_id % 16分，确保同用户数据物理相邻
分表不是加个配置就能跑起来的功能，它是对整个数据访问模式的重构。最常被忽略的，是分表后的运维成本：DDL 怎么批量执行？备份脚本是否识别新表？监控指标怎么聚合？这些比代码逻辑更耗精力。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
