一、问题发现篇
最近组内做了一次典型缺陷分享时，翻阅2018年的缺陷，找到了一个让我觉得“有料”的bug（别的同事测试发现的），先大致简单的描述下这个问题：
- 需要实现的功能：从一个DB库同步某一段时间的数据到另一个DB库（简化后的需求）。
- 问题描述：一次同步20w条符合记录的数据，程序同步完成后，丢数据5条。
- 问题定位：加载数据的sql，考虑到数据量大，使用了limit M,N的方法来分页加载数据，大致如下：
select * from test where Fmodify_time >= '2018-12-12 05:00:00'and Fmodify_time <= '2018-12-12 05:01:00' limit 0,2;
开发哥哥定位问题产生的原因是因为20w的数据里，存在大量的Fmodify_time 值相同的记录，由于未排序，导致这类数据服务器返回时会随机选择，从而导致分页取出来的数据存在重复或者丢失的问题。然后解决的办法就是，加上order by Fmodify_time 就能满足，因为Fmodify_time 是一个索引，索引排序是有序的。后面测试小哥用相同的数据验证不丢数据，事情就告一段落了。
二、问题验证和解决篇
巧着，18年下半年花了2个月时间在学习mysql，在学习limit 分页查找的官方文档里有看到这么一段话：https://dev.mysql.com/doc/refman/5.7/en/limit-optimization.html
（1）如果在使用order by列中的多个行具有相同的值，则服务器可以按任何顺序自由返回这些行，并且可能根据整体执行计划的不同而不同。换句话说，这些行的排序顺序相对于无序列是不确定的。
（2）影响执行计划的一个因素是 LIMIT，因此ORDER BY 使用和不使用查询LIMIT可能会返回不同顺序的行。如果确保使用和不使用相同的行顺序很重要，请LIMIT在ORDER BY子句中包含其他列以使记录具有确定性，
比如使用主键。
那这么说，之前开发说通过order by 索引能使得结果返回有序就是有问题的了，带着这个疑问和官方文档的demo，结合实际的这个缺陷，做了个小验证。
（1）建表如下： 主键：id，索引：create_time
CREATE TABLE `test` ( `id` int(11) NOT NULL AUTO_INCREMENT, `name` varchar(255) DEFAULT NULL, `create_time` timestamp NULL DEFAULT NULL ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `index_time` (`create_time`) USING BTREE ) ENGINE=InnoDB AUTO_INCREMENT=9 DEFAULT CHARSET=latin1
（2）插入数据如下：
（3）模拟分页查找，不使用order by。结果如下：
测试结果：丢数据id=1的记录，id=7的数据重复导致。看来这个问题是真的存在的。那按照开发哥哥的解决方法加上order by create_time就没问题了？
（4）模拟分页查找，使用order by + create_time（索引），如下：
测试结果：丢数据id=7的记录，id=3的数据重复导致。看来加了索引排序，还是有问题的，开发哥哥的“解决方法”实际是不能解决问题的。
（5）模拟分页查找，使用order by + create_time（索引）+ id（主键），如下：
测试结果：未丢数据。
分页查找limit M,N 的基本原理，就是服务器查找M+N条，然后返回从M条开始的后N条，导致上面问题出现的本质原因，还是mysql服务器查询后的数据排序不稳定导致。同小节的官方文档有说明当LIMIT row_count 和ORDER BY一起使用的时候，mysql不会对整个结果集排序，而是只对row_count 行的数据进行排序然后就返回。
If you combine LIMIT row_count with ORDER BY, MySQL stops sorting as soon as it has found the first row_count rows of the sorted result, rather than
sorting the entire result. If ordering is done by using an index, this is very fast. If a filesort must be done, all rows that match the query
without the LIMIT clause are selected, and most or all of them are sorted, before the firstrow_count are found. After the initial rows have been
found, MySQL does not sort any remainder of the result set.
三、未解之谜篇
大致的原理已经理清了，但是还有几个问题是没想明白的：
问题一： 如果构造测试数据的时，把id =1的记录，时间2018-12-12 05:01:00 修改为2018-12-12 04:59:00，不加order by 都不会出现丢数据和重复数据的问题：
这是为什么？数据的不同对结果是有影响的！！！那测试的时候数据要怎么构造呢？才能保证输入的数据都是有代表的呢？这个现象背后的原理是什么呢？
问题二：使用索引排序 order by+索引，是不稳定的？