activedataprovider是yii分页首选，但需避免提前执行查询、深分页、排序无索引、参数丢失及count慢等问题；应结合游标分页、索引优化与显式参数透传。
Yii 2.0.45 中分页性能问题，核心不在框架本身，而在于分页逻辑是否贴合数据库真实执行路径。用对 ActiveDataProvider 是最稳妥的起点，但光靠它还不够——关键得避开深分页、排序不稳定、参数丢失、总数误查这几类高频坑。
优先用 ActiveDataProvider，但别提前触发查询
ActiveDataProvider 是 Yii 分页的“官方推荐解”，它把 count() 和带 LIMIT/OFFSET 的主查询交给底层自动处理，避免你手动写两次 SQL（一次算总数、一次取数据）。但前提是：千万别在配置前就调用 $query->all() 或 $query->count()，否则会多查一次，白耗资源。
-
正确做法：传一个未执行的
ActiveQuery实例进去，比如new ActiveDataProvider(['query' => User::find()->where(['status' => 1])]) -
pageSize 控制每页条数，默认从
$_GET['page']读页码，如需改参数名（比如用p），加'pageParam' => 'p' -
排序直接配 sort：
'sort' => ['defaultOrder' => ['created_at' => SORT_DESC]]，不用手写orderBy
LinkPager 丢参数？显式透传业务字段
LinkPager 默认只保留 page 和 per-page 这类分页参数，category=3、q=search 这类业务参数会被清掉——这不是 bug，是设计如此。解决方法是在 pagination 配置里加 params，但不能直接 dump 整个 $_GET，防止敏感参数泄露或注入风险。
-
安全写法：显式列出要透传的键，例如
'params' => ['category' => Yii::$app->request->get('category'), 'q' => Yii::$app->request->get('q')] -
启用 URL 美化时 route 必须写全，比如
'route' => 'article/index'，不能省略，否则链接跳转失败
深分页卡顿？换思路，别硬扛 OFFSET
当页码很大（比如第 5000 页）、OFFSET 值上万时，MySQL 实际要扫描并丢弃前面所有匹配行，性能断崖式下跌。ActiveDataProvider 也救不了这种场景——它只是帮你封装了 LIMIT/OFFSET，没改变底层执行逻辑。
-
适用场景优先用游标分页：客户端传上一页最后一条记录的排序字段值（如
last_id=12345），服务端改写为WHERE id > 12345 ORDER BY id LIMIT 20 -
不支持随机跳页？那就限制页码范围：后端校验
page ，超限返回空或提示“已到最后”；前端禁用页码输入框，只留“下一页”按钮 -
模糊查询或无索引字段导致 count() 慢？缓存总数：用
Yii::$app->cache->set('user_count', $count, 300)，5 分钟过期，比每次查快得多
排序字段没索引？分页结果会错乱
分页必须搭配 ORDER BY，否则 MySQL 返回顺序不可控，翻页时数据重复、遗漏、“反复横跳”都是常态。更关键的是：如果 ORDER BY 字段没走索引，就会触发 Using filesort，性能雪上加霜。
-
检查执行计划：用
EXPLAIN看type是否为range或index，Extra不含Using filesort -
复合索引要覆盖 WHERE + ORDER BY：比如查询
WHERE status = 1 ORDER BY created_at DESC，建索引INDEX idx_status_ctime (status, created_at) -
避免在排序中用函数：像
ORDER BY DATE(created_at)无法走索引，应改用created_at字段本身，并确保类型和查询条件一致
