gorm的limit+offset分页在数据量超10万后性能断崖式下跌，根本原因是数据库需扫描并丢弃前n行，jaeger仅如实反映该db层硬伤，优化方向应为改用游标分页或索引优化。
直接说结论：GORM 的 Limit + Offset 分页在数据量超 10 万后，Jaeger 链路里会暴露出明显耗时尖刺，但这个“慢”不是 Span 埋点问题，而是数据库执行层的硬伤——Jaeger 只是如实照出病灶，你不能靠调 tracer 参数来治。
为什么 Jaeger 里看到分页 Span 耗时飙升？
这不是链路追踪本身的问题，而是 SELECT * FROM users LIMIT 20 OFFSET 100000 这类 SQL 在 MySQL/PostgreSQL 中必须扫描并丢弃前 N 行。Jaeger 的 Span 时间戳忠实反映了这一过程：从 DB 驱动发请求、到收到第一行结果之间的完整延迟。
- Offset 越大，Span 持续时间越长，且呈近似线性增长——500 页 ≈ 扫 10 万行，5000 页 ≈ 扫 100 万行
- 即使
id字段有索引，B+ 树仍需逐节点跳转定位起始位置，无法 O(1) 定位 - Jaeger 不会掩盖这个问题；相反，它让你一眼看出“慢在 DB 查询”，而不是卡在网络或中间件
GORM 分页 Span 埋点容易漏掉的关键上下文
如果你在 Jaeger UI 里看到分页查询 Span 是孤立 root 节点（无 Parent Span ID），说明 context 没传进 DB 层——那你就根本没法把“第 3 页慢”和上游 HTTP 请求关联起来，瓶颈分析就断了。
- 裸用
db.Find(&users)不会自动继承当前 HTTP 请求的 trace context - 必须显式 wrap：MySQL 用
otelmysql.Wrap(db)，PostgreSQL 用otelpostgresql.Wrap(db)，否则 Span 生命周期与业务逻辑脱钩 - 若用了 GORM 的
Session或事务，要确保WithContext(ctx)显式透传，例如：db.WithContext(ctx).Where(...).Limit(...).Find(&users) - 避免在 goroutine 里做分页查询却不传
ctx，否则新 Span 自动变成 root
怎么让 Jaeger 真正帮上忙：改分页方式 + 改埋点粒度
Jaeger 不是性能优化工具，但它能帮你确认“该不该换分页”。一旦发现 Offset 耗时占整个请求 80% 以上，就该立刻切游标分页——这时 Jaeger 的价值才真正体现出来：验证新方案是否生效。
- 游标分页必须带确定排序字段，例如
ORDER BY created_at DESC, id DESC，对应索引为INDEX idx_created_id (created_at, id) - Span 命名要区分场景：
"db.pagination.cursor"vs"db.pagination.offset"，方便在 Jaeger UI 里筛选对比 - 禁用
Count(*)全表统计：不要在分页 Span 里埋点db.Count()，它本身就会拖慢链路；UI 不强求总页数就别查 - 首次请求查
Limit(n+1)判断是否有下一页，这个逻辑也要包进同一个 Span，避免拆成两个 DB Span 干扰判断
最常被忽略的一点：游标值（如 last_created_at 和 last_id）如果从 URL query string 直接拼进 SQL 或 GORM Where，可能引发注入或类型转换错误——Jaeger 里看到的 Span 错误码可能是 500，但根源不在 tracer 初始化，而在参数解析阶段。务必先 decode 再校验再传入查询。
