参考https://www.cnblogs.com/tonghun/p/7122801.html
物理分页为什么用limit
| 物理分页 | 逻辑分页 | Cool |
|---|---|---|
| 物理分页依赖的是某一物理实体，这个物理实体就是数据库，比如MySQL数据库提供了limit关键字，程序员只需要编写带有limit关键字的SQL语句，数据库返回的就是分页结果。 | 逻辑分页依赖的是程序员编写的代码。数据库返回的不是分页结果，而是全部数据，然后再由程序员通过代码获取分页数据，常用的操作是一次性从数据库中查询出全部数据并存储到List集合中，因为List集合有序，再根据索引获取指定范围的数据。 | 概念 |
| 每次都要访问数据库，对数据库造成的负担大 | 只需要访问一次数据库 | 数据库负担 |
| 每次只读取一部分数据，占用的内存空间较小 | 一次性将数据读取到内存，占用较大的内存空间。如果使用java开发，Java本身引用的框架就占用了很多内存，这无疑加重了服务器的负担。 | 服务器负担 |
| 每次需要数据时都访问数据库，能够获取数据库的最新状态，实时性强 | 因为一次性读入到内存，数据发生了改变，数据库逇最新状态无法实时反映到操作中 | 实时性 |
| 数据库量大、更新频繁的场合 | 数据量较小、数据稳定的场合 | 服务器负担 |
| 为什么逻辑分页占用较大的内存空间，比如我有一张表，表的信息是： |
-- ---------------------------- -- Table structure for vote_record_memory -- ---------------------------- DROP TABLE IF EXISTS `vote_record_memory`; CREATE TABLE `vote_record_memory` ( `id` int(11) NOT NULL AUTO_INCREMENT, `user_id` varchar(20) NOT NULL, `vote_id` int(11) NOT NULL, `group_id` int(11) NOT NULL, `create_time` datetime NOT NULL, PRIMARY KEY (`id`), KEY `index_id` (`user_id`) USING HASH ) ENGINE=MEMORY AUTO_INCREMENT= DEFAULT CHARSET=utf8; 解释limit
limit X，Y ，跳过前X条数据，读取Y条数据
- X表示第一个返回记录行的偏移量，Y表示返回记录行的最大数目
- 如果X为0的话，即 limit 0, Y，相当于limit Y、
通过业务分析limit
- 我有一张工资表，只显示最新的前两条记录，同时进行员工姓名和工资提成备注查询
SELECT cue.real_name empName, zs.push_money AS pushMoney, zs.push_money_note AS pushMoneyNote, zs.create_datetime AS createTime FROM zq_salary zs //主表 LEFT JOIN core_user_ext cue ON cue.id = zs.user_id //从表 on之后是从表的条件 WHERE zs.is_deleted = 0 AND ( cue.real_name LIKE '%李%' OR zs.push_money_note LIKE '%测%' ) ORDER BY zs.create_datetime DESC LIMIT 2; 就相当于 ORDER BY zs.create_datetime DESC LIMIT 0,2; 
limit的效率问题
- 我有一个需求，就是从vote_record_memory表中查出到的数据，此时在id上加个索引，索引的类型是Normal，索引的方法是BTREE，分别用两种方法查询
-- 方法1 SELECT * FROM vote_record_memory vrm LIMIT ,20000 ; -- 方法2 SELECT * FROM vote_record_memory vrm WHERE vrm.id >= LIMIT 20000 
你会发现，方法2的执行效率远比方法1的执行效率高，几乎是方法1的九分之一的时间。
为什么方法1的效率低，而方法二的效率高呢？
- 分析一、
因为在方法1中，我们使用的单纯的limit。limit随着行偏移量的增大，当大到一定程度后，会出现效率下降。而方法2用上索引加where和limit，性能基本稳定，受偏移量和行数的影响不大。
- 分析二、
我们用explain来分析
可见，limit语句的执行效率未必很高，因为会进行全表扫描，这就是为什么方法1扫描的的行数是400万行的原因。方法2的扫描行数是47945行，这也是为什么方法2执行效率高的原因。我们尽量避免全表扫描查询，尤其是数据非常庞大，这张表仅有400万条数据，方法1和方法就有这么大差距，可想而知上千万条的数据呢。
能用索引的尽量使用索引，type至少达到range级别*，这不是我说的，这是阿里巴巴开发手册的5.2.8中要求的*
我不用索引查询到的结果和返回的时间和方法1的时间差不多：
limit物理分页
| 页数 | 每页显示的行数 | limit语句 | 计算方式 |
|---|---|---|---|
| 第一页 | 20 | limit 0,20 | limit 0*20,20 |
| 第二页 | 20 | limit 20,20 | limit 1*20,20 |
| 第三页 | 20 | limit 40,20 | limit 2*20,20 |
| 第四页 | 20 | limit 60,20 | limit 3*20,20 |
| 如果是SQL语句来进行分页的话，我们可以看到的是： |
-- 首页 SELECT * from vote_record_memory LIMIT 0,20; -- 第二页 SELECT * from vote_record_memory LIMIT 20,20; -- 第三页 SELECT * from vote_record_memory LIMIT 40,20; -- 第四页 SELECT * from vote_record_memory LIMIT 60,20; -- n页 SELECT * from vote_record_memory LIMIT (n-1)*20,20; 
因而，如果是用java的话，我们就可以写一个方法，有两个参数，一个是页数，一个每页显示的行数
/ * @description 简单的模拟分页雏形 * @author zby * @param currentPage 当前页 * @param lines 每页显示的多少条 * @return 数据的集合 */ public List<Object> listObjects(int currentPage, int lines) {
String sql = "SELECT * from vote_record_memory LIMIT " + (currentPage - 1) * lines + "," + lines; return null; } 版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请联系我们举报，一经查实，本站将立刻删除。
发布者：全栈程序员-站长，转载请注明出处：https://javaforall.net/218204.html原文链接：https://javaforall.net
