分库分表必须由业务层或中间件控制连接与SQL路由，ORM无法自动支持；需提前确定目标库表、使用独立DB实例、避免跨库事务，分片键应选不变字段并压测验证。
分库分表不是 ORM 能自动解决的问题
Go 语言标准库和主流 ORM（如
、
）本身不提供分库分表能力。它们只负责单库的 SQL 执行与映射，分库分表必须由业务层或中间件控制连接选择与 SQL 路由。强行让 ORM “感知分片”会导致模型耦合、路由逻辑分散、难以调试。
常见错误现象：
或查询总落在同一库、某分片数据暴涨——往往是因为连接池复用未隔离，或分片键未参与路由判断。
分库分表必须在获取
实例前就确定目标库；不能先拿一个通用 DB 再“切换”
每个物理库建议使用独立的
实例（含独立连接池），避免事务跨库、连接竞争
不要依赖 ORM 的
或钩子做分片路由——时机不可控，且无法影响预处理语句的 prepare 阶段
如何根据分片键动态选库选表（以 user_id 分片为例）
核心是把分片逻辑抽成纯函数，输入分片键，输出库名 + 表名 + 对应
实例。推荐用取模（
）或一致性哈希，避免扩容时全量迁移。
示例：16 个库、每个库 32 张 user 表，按
计算归属：
注意：
是预先初始化好的
，每个值调用过
并设好
等参数。别在每次请求里临时 open —— 连接泄漏风险极高。
事务与跨分片操作怎么处理
严格意义上的分布式事务在分库分表场景下基本放弃。实际做法是降级为最终一致性，靠业务补偿或消息队列驱动。
能规避就规避：
单条记录的所有读写必须落在同一库+同一表（靠分片键保证），这是前提
避免
跨库表——拆成多次查询，在 Go 层合并；或冗余必要字段（如订单表存用户昵称）
批量写入不同分片？改用异步写入 + 成功回调，别强求原子性
如果真要跨库事务（例如扣库存+记流水），至少确保所有涉及库都支持
，并用
的
显式控制会话：
，再执行
/
。但 MySQL XA 性能差、运维复杂，生产环境慎用。
分片键设计不当会导致什么
最典型的是用 UUID 或雪花 ID 作为分片键却不截取时间部分——导致数据写入完全随机，热点分散但缓存命中率归零，磁盘 IO 持续拉满。
真实踩坑点：
用
分片？查最近 7 天订单快，但查老用户全量数据要扫全部分片
用
分片？运营商号段集中，某些库瞬间写爆
分片键不可更新——一旦变更，就得搬数据。所以优先选生命周期内不变的字段（如
）
上线前务必压测：模拟真实流量分布，监控各库
和慢查数量。不看指标，只靠理论分片等于没分。
gormsqlxpanic: sql: database is closed*sql.DB*sql.DBScopes*sql.DB%user_id % 512func GetDBAndTable(userID int64) (*sql.DB, string) {
dbIndex := userID % 16
tableIndex := (userID / 16) % 32 // 或直接 userID % 32，取决于设计
dbName := fmt.Sprintf("user_db_%d", dbIndex)
tableName := fmt.Sprintf("user_%d", tableIndex)
return dbPool[dbName], tableName
}dbPoolmap[string]*sql.DBsql.OpenSetMaxOpenConnsJOINXIDdatabase/sqlConnconn, _ := db.Conn(ctx)BEGINCOMMITcreated_atphoneuser_idThreads_running