MySQL分页查询limit踩坑记

本篇文章给大家分享《MySQL分页查询limit踩坑记》，覆盖了数据库的常见基础知识，其实一个语言的全部知识点一篇文章是不可能说完的，但希望通过这些问题，让读者对自己的掌握程度有一定的认识(B 数)，从而弥补自己的不足，更好的掌握它。

1. 问题背景

线上有一个批处理任务，会批量读取昨日的数据，经过一系列加工后，插入到今日的表中。表结构如下：

CREATE TABLE `detail_yyyyMMdd` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT '主键',
  `batch_no` varchar(64) NOT NULL COMMENT '批次号',
  `order_id` varchar(64) NOT NULL COMMENT '订单ID',
  `user_id` varchar(64) NOT NULL COMMENT '用户ID',
  `status` varchar(4) NOT NULL COMMENT '状态',
  `product_id` varchar(32) NOT NULL COMMENT '产品ID',
  PRIMARY KEY (`id`),
  KEY `idx_batchno_userid` (`batch_no`,`user_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='明细表';

因数据量较大，批量读取昨日数据时，使用了分页查询limit语句，查询sql如下：

SELECT id,batch_no,order_id,user_id,status,product_id FROM detail_yyyyMMdd WHERE batch_no=‘batch_type_yyyyMMdd’ LIMIT ?,?;

从某一天开始，客服频繁收到客诉，反馈数据未更新。

2. 问题排查

初步排查，客诉反馈的数据确实没有插入。线上增加了一些业务日志后，发现分页查询昨日数据时，第二次查询的结果集与第一次查询的结果集有重复数据。

与DBA沟通，确认了客诉爆发前一天做了一次数据库变更，兄弟团队为了解决一个慢查询问题，增加了一个索引，变更sql如下：

ALTER TABLE `detail_yyyyMMdd` ADD INDEX `idx_batchno_status_productid` (`batch_no`, `status`, `product_id`);

DBA分析，该变更sql上线前，分页查询会走idx_batchno_userid索引，上线后则走idx_batchno_status_productid，而该索引存在大量重复记录，导致每次分页查询的数据都可能和之前的重复。

为什么索引有重复记录时，分页查询的数据就可能与之前的重复呢？在网上搜了下，这里贴一篇官方的文档：https://dev.mysql.com/doc/ref...

If multiple rows have identical values in the ORDER BY columns, the server is free to return those rows in any order, and may do so differently depending on the overall execution plan. In other words, the sort order of those rows is nondeterministic with respect to the nonordered columns.

One factor that affects the execution plan is LIMIT, so an ORDER BY query with and without LIMIT may return rows in different orders.

If it is important to ensure the same row order with and without LIMIT, include additional columns in the ORDER BY clause to make the order deterministic.

在MySQL 5.6的版本上，优化器在遇到order by limit语句时，做了个查询优化，即使用了priority queue（优先级队列）。采用priority queue能够根据limit N维护一个大小为N的堆，在排序的过程中，只用保留N条记录即可。但堆排序是一个不稳定的排序算法，所以当排序字段值存在重复时，返回的数据顺序可能会不一样，其中一个影响因素就是limit。

解决方案：查询语句加上order by id（保证排序字段的唯一性），上线后，问题得到解决。

但仍然存在两个疑点：

• 原来的索引idx_batchno_userid也会有重复记录，为什么一直没有爆出问题？
• 线上的查询语句只有limit，没有order by，可以直接按照索引的有序性（索引聚簇表）进行读取并分页，不需要触发priority queue优化。

3. 问题定位

仔细观察了两次分页查询的结果集后发现，两次结果集的数据顺序分别对应两个索引，即第一次分页查询走了索引idx_batchno_userid，第二次分页查询走了索引idx_batchno_status_productid，两个索引的数据顺序是不一样的，从而导致两次分页查询的数据存在重复。与DBA交流，MySQL的优化器会基于成本选择最优的索引，而这两个索引的成本相差不大。

这个结论在线下得到复现，但并不能稳定复现。在总结果集没有变化的情况下，两次分页查询分别走了不同索引的根因，还有待继续深挖。

End

MySQL使用limit进行分页查询时，可能会出现重复数据，可以通过加上order by子句并保证排序字段的唯一性来解决。

今天关于《MySQL分页查询limit踩坑记》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！