分页少了数据，这个是因为链表，排序的时候没有加上主键

最新推荐文章于 2022-11-15 13:45:46 发布
原创 最新推荐文章于 2022-11-15 13:45:46 发布 · 219 阅读 · 0 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。

本文探讨了在使用链表进行数据排序时，忽略主键导致的数据缺失问题。通过对比错误与正确的SQL写法，强调了在orderby语句中包含主键对于确保数据完整性和正确排序的重要性。

分页少了数据，这个是因为链表，排序的时候没有加上主键

如我做链表，排序字段是，a.sort，
错误写法是 order by a.sort
正确写法是 order by a.sort,a.id

MySQL高频基本面试问题整理
张彦峰的博客
04-07 174万+
总结大厂MySQL高频基本面试问题整理，用于快速查缺补漏
互联网大厂高频面试题基本总结回顾（含笔试高频算法整理）
热门推荐
张彦峰的博客
04-03 176万+
1.自我介绍+项目介绍+项目细节/难点提问-------这个主要看个人的经历了，每个人都不一样 2.基础知识点考核---------还是可以去增强自己的，也是这次的主要的一些总结思路 3.算法题-----------一般都是LeetCode高频题，这个得在找工作之前的好好的练习(d对常见的高频题进行总结分析，见对应的链接提示)
在ORDER BY 子句中加入主键或唯一键
千里之行始于足下
01-09 3214
----start ORDER BY 子句非常简单，正因为简单，很多人不太在意，随意使用ORDER BY子句很可能出现逻辑错误，考虑如下情况： CREATE TABLE STUDENT ( ID INT,---学号 NAME VARCHAR(20) NOT NULL,---姓名 BIRTHDAY DATE---生日 primary key(ID) )
MySQL查询优化之order by 、 group by与分页查询优化
小小默：进无止境
09-07 3902
order by 子句尽量使用index方式排序(即using index)，避免使用filesort方式排序(即using filesort)。Index方式效率高，它指MySQL扫描索引本身完成排序，filesort则效率低。 **order by满足两种情况，会使用 index 方式排序：** * order by语句使用索引最左前列(最左匹配法则) * where子句和order by子句条件列组合满足最左匹配法则 下面给出几个实例来说明，如下所示我们创建表并为其创建组合索引(c1,c2,c3)
MySQL数据库中的排序与分页的操作详解
路宇的博客
01-23 1749
一、排序 如果没有使用排序操作，默认情况下查询返回的数据是按照添加数据的顺序显示的。 使用关键字ORDER BY进行排序操作 #练习：按照salary从高到低的顺序显示员工信息 #使用ORDER BY 对查询到的数据进行排序操作 #升序：ASC(ascend) #降序：DESC(descend) SELECT employee_id,last_name,salary FROM employees ORDER BY salary; #如果ORDER BY 后没有显式指名排序的方式的话,则默认按照升序排列。
sql 分页查询 order by和group by一起使用导致排序失效问题解决
lucky_fd的博客
11-11 6142
背景：在查询数据库数据的时候，很多时候我们需要用到group by来进行分组，同时使用order by进行排序，但是当两个同时使用时稍不注意就会出现问题。我在进行公司项目开发时就出现了问题：通过分页查询对查询的数据进行分组，通过聚合函数对分组数据处理，然后排序返回到前端显示，后面发现前端分页的数据会出现重复或丢失。分析判断应该是sql排序失效导致分页查询数据异常，后面查资料证实了这一点。
MySQL解决group by分组后未排序问题
李长渊的博客
11-15 1888
MySQL解决group by分组后未排序问题
基于redis的zSet集合做数据缓存实现分页查询 java
tianluke1234的博客
05-24 4万+
需要场景：最近公司要做手机页面展示新闻文章数据查询的优化工作，让我提个优化方案。现状是目前手机页面的数据请求系统后台，系统后台然后调用其他系统的接口，返回分页数据到前台展示，这样一来，用户每次下拉到页面底部加载更多数据都要调用其他接口，用户体验显然不是很好，那有没有更好的方案呢？ 优化方案：redis正好适合在这种场景下使用，用户每次下拉到页面底部，此时从前台页面到系统后台分...
存储引擎（C语言版本）_C语言内存管理_C语言内核编程_c语言数据结构_C语言存储引擎_
10-04
在这个存储引擎中，每个页可以存储10000条记录，且页数不限，这意味着它采用了某种形式的分页机制来管理大量数据。通过记录ID（主键）作为索引，可以迅速定位到特定记录，支持正序和倒序查找，这表明它具备了基本的...
基于Redis的增删改查与排序操作实现
例如，向 List 添加元素和向 Hash 写入数据这两个操作如果分开执行，可能会导致数据不一致。为此，Redis 提供了 MULTI/EXEC 事务机制或 Lua 脚本，可用于保证多个命令的原子执行。在 RedisDealUtil.java 中很可能...
排序分页结果错乱的问题
xiuzhentianting的博客
09-14 2411
如果order by有内容，但是不能确定唯一的位置，则sql每次查询的结果可能不一样， 如果进行分页的话，就会导致数据错乱。 分页必须保证order by 确定每行的位置，如果不能确定，可以使用多列排序方法： order by a,b
详解排序和分页(order by & limit)，及存在的坑
hellenlee22的博客
11-25 3228
limit介绍 limit用来限制select查询返回的行数，常用于分页等操作。 语法： select 列 from 表 limit [offset,] count; 说明： offset：表示偏移量，通俗点讲就是跳过多少行，offset可以省略，默认为0，表示跳过0行；范围：[0,+∞)。 count：跳过offset行之后开始取数据，取count行记录；范围：[0,+∞)。 limit中of...
解决oracle使用rownum排序分页排序字段不唯一导致分页错误
bls_sky
04-27 935
转自：http://my.oschina.net/ulyn/blog/160520点击打开链接 最近在写个列表组件ulynlist时候，测了下发现了个问题，在此记录下。 今天，列表组件调的时候，我试了下调下每个条数，每页一条，刚完成分页脚的插件时候，很高兴的点着，突然点到10来条时候发现怎么一直都是那条数据，还以为是前端插件写的有问题。后面再去看了下控制台的sql，截出sq
普通分页的底层原理是什么
最新发布
04-27
### 普通分页的实现原理及数据库底层机制 普通分页是一种常见的数据检索方式，主要用于从大规模数据集中提取部分记录供前端展示。其实现涉及 SQL 查询语句的设计以及数据库内部的工作流程。 --- #### 1. **SQL 分页查询的基本形式** 在关系型数据库中，最常用的分页方法是通过 `LIMIT` 和 `OFFSET` 关键字实现。其基本语法如下： ```sql SELECT column_name(s) FROM table_name ORDER BY some_column LIMIT number_of_rows OFFSET offset_value; ``` - `LIMIT`：指定每次查询返回的最大行数。 - `OFFSET`：跳过前面若干行后再开始返回结果。 这种模式简单直观，适用于中小规模的数据集[^2]。 --- #### 2. **分页查询的执行过程** 当一条带有 `LIMIT` 和 `OFFSET` 的 SQL 被发送到数据库时，服务器会按照以下步骤处理请求： - **全表扫描或索引扫描** 数据库首先根据 `WHERE` 条件（如果有）筛选出满足要求的所有记录集合。如果没有过滤条件，则可能需要对整个表进行扫描[^2]。 - **排序操作** 接下来依据 `ORDER BY` 子句规定的顺序排列这些记录。注意这一步可能会消耗较多资源尤其是当目标列未建立适当索引的情况下[^4]。 - **截取所需片段** 最后按照给定的偏移量 (`OFFSET`) 和限制数目(`LIMIT`) 截取出对应的部分作为最终输出。 --- #### 3. **数据库底层机制分析** 为了更深入理解分页背后的运作机理，还需探讨几个关键技术点： ##### （1）**存储引擎的作用——以 InnoDB 为例** InnoDB 是 MySQL 默认使用的存储引擎之一，在分页场景下表现出色主要得益于以下几个特性: - **聚簇索引(Clustered Index)** 主键构成的 B+Tree 结构不仅加快了定位速度还减少了随机 IO 开销因为相邻主键对应的物理地址往往靠近彼此有助于连续读取效率提升. - **缓冲池(Buffer Pool)** 经常访问的数据页面会被加载入内存区域即所谓的 Buffer Pool 当再次遇到相同或者相似查询时候可以直接命中避免反复触碰硬盘从而显著降低延迟时间. ##### （2）**页(Page)的概念及其意义** 正如之前提到过的那样 Page 表示的是 InnoDB 内部用来组织管理数据的基本单位大小固定一般为16KB .每当新增一行数据都会尝试将其插入现有空闲空间不足则开辟新的Page 同样删除也会释放相应容量形成碎片化现象所以长期频繁增删改动作容易引起性能衰退问题因此定期维护很有必要[^2]. ##### （3）**双链表与单链表的应用** 除了上述宏观层面外微观细节同样值得关注比如我们知道每个Page 内部各行之间采用单向链接相互串联起来便于快速遍历而不同Level Pages间则是依靠双向链条维持上下级关联方便跳跃式导航极大简化了复杂查询路径规划难度提升了响应速率. --- #### 4. **潜在缺陷与改进方向** 尽管基于 `LIMIT`/`OFFSET` 的传统做法易于理解和部署但仍存在一些局限之处值得我们思考并寻找解决方案: - **随着Offset增大性能急剧恶化** 因为每一次都需要先丢弃前N条再选取M条尤其面对百万级以上的大表很容易造成严重的性能瓶颈为此业界提出了诸如Keyset Pagination 或者 Offset-Free Techniques 等新型算法试图缓解这一矛盾局面[^2]. - **缺乏全局视野难以预估总量** 很多情况下客户端希望知道总共多少页才能合理安排UI界面此时单纯依赖单一Query无法达成目的于是衍生出了Count(*)辅助统计功能不过它本身也可能成为另一个耗时环节故需谨慎权衡利弊决定是否启用[^1]. --- ### 结论 综上所述，普通分页借助简单的 SQL 构造实现了便捷的数据分割展现然而背后却隐藏着复杂的交互逻辑涵盖了从高层API调用直至底层硬件指令序列转换等多个层次的内容只有全面掌握各个环节的知识才能够真正做到游刃有余地应对各种挑战情景. ---
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

BUG天

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值