当您分页时，按字母顺序分页会逐渐变慢（MySQL）

发布于 2024-09-18 19:34:48 字数 467 浏览 4 评论 0原文

我有一个超过 100k 行的数据集，所以它不是很小，但也不是很大。翻阅结果时，当您转到较高的页面时，速度会逐渐变慢。换句话说，这个查询：

SELECT * FROM items WHERE public = 1 ORDER BY name LIMIT 0,10

执行速度比我在 name 上有索引要快得多

SELECT * FROM items WHERE public = 1 ORDER BY name LIMIT 10000,10

，我曾经在 public 上有一个索引，但我删除了它，因为它似乎进一步降低性能。

这里有什么想法吗？有没有一种简单的方法可以加快速度？我正在考虑取消查看较高页面的功能，因为除了机器人之外，没有人真正浏览过第 2 或第 3 页，而且他们有更简单的方法来查找该内容。

原文

I've got a dataset with over 100k rows, so it's not tiny, but not huge either. When paging through the results, it gets progressively slower as you go to higher pages. In other words, this query:

SELECT * FROM items WHERE public = 1 ORDER BY name LIMIT 0,10

executes much faster than

SELECT * FROM items WHERE public = 1 ORDER BY name LIMIT 10000,10

I have an index on name, and I used to have an index on public, but I removed it since it seemed to degrade performance even more.

Any ideas here? Is there an easy way to speed this up? I'm considering removing the ability to view the higher pages since nobody really browses past page 2 or 3, except robots, and there are easier ways for them to find that content.

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

你的呼吸 2024-09-25 19:34:48

大 LIMIT 问题：

谨防大 LIMIT 如果您需要前几行，那么使用索引进行排序是有效的，即使发生了一些额外的过滤，因此您需要按索引扫描更多行，然后按 LIMIT 请求。但是，如果您正在处理具有大偏移量的 LIMIT 查询，效率将会受到影响。 LIMIT 1000,10 可能比 LIMIT 0,10 慢得多。确实，大多数用户不会在结果中浏览超过 10 页，但搜索引擎机器人很可能会这样做。我见过机器人在我的项目中查看 200 多个页面。此外，对于许多未能处理好这一问题的网站来说，发起 DOS 攻击非常简单——通过少量连接请求大量页面，这就足够了。如果您不执行任何其他操作，请确保阻止页码太大的请求。
对于某些情况，例如，如果结果是静态的，则预先计算结果可能是有意义的，以便您可以查询它们的位置。
因此，您将拥有 1000 到 1009 之间的 WHERE 位置，而不是使用 LIMIT 1000,10 进行查询，该位置对于任何位置都具有相同的效率（只要已索引）

资源：