总结

有些朋友问：MySQL的分页似乎是个问题。有没有办法优化它

XX在互联网上推荐了一些分页方法，但似乎不可行。你能评论一下吗

方法总结

方法1：直接使用数据库提供的SQL语句

语句样式：在MySQL中，可以使用以下方法：从表限制m，n中选择*的名称

适应场景：适用于较少的数据（千分之元组）

原因/缺点：全表扫描是缓慢的，和一些数据库结果集是不稳定的，如一旦回到1,2,3，回到2,1,3在另一个时间。从结果集的m位置限制n的输出，其余的丢弃。

方法2：使用索引创建主键或唯一索引（假设每页10页）。

表式：在MySQL数据库中，可以通过以下方法：在选择表的名称，其中id_pk >（pagenum10）限M

适应场景：适用于大量数据（数万元组）

原因是：索引扫描速度快。一个朋友建议：由于数据查询不按pk_id，就会有数据丢失，唯一的方法3。

方法3：基于索引重新排序

表式：在MySQL数据库中，可以通过以下方法：选择表名id_pk >（pagenum10）的id_pk ASC极限m阶

自适应场景：适用于数据量大的情况（元组数上万）。后顺序是主键或唯一最好的栏目，这样可以消除OrderBy操作指标，但结果是稳定（稳定的意义，请看方法1）。

原因：指数扫描，速度会很快。但MySQL排序操作，只有ASC没有DESC（降序是假的，未来将做真实的描述，期待…。

方法4：使用准备（第一个问号代表pagenum，其次，基于指数）。代表元组数量每页

表式：在MySQL数据库中，可以通过以下方法：从桌子上id_pk >选择准备stmt_name名称（）通过id_pk ASC极限m阶

适应场景：大量数据

原因是：索引扫描的速度会很快。准备语句比普通查询快一点。

方法5：存储过程类（最好融合上述方法4）

语句样式：不再给出

适应场景：大量数据。作者推荐的方法

原因：操作被封装在服务器中，速度相对较快。

方法6：反面方法

sql_calc_found_rows写在互联网上。没有理由，不要模仿