MySQL 查询性能: 越少的结果集越慢越多的越快? 1/2

随着人工智能 AI 应用的日益普及，短视频的流行，越来越多的人选择短平快的视觉享受，越来越少的人选择读文字，尤其是长篇文字读物。
这是一种时代的选择，同时也让我们深思背后的原因，文字材料到底会不会被全面的的视听材料取代? 我们坚守文字材料及相应的读物，是否还有意义?
经过那么多的探索，我们认为文字材料依然是一种传统的文明与文化的载体，需要继续传承下去。

最近在优化 UfqiNews 有福新闻时发现一个现象，在同样一个 SQL 查询语句中如果 limit 10 ，也即只取10条查询结果时，运行时的查询时长比 limit 100 还要长。这很反直觉反经典反传统，为何查询的结果越少，反而耗时越多呢?

AI 时代，个人尝试的越多就收获的越多，我们将这个难解的问题抛给了 OpenAI 的 ChatGPT , 很快就有了非常明确的深度解读，以及相应的解决方法。

问题描述:
当我查询一个sql时，如果用:
mysql> select id, title, imgurl, iclick from news_pagetbl where inserttime>’2026-01-16 09:48:14′ and iclick>0 order by iclick desc limit 100;
Empty set (0.01 sec)
会很快出结果, 耗时 0.01 秒，如果我 limit 10时，却卡住很长时间不能出结果：
mysql> select id, title, imgurl, iclick from news_pagetbl where inserttime>’2026-01-16 09:48:14′ and iclick>0 order by iclick desc limit 10;
…. 卡住….，耗时几分钟没有结果….

这是一个非常经典、但很反直觉的 MySQL 查询性能问题 👍
结论先给你一句话版：

LIMIT 10 反而更慢，是因为 MySQL 选了“错误的执行计划”，导致需要扫描 / 排序更多数据。

下面我一步步把为什么会这样、MySQL 在干什么、以及如何彻底解决讲清楚。

一、你这个现象为什么“看起来不合理”

你有两条 SQL：

-- 很快
SELECT id, title, imgurl, iclick
FROM news_pagetbl
WHERE inserttime > '2026-01-16 09:48:14'
  AND iclick > 0
ORDER BY iclick DESC
LIMIT 100;

-- 很慢， 反而卡住
SELECT id, title, imgurl, iclick
FROM news_pagetbl
WHERE inserttime > '2026-01-16 09:48:14'
  AND iclick > 0
ORDER BY iclick DESC
LIMIT 10;

直觉：
LIMIT 越小 → 返回越少 → 应该越快 ❌，
现实：
LIMIT 10 → 更慢甚至“卡死” ✔️。

二、核心原因（重点）

👉 MySQL 为 LIMIT 10 选择了不同的执行计划

MySQL 优化器在看到：

ORDER BY iclick DESC LIMIT 10

时，很容易误判：

“我只要 10 条，那我用 iclick 的索引倒序扫，很快就能拿到前 10 条。”

但问题是：

⚠️ 你的 WHERE 条件还有：

inserttime > '2026-01-16 09:48:14'

如果 没有一个同时满足：

(inserttime, iclick)  或  (iclick, inserttime)

这样的联合索引，那么 MySQL 会：

LIMIT 10 时的执行方式（慢）：

先按 iclick DESC 扫索引
每一条都去回表
再判断 inserttime > xxx
如果不满足 → 丢弃
一直扫，直到凑够 10 条为止

⚠️ 如果最近 inserttime 的数据很少，
⚠️ 或者 iclick 高的记录大多是旧数据。

👉 MySQL 可能要扫 成千上万甚至几十万行 才凑够 10 条

于是就“卡住了”。

LIMIT 100 时反而快的原因

LIMIT 100 时，优化器往往会选择：

先用 inserttime 条件过滤 → 再排序 → 再 LIMIT

也就是：

根据 inserttime 范围扫描
得到一个“较小的临时结果集”
在内存/临时表中 ORDER BY iclick
取前 100 条

📌 虽然多返回了 90 条，但总扫描量反而更小。

三、你现在大概率的索引状态（推测）

你很可能有以下其中之一：

只有 iclick 索引
或只有 inserttime 索引
或索引顺序不对

但没有一个“覆盖你这个查询”的联合索引。

四、如何 100% 解决（推荐方案）

✅ 最优解：建一个正确的联合索引

ALTER TABLE news_pagetbl
ADD INDEX idx_time_click (inserttime, iclick DESC);

👉 这是最推荐的方案

为什么？

WHERE inserttime > ...：可以用索引范围扫描
ORDER BY iclick DESC：同一个索引内顺序已排好
LIMIT 10：只扫极少行，直接停

⚡ 查询会变成“瞬间返回”。

🧠 如果你不能建索引（临时止血方案）

方案 1：强制索引（不推荐长期用）

SELECT /*+ FORCE_INDEX(idx_inserttime) */
       id, title, imgurl, iclick
FROM news_pagetbl
WHERE inserttime > '2026-01-16 09:48:14'
  AND iclick > 0
ORDER BY iclick DESC
LIMIT 10;

或：

SELECT ...
FROM news_pagetbl FORCE INDEX (idx_inserttime)
WHERE ...

方案 2：子查询“先限范围再排序”

SELECT id, title, imgurl, iclick
FROM (
    SELECT id, title, imgurl, iclick
    FROM news_pagetbl
    WHERE inserttime > '2026-01-16 09:48:14'
      AND iclick > 0
    ORDER BY inserttime DESC
    LIMIT 5000
) t
ORDER BY iclick DESC
LIMIT 10;

📌 本质：
人工帮 MySQL 缩小排序数据量。

五、如何验证我说的是不是你这个问题（强烈建议）

你可以直接跑：

EXPLAIN SELECT id, title, imgurl, iclick
FROM news_pagetbl
WHERE inserttime > '2026-01-16 09:48:14'
  AND iclick > 0
ORDER BY iclick DESC
LIMIT 10;

如果你看到：

type = index 或 ALL
rows 非常大
Using filesort
用的是 iclick 单索引

👉 那就 完全命中这个问题。

六、一句话总结（记住这个坑）

MySQL 在 ORDER BY + LIMIT 时，LIMIT 越小，越容易选错索引，反而越慢。

没有“where + order by”联合索引 = 性能炸弹。

下一篇继续 MySQL 查询: 越复杂的 SQL 查询反而更快?

有福新闻 UfqiNews

这里呈现热点全局, 尺寸间一览所有令人关注的疑点焦点;
这里表达条分缕析, 视野内一睹各个脉络清晰的故事主线.
有福新闻UfqiNews 带来全新的资讯阅览体验, 不信息过载, 亦不信息茧房.

在寻求最大社会共识和满足千人千面之间谋取平衡,
在满足广泛涉猎与追求术业专攻之间谋取平衡.
媒介插上人工智能的翅膀将如虎添翼, 与资讯比翼双飞.
新闻爱好者的良心之选, 匠心之作.

UfqiNews presents the hot spots globally, with all interesting points at a glance.
Information is organized here and there is a clear storyline within every single detail.
UfqiNews brings a brand new reading experience, no information overload and no information Cocoons,

In seeking a balance of the maximum social consensus and meeting thousands of people for each interest,
In achieving a balance between satisfying a wide range of hunting and pursuing specialization in the industry.
That media is being born with wings of the artificial intelligence will be even more powerful and the information will fly swifter than ever.
Better choices of newsreaders and the art of work from them.