GORM不支持跨数据库JOIN，因底层驱动仅绑定单库连接；可行方案为应用层双查+内存合并，或通过FEDERATED引擎/VIEW桥接，但后者运维成本高、事务隔离弱。
跨库 JOIN 在 GORM 里根本走不通
GORM 不支持跨数据库（如 MySQL 中 db_a.users 和 db_b.orders）的 JOIN 查询，底层 SQL 驱动和方言不认这种写法。你写的 db.Table("db_a.users").Joins("LEFT JOIN db_b.orders") 会直接报错 Error 1146: Table 'db_b.orders' doesn't exist——不是语法错，是连接上下文只绑定了一个数据库实例。
真正能落地的方案只有两种：
- 应用层双查 + 内存合并：先查
db_a的主表数据，再用结果中的 ID 列批量查db_b的关联数据，最后在 Go map 或 slice 里手动组装 - 视图或联邦表（MySQL 8.0+）：在中间库建
VIEW或用FEDERATED引擎桥接，但运维成本高、权限难控、事务隔离弱
别信“改 DSN 就能跨库 JOIN”这类说法——GORM 的 Joins 方法生成的 SQL 仍走同一个 DB 连接池，换 DSN 只能换整个 *gorm.DB 实例，无法嵌入单条查询。
内存分页只适合小数据量场景
用 Find(&results) 把全量数据捞进内存再 slice[start:end]，看似简单，实则危险。一旦表里有 10 万行，SELECT * 就可能吃光服务内存或触发 GC 频繁停顿。
适用边界非常明确：
- 数据源是本地 slice 或 map（非 DB），比如配置项列表、枚举缓存
- DB 查询已加了强条件过滤，预估结果集
- 前端明确要求“跳页不保序”，即第 5 页不一定要严格等于 SQL 分页的第 5 页（例如后台管理的临时筛选）
注意：sort.Slice 排序 + 内存分页组合使用时，必须确保排序字段无重复值，否则 Offset 计算会偏移——这恰恰是数据库物理分页靠 ORDER BY id ASC 加唯一索引保证的。
混合分页：DB 分页 + 内存后处理的正确姿势
常见需求如“查用户列表，同时附带每个用户最新一条订单状态”，不能跨库 JOIN，又不能全量拉取。这时应拆成两步，且严格分离查询上下文：
- 第一步：对主表（users）做标准物理分页，
db.Offset((page-1)*size).Limit(size).Order("id ASC").Find(&users) - 第二步：提取
users中所有id，用IN批量查订单表（必须同一库），db.Where("user_id IN ?", userIds).Order("created_at DESC").Select("user_id, status, created_at").Find(&orders) - 第三步：用
map[uint]Order建立映射，遍历users注入对应订单——不要用双重循环，O(n²) 在 1000 条时就明显卡顿
关键点：两次查询必须用独立的 *gorm.DB 实例（或显式 Session(&gorm.Session{}) 隔离），否则 Where 条件会残留污染；IN 参数超过 1000 个时要分批，MySQL 默认有 max_allowed_packet 限制。
游标分页才是大数据量下的实际解法
当数据量上百万、深度分页（page=10000）频繁出现时，OFFSET 会越来越慢，因为 MySQL 仍需扫描前面所有行。此时必须放弃 page/limit 模型，改用基于排序字段的游标（cursor）：
- 客户端传上一页最后一条记录的
id（或created_at+id组合），例如?cursor=12345 - 查询写成
WHERE id > 12345 ORDER BY id ASC LIMIT 20，GORM 表达为db.Where("id > ?", lastID).Order("id ASC").Limit(20).Find(&items) - 响应中不再返回
total和total_pages，而是返回下一页游标next_cursor（即本页最后一条的id）
游标分页无法跳转任意页，但换来的是恒定查询性能。它不依赖 COUNT(*)，也不受 OFFSET 拖累——这才是线上高频接口该用的方式。别在日志、消息流、feed 流等场景还硬扛 page 参数。
