分库分表逻辑应在gin中间件或handler入口处处理，从请求参数提取分片键并计算目标库表，避免硬编码在dao层；用user_id分片时须处理负数和零值，推荐先取绝对值再模运算。
分库分表不是 Gin 的事，但路由层必须感知分片逻辑
Gin 本身不提供分库分表能力，它只负责 HTTP 请求的接收与响应。真正决定数据写到哪个库哪张表的，是你在 Handler 里写的分片逻辑。如果把分片规则硬编码在 DAO 层或 SQL 拼接里，后期维护和测试会非常痛苦。正确做法是：在 Gin 的中间件或 Handler 入口处，从请求参数（如 user_id 或 order_id）提取分片键，计算出目标 db_name 和 table_suffix，再透传给数据库操作层。
常见错误是直接在 DB.Exec 前拼接表名，比如 "orders_" + strconv.Itoa(userID%16) —— 这会让 ORM 或连接池无法复用 prepared statement，也容易被注入攻击。更稳妥的方式是用预定义的分片映射表或一致性哈希函数（如 hashmaphash.New()），并确保分片逻辑可单元测试。
用 user_id 分片时，别忽略负数和零值
很多业务用 int64 类型的 user_id 做分片依据，但实际数据中可能存在 user_id = 0（如游客）、或负值（某些老系统导出 ID 为 signed int）。直接用 user_id % 16 会导致负数结果为负，MySQL 表名不能含负号，PostgreSQL 会报 syntax error。
- 始终先取绝对值再模运算：
shard := int(math.Abs(float64(userID))) % 16 - 或统一转为 uint64：
shard := uint64(userID) % 16（注意：若原user_id是负的，uint64(-1)会变成极大值，仍需前置校验） - 建议在 Gin 的绑定结构体中加校验：
if userID
连接多个 MySQL 实例时，sql.DB 实例不能混用
分库意味着你至少要管理 N 个 *sql.DB 实例（每个库一个）。有人图省事只初始化一个全局 db 变量，然后在运行时动态改 db.Driver 或 URL —— 这是错的。*sql.DB 是连接池，内部状态（如 maxOpen、maxIdle）和底层驱动强绑定，切换 URL 不会重置连接池，旧连接可能还在用，新查询会失败或超时。
正确做法是预先构建 map：
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
var dbMap = make(map[string]*sql.DB) for i := 0; i <p>然后在 Handler 中根据分片键取对应 <code>dbMap["shard_3"]</code>。注意：这个 map 必须是包级变量或注入到 <code>gin.Engine</code> 的 <code>Context</code> 中，不能每次请求都重建。</p> <h3>跨分片查询（如查用户所有订单）只能靠应用层聚合</h3> <p>Gin 接口要支持“查某用户全部订单”，而该用户的订单可能分散在 4 张物理表（<code>orders_0</code> 到 <code>orders_3</code>）里。MySQL 不支持跨库 <code>UNION ALL</code> 自动路由，也没有类似 TiDB 的 global index。你只能在 Go 层并发查多个分片，再合并结果。</p> <p>容易踩的坑：</p>
- 没设超时控制：4 个 goroutine 同时查，某个库慢了拖垮整个接口 —— 务必用
context.WithTimeout包裹每个查询 - 结果排序丢在数据库外做：
sort.Slice()处理上万条数据很耗 CPU，应尽量让各分片返回已按created_at DESC排序的数据，再用归并排序（heap包）合并 - 分页失效：limit 10 offset 100 在每个分片查 10 条，最后取前 10 条，语义完全不对 —— 正确做法是每个分片查
limit 110，应用层取 top 100
这种查询天然不适合高频调用，建议加缓存（如 Redis Hash 存最近 30 天订单 ID 列表），或引导前端用时间范围 + 分片键组合查询，避开全分片扫描。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
