关键在于有合适索引+明确ORDER BY排序+LIMIT配合覆盖索引；仅SELECT * FROM t LIMIT 10通常无法避免全表扫描，必须通过EXPLAIN验证执行计划是否使用索引扫描。

在SQL中只查前10条记录且避免全表扫描，关键在于有合适的索引 + 明确的排序依据 + 使用 LIMIT/TOP/ROWNUM 等语法。没有 ORDER BY 的 LIMIT 很可能仍会触发全表扫描（尤其在无索引或统计信息不准时），因为数据库无法确定哪10条是“前10条”——它必须先拿到全部数据再截断。

必须配合 ORDER BY 和对应索引

仅写 SELECT * FROM t LIMIT 10 通常无法避免全表扫描，除非该表极小或优化器基于统计信息做了特殊处理（不可靠）。真正高效的方式是：

• 明确指定排序字段，例如 ORDER BY created_time DESC
• 确保该排序字段上有有效索引（如 INDEX(created_time) 或 INDEX(status, created_time)）
• 查询语句形如：SELECT * FROM orders WHERE status = 'paid' ORDER BY created_time DESC LIMIT 10

此时数据库可利用索引快速定位并顺序读取前10条满足条件的行，无需扫描整张表。

避免 SELECT *，只查必要字段

即使有索引，若查询列未被覆盖，数据库仍需回表（Index Lookup + Table Access）；若索引已包含所有需要的字段（覆盖索引），就能完全避免访问数据页：

• 差： SELECT * FROM users ORDER BY id LIMIT 10 → 可能回表（取决于索引结构）
• 好： SELECT id, name, email FROM users ORDER BY id LIMIT 10，并建索引 INDEX(id, name, email)

注意不同数据库的语法与行为差异

各数据库对“取前N条”的实现和优化支持略有不同：

• MySQL / PostgreSQL：用 LIMIT 10，配合索引效果稳定
• SQL Server：推荐用 TOP 10 + ORDER BY，或更可控的 OFFSET 0 ROWS FETCH NEXT 10 ROWS ONLY
• Oracle 12c+：用 FETCH FIRST 10 ROWS ONLY；老版本用 ROWNUM ，但必须嵌套在带 ORDER BY 的子查询中，否则排序失效

验证是否真的避免了全表扫描

执行前务必看执行计划（EXPLAIN）：

• MySQL：运行 EXPLAIN SELECT ... LIMIT 10，确认 type 是 range 或 index，key 显示用了哪个索引，rows 接近10而非表总行数
• PostgreSQL：用 EXPLAIN (ANALYZE, BUFFERS)，观察是否为 Index Scan 或 Index Only Scan
• 避免看到 Seq Scan（PostgreSQL）、ALL（MySQL）或 TABLE ACCESS FULL（Oracle）