beego原生分页在数据量超10万行后因count(*)全表扫描导致性能骤降，应改用游标分页、总数缓存与异步更新、模糊总数等组合策略优化。
Beego 原生分页在数据量超过 10 万行后，Count() + Limit() 组合会明显变慢，尤其是 MySQL 的 COUNT(*) 全表扫描开销不可忽视。直接套用文档示例或 layui 分页 demo 很容易在线上压测阶段暴露性能瓶颈。
为什么 Count() 是性能杀手
Beego ORM 的 qs.Count() 默认生成 SELECT COUNT(*) FROM ...，不带 WHERE 条件优化时，MySQL 无法走覆盖索引；即使加了索引，InnoDB 的 MVCC 机制也需遍历聚簇索引或二级索引的全部叶子节点统计行数。百万级表单次 Count() 可能耗时 300ms+，用户点下“第 200 页”时，后端先卡住半秒再查数据，体验断层。
- 避免在高并发列表页无条件调用
Count()，尤其当业务允许“模糊总页数”（如显示“约 1200 条”） - 若必须精确总数，优先检查 WHERE 条件是否命中联合索引最左前缀，否则
Count()必然慢 - 不要依赖
math.Ceil(float64(count)/float64(pageSize))计算页数——如果count本身查得慢，这行代码毫无意义
用游标分页替代 offset 分页
当数据有序且有唯一递增字段（如 id 或 created_at），应放弃 OFFSET 方式，改用游标（cursor-based pagination）。Beego ORM 本身不封装游标逻辑，但可手动构造：
- 前端传
last_id=12345而非page=10 - 后端查询写成
qs.Filter("id__gt", lastId).OrderBy("id").Limit(pageSize) - 返回结果中取最后一个
id作为下一页的last_id，无需Count() - 注意：游标分页无法跳转任意页，但对“加载更多”场景更稳定、更快
分页总数缓存与异步更新
如果业务强依赖精确总条数（如后台管理系统的页码栏），可将 Count() 结果缓存，并异步刷新：
- 首次访问时查一次
Count()，写入 Redis，key 形如count:admin_user:status_0 - 后续请求直接读缓存，过期时间设为 30–60 秒（根据数据变更频率调整）
- 另起 goroutine 在数据写入（Create/Update/Delete）后触发
Count()重算并更新缓存，避免阻塞主流程 - 缓存失效时降级为查库，但不会每请求都扫全表
前端分页组件需配合后端语义
layui 的 laypage.render 默认依赖后端返回 count 和 curr，但若你已切到游标分页，就别再传 count。前端应改为：
- 隐藏页码数字栏，只留“下一页”按钮（或无限滚动）
- 响应体里返回
"has_more": true和"next_cursor": "12345"字段 - 禁用
laypage的count参数，用 JS 自行控制按钮状态 - 避免在模板里硬写
id="page"——若改用游标，这个 div 就不该由 laypage 控制
真正卡住 Beego 分页的从来不是模板怎么写，而是没想清楚“到底要不要精确总数”和“能不能接受游标语义”。缓存、游标、降级三者组合，比堆硬件或换框架更能立竿见影。
