ShardingSphere-Proxy不支持无分片键的LIMIT OFFSET跨分片分页，因无法路由而报错或返回空；必须带显式分片键等值条件且类型匹配，多分片分页需应用层并发查询+内存归并。
ShardingSphere-Proxy 不支持标准 LIMIT OFFSET 跨分片分页
ShardingSphere-Proxy 对 LIMIT 10 OFFSET 20 这类无分片键的分页 SQL 默认拒绝执行，报错类似 Error 20024 (44000): Sharding value must implements Comparable 或直接返回空结果。根本原因是 Proxy 无法确定该分页应路由到哪个物理分片——它需要明确的分片键值来定位数据位置。
常见错误现象：
- 全表查询加
Limit(10).Offset(20)，GORM 生成的 SQL 被 Proxy 拦截，返回空 slice 或 panic - 用
WHERE user_id = ?带参数但未传具体值（比如用了db.Where("user_id = ?", userID).Limit(10).Offset(20)却传了0），Proxy 解析出无效分片值，路由失败 - 分页时用了
ORDER BY created_at但created_at不是分片键，Proxy 可能返回乱序或不完整结果
必须满足两个前提才能走 Proxy 分页：
- SQL 中必须含显式、非零的分片键等值条件，例如
WHERE order_id = '20240821ABC'（不能是WHERE order_id = ?绑定变量） - 分片键字段类型需与 Proxy 配置一致：若配置为
order_id: substring(order_no, 0, 4)，Go 层传入的order_id必须是string，不能是[]byte（否则触发[B@xxx报错）
GORM 的 Scopes + 手动分页逻辑是唯一可行路径
别指望 db.Scopes(...).Limit(10).Offset(20).Find(&results) 自动跨分片生效——Proxy 不会帮你合并多个分片的结果。真实分页必须由 Go 层拆解：
- 先根据分片键算出目标分片（如
shardID := userID % 8），再用db.Table("orders_" + fmt.Sprintf("%03d", shardID))定向查单个物理表 - 若分页涉及多分片（如按时间范围查所有订单），需并发查每个分片的
LIMIT N+OFFSET M，再在内存中 merge-sort 后取第 M~M+N 条 - 避免用
Count()获取总条数：Proxy 的SELECT COUNT(*)在无分片键时可能不准或超时，建议改用近似统计（如 Redis HyperLogLog）或业务允许的“下一页是否存在”模式
示例（单分片安全分页）：
func PaginateOrderByUserID(db *gorm.DB, userID uint64, page, pageSize int) ([]Order, error) {
shardID := userID % 8
tableName := fmt.Sprintf("orders_%03d", shardID)
<pre class="brush:php;toolbar:false;">var orders []Order
err := db.Table(tableName).
Where("user_id = ?", userID).
Limit(pageSize).
Offset((page - 1) * pageSize).
Find(&orders).Error
return orders, err}
为什么不能依赖 GORM 的 Preload 关联分页
Preload("User") 在分库分表场景下基本失效。原因很直接：关联表（如 users）很可能在另一个库或另一个分片规则下，Proxy 不支持跨库 JOIN，GORM 也无法自动把 orders_001 和 users_002 拼成一条 SQL。
实际后果：
- Preload 会发出独立的
SELECT * FROM users WHERE id IN (1,2,3)，但这个查询没带任何分片键，Proxy 直接路由到默认库（常为空） - 若强行在 Preload 中加
Where("shard_id = ?", shardID)，又破坏了 ORM 的抽象，且无法保证关联 ID 分布在同一分片 - 更隐蔽的坑：GORM 的
Joins("JOIN users ON orders.user_id = users.id")会被 Proxy 当作非法跨分片操作拦截
正确做法是两步分离：
- 先分页查出
orders列表（带user_id字段） - 提取所有
user_id，用IN批量查users表 —— 注意：users表也需走分片逻辑，比如db.Table("users_" + suffix).Where("id IN ?", ids)
容易被忽略的边界：分页参数校验和时钟回拨影响
Proxy 分页失败时，错误信息往往不明确，真正卡点常在细节：
-
page和pageSize必须做服务端校验：前端传page=0或pageSize=10000可能导致 Proxy 内存溢出，建议硬限制pageSize - 若用 Snowflake 生成分片键（如
order_id），时钟回拨会导致同一毫秒内生成重复 ID，Proxy 路由到同一张表但数据错乱，分页结果出现跳号或重复 - Proxy 日志里看不到 GORM 的 SQL 绑定值，调试只能靠抓包（如
tcpdump -i lo port 3307）或开启 Proxy 的sql-show: true配置，看它最终解析出的语句是否含有效分片值
最麻烦的不是写不对，而是查不到错在哪——Proxy 把问题吞掉后只返回空，得从它的 stdout 或 logs/sharding-proxy.log 里翻原始报错。
