为什么 GORM 默认不支持分表，硬加 TableName() 会出问题
因为 GORM 的 TableName() 是实例级静态方法，它在模型初始化时就被缓存，一旦注册了多个分表（比如 user_001、user_002），GORM 内部的 schema 缓存会冲突，导致查询总是落到第一个注册的表上。
常见错误现象：record not found 或查到其他分表的数据；用 db.Table("user_002").Where(...).Find() 能绕过但破坏 ORM 抽象，后续关联、钩子、软删除全失效。
- 真正该用的是
Scopes+ 动态表名构造，把分表逻辑收口到 query scope 里 - 别在模型 struct 上写
func (u User) TableName() string—— 这是全局污染，不是分表 - 如果必须用
TableName()，得配合Session(&gorm.Session{NewDB: true})每次新建 session，否则缓存复用直接翻车
用 Scopes 实现安全分表路由（以 user_id 分片为例）
核心思路：把分表逻辑封装成可复用的 scope 函数，让调用方无感，同时保证事务、预加载、条件拼接都正常。
示例中 ShardByUserID 接收 user_id，算出分表后缀，再用 db.Table() 切换目标表 —— 注意这里只改表名，不改 model 绑定，所以 Scan、Count、Updates 全能用：
立即学习“go语言免费学习笔记（深入）”；
func ShardByUserID(userID uint64) func(db *gorm.DB) *gorm.DB {
return func(db *gorm.DB) *gorm.DB {
shardID := userID % 16
tableName := fmt.Sprintf("user_%03d", shardID)
return db.Table(tableName)
}
}
// 使用
var u User
db.Scopes(ShardByUserID(12345)).Where("status = ?", "active").First(&u)
- scope 必须返回
*gorm.DB，不能直接db.Table(...).Where(...)链式调用后返回结果 —— 否则无法继续组合其他 scope - 分片键（如
user_id）必须作为参数传入 scope，不能从 context 或 global 变量读 —— 否则并发下错表 - 别在 scope 里做
db.Unscoped()或改FullSaveAssociations，这些会污染后续链式操作
分表中间件和 GORM Hook 的协作边界在哪
GORM 的 BeforeQuery、AfterFind 等 hook 是全局生效的，适合加审计字段、时间戳、租户 ID 过滤；但不适合做分表 —— 因为 hook 拿不到原始 SQL 条件里的分片键值，也没法动态改表名。
典型踩坑：在 BeforeQuery 里试图解析 db.Statement.Clauses 提取 WHERE user_id = ?，结果发现参数还没绑定，或者被 IN、BETWEEN、JOIN 搞乱，根本不可靠。
- 分表决策必须发生在 query 构建早期，且依赖明确输入（如函数参数或显式 context key），不是靠“猜”SQL
- Hook 更适合做统一数据脱敏（
AfterFind清空手机号）、状态转换（BeforeUpdate自动更新updated_at） - 如果用了分表中间件（如
shardingsphere-proxy），GORM 层就别再自己分表 —— 两者叠加会导致 double-sharding，查不到数据
分表后 COUNT、JOIN、事务的真实约束
跨分表 COUNT(*) 没有银弹：GORM 的 Count() 只作用于当前表，想算总用户数就得手动遍历所有分表并累加，或者加汇总表/ES 同步。
JOIN 基本放弃：GORM 不支持跨物理表 JOIN，硬写 Joins("LEFT JOIN user_002 ON ...") 会报 invalid association 或生成无效 SQL；即使手写原生 SQL，也得确保 JOIN 的两张表在同一个数据库实例里（跨库分表更麻烦）。
- 事务只能在单一分表内保证 ACID；跨分表 update 必须用 TCC 或本地消息表，GORM 的
Transaction无能为力 - 预加载（
Preload）默认按主表分片路由，如果关联表也分片，且分片规则不一致（比如 user 按 ID、order 按 user_id），就会查空 —— 得手动拆成两个分片查询再 merge - 唯一索引只能建在单表内，
UNIQUE(user_email)在分表后失效，得靠应用层双检或分布式锁兜底
分表不是加个中间件就完事，它把数据一致性、查询语义、运维复杂度全推给了业务代码。最常被忽略的，是分片键变更成本 —— 一旦选错，迁移就是停机+双写+校验的三重地狱。
