【MySQL数据库 | 第二十四篇】Limit语句的性能问题和调优策略

前言：

MySQL作为最流行的关系型数据库管理系统之一，被广泛应用于各种规模和类型的应用程序中。其强大的功能和灵活的查询语言使得开发人员能够高效地执行各种数据操作和分析。

然而，在处理大量数据或复杂查询时，一些开发人员可能会遇到性能问题，其中一个常见的问题就是与LIMIT子句相关的性能问题。

目录

前言：

Limit：

调优策略：

1.主键连续自增情况：

 2.根据非主键字段排序的分页查询：

3.记录上一次分页查询的最大id。

总结：

---

Limit：

这是我们在查询过程中会经常使用到的一个关键字，用于分页操作。下图为一个实例

比方我们要在这张表中执行这样一条语句：

select * from emp limit 3,5

 也就是从这张表的第三条数据开始，往后查五条数据。下图为查询结果：

而这条语句真正的执行过程为：从第一条数据开始，往后查询八条数据，然后丢弃掉前三条数据

从这里其实就能看出：一般的Limit语句在小数据量的表中的查询性能可能还不受限，当在数据量大的表中查询表末的数据的时候性能就会出现明显瓶颈，比如：

select * from table limit 10000000,10

那么在这条语句中，我们要先查询10000010条记录，然后抛弃前10000000条记录，返回剩余的十条记录。而这就是传统的limit语句存在的性能问题。

调优策略：

1.主键连续自增情况：

如果我们的主键是连续且自增的，那么以下两条SQL语句的执行结果是一样的（案例中的id是主键）：

select * from emp  limit 999990,10select * from emp where id > 999990 limit 10

我们分别来看一看两个SQL的执行计划：

select * from emp  limit 999990,10

select * from emp where id > 999990 limit 10

相比之下，我们可以看出当我们采用>999990这种简单的优化之后，查询的type由全表ALL变为了range。

但是这种简单的调优在大多数情况下都不合适，因为我们的业务中基本都会存在删除的业务，可能会破坏主键的连续性。

而且如果原SQL是order by 非主键的字段，那么就会造成这两条SQL语句查询结果的不一致，

这种改写必须满足两个条件：主键自增且连续，结果是按照主键递增的。

 2.根据非主键字段排序的分页查询：

比如我们要根据name进行排序并分页：

select * from emp order by name limit 10,5

这条语句中name是非主键字段，那么这条语句就不会走索引，通过查看执行计划可以得知：

那么其实我们的整体优化思路就是：让排序的时候尽可能返回字段减少，我们先通过排序和分页操作查询出主键，再根据主键去查找对应的记录。

 也就是这样一条SQL语句：

select * from emp e 
inner  join (select id from emp order by name limit 10,5) ed 
one.id = ed.id

这样的话，我们的两次查询一次先通过子查询查出指定范围内的id，再查询出id对应的记录，查看这条的执行计划：

优化后的索引使用的排序成为了索引排序。

3.记录上一次分页查询的最大id。

这种方法其实是第一个方法的变种，当我们不断的记录上一次查询的最大id的时候，我们就可以不断的把SQL语句优化为：

select * from emp where id > （记录上一次最大id） limit 返回条数

总结：

在数据库查询中，使用LIMIT关键字可以限制返回的结果数量，这在处理大数据集或深度分页时特别有用。然而，使用LIMIT也可能导致性能问题。本文讨论了一些与LIMIT关键字相关的性能问题，并提出了一些解决方案。

首先，我们探讨了LIMIT的工作原理以及它如何影响数据库的性能。我们了解到，LIMIT可能会导致数据库在执行查询时遍历大量数据，这会增加查询的时间和资源消耗。

综上所述，虽然LIMIT在处理大数据集或深度分页时非常有用，但我们在使用时也需要注意可能带来的性能问题。通过合理优化查询和选择合适的解决方案，我们可以最大程度地提高数据库的性能，从而提升系统的整体效率和用户体验。

---

如果我的内容对你有帮助，请点赞，评论，收藏。创作不易，大家的支持就是我坚持下去的动力！