查看原文
其他

order by 结果不准确的问题

杨奇龙 yangyidba 2022-10-13

一 介绍 
     相信大部分DBA在和开发打交道的过程中,经常会遇到分页查询 order by 排序这样的需求。本文源于生产过程中的案例,5.6,5.7.16版本的数据库使用limit和order by 一个非唯一字段时,结果集并不总是确定的.已经确定为bug,详见:http://bugs.mysql.com/bug.php?id=72076。提醒读者朋友注意。

二 分析 
环境准备 

  1. CREATE TABLE `tb1` (

  2.   `id` bigint(20) NOT NULL AUTO_INCREMENT,

  3.   `a` decimal(19,2) NOT NULL,

  4.   `acid` bigint(20) NOT NULL,

  5.   `prid` bigint(20) NOT NULL,

  6.   PRIMARY KEY (`id`),

  7.   KEY `idx_prid` (`prid`),

  8.   KEY `idx_acid` (`acid`)

  9. ) ENGINE=InnoDB AUTO_INCREMENT=0 DEFAULT CHARSET=utf8

注意字段a 上面是没有索引的。
初始化数据

  1. INSERT INTO `tb1` (`id`, `a`, `acid`, `prid`) 

  2. VALUES (1,2.00,3,2),(2,3.00,3,2),(3,4.00,2,3),(4,5.00,2,3),(5,6.00,2,3),(6,8.00,2,3),(7,10.00,2,3),(8,12.00,2,3),(9,16.00,2,3),(10,20.00,2,3),(11,6.00,2,4),(12,8.00,2,4),(13,10.00,2,4),(14,12.00,2,4),(15,5.00,2,2),(16,6.00,2,2);

2.1 执行两个根据非索引字段且有重复值的 order by a排序

  1. mysql> select * from tb1 order by a desc limit 4;

  2. +----+-------+------+------+

  3. | id   | a     | acid | prid |

  4. +----+-------+------+------+

  5. | 10 | 20.00 | 2    | 3    |

  6. | 9  | 16.00 | 2    | 3    |

  7. | 14 | 12.00 | 2    | 4    |

  8. | 8  | 12.00 | 2    | 3    |

  9. +----+-------+------+------+

  10. 4 rows in set (0.00 sec)

得到id 10, 9, 14, 8 的结果集,a=12 的有两个id 分别为14,8. 再次执行获取3条记录。

  1. mysql> select * from tb1 order by a desc limit 3;

  2. +----+-------+------+------+

  3. | id | a     | acid | prid |

  4. +----+-------+------+------+

  5. | 10 | 20.00 | 2    | 3    |

  6. | 9  | 16.00 | 2    | 3    |

  7. | 8  | 12.00 | 2    | 3    |

  8. +----+-------+------+------+

  9. 3 rows in set (0.00 sec)

得到id 为10 9 8 的结果集,第三条记录变为id=8的记录,而非id=14,结果不准确。
我们为a字段加上索引,再次查询 

  1. mysql> alter table tb1 add key ind_tb1_a(a);

  2. Query OK, 0 rows affected (0.00 sec)

  3. Records: 0 Duplicates: 0 Warnings: 0

  4. mysql> select * from tb1 order by a desc limit 3; 

  5. +----+-------+------+------+

  6. | id | a     | acid | prid |

  7. +----+-------+------+------+

  8. | 10 | 20.00 | 2    | 3    |

  9. | 9  | 16.00 | 2    | 3    |

  10. | 8  | 12.00 | 2    | 3    |

  11. +----+-------+------+------+

  12. 3 rows in set (0.00 sec)

得到id 为10 9 8 的结果集,此时第三条记录仍为id=8。

  1. mysql> select * from tb1 order by a desc limit 4;

  2. +----+-------+------+------+

  3. | id | a     | acid | prid |

  4. +----+-------+------+------+

  5. | 10 | 20.00 | 2    | 3    |

  6. | 9  | 16.00 | 2    | 3    |

  7. | 14 | 12.00 | 2    | 4    |

  8. | 8  | 12.00 | 2    | 3    |

  9. +----+-------+------+------+

  10. 4 rows in set (0.00 sec)

得到id 为10, 9, 14, 8 的结果集,第三条记录变化为id=14
从上面的测试来看对于一个非唯一字段无论是否含有索引,执行order 排序结果集都是不确定的。


三 解决方法 
3.1 业务属性确保 a 字段不能唯一,则需要针对排序结果再加上唯一字段的排序 比如主键id 。

  1. mysql> select * from tb1 order by a desc ,id desc limit 4;

  2. +----+-------+------+------+

  3. | id | a     | acid | prid |

  4. +----+-------+------+------+

  5. | 10 | 20.00 | 2    | 3    |

  6. | 9  | 16.00 | 2    | 3    |

  7. | 14 | 12.00 | 2    | 4    |

  8. | 8  | 12.00 | 2    | 3    |

  9. +----+-------+------+------+

  10. 4 rows in set (0.00 sec)

  11. mysql> select * from tb1 order by a desc ,id desc limit 3;

  12. +----+-------+------+------+

  13. | id | a     | acid | prid |

  14. +----+-------+------+------+

  15. | 10 | 20.00 | 2    | 3    |

  16. | 9  | 16.00 | 2    | 3    |

  17. | 14 | 12.00 | 2    | 4    |

  18. +----+-------+------+------+

  19. 3 rows in set (0.00 sec)

使用order by id/unique_key 排序之后,前三个结果集是一致的10,9,14 。 结果集满足我们的需求。从而解决不确定性带来的问题。
3.2 是否可以去掉不必要的order by,这个是由业务逻辑决定的。


四 总结
     DBA在和开发沟通/培训过程中要注意这一点:5.6版本基于非唯一字段的排序 结果集是不确定的。如果业务逻辑对分页或者order by结果集有比较高的严格要求 ,请记得利用唯一键排序。 


您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存