mysql和postgresql中获取前10条记录均使用select * from users limit 10，语法一致；但必须配合order by（如order by created_at desc）才能确保结果确定性，否则顺序不确定。
MySQL 和 PostgreSQL 中用 LIMIT 获取前10条
大多数现代关系型数据库支持 LIMIT 语法，直接加在查询末尾即可。注意它必须放在 ORDER BY 之后（如果有的话），否则结果顺序不确定。
- 如果不关心顺序，写成
SELECT * FROM users LIMIT 10 - 如果要按创建时间取最新10条，得加上
ORDER BY created_at DESC LIMIT 10 -
LIMIT在 MySQL 和 PostgreSQL 中行为一致，但 SQLite 也支持，SQL Server 和 Oracle 不支持该写法
SQL Server 中用 TOP 取前10条
SQL Server 不认 LIMIT，得用 TOP 关键字，且必须紧跟在 SELECT 后面。
- 正确写法：
SELECT TOP 10 * FROM users - 要带排序时，
TOP不能单独控制“前10”，必须配合ORDER BY，否则可能每次返回不同记录 - 如果想跳过前5条再取10条（分页），
TOP本身不支持 offset，得用OFFSET-FETCH（SQL Server 2012+）或子查询模拟
Oracle 中用 ROWNUM 或 FETCH FIRST
Oracle 12c 之前只能靠 ROWNUM，但它是在结果集生成过程中逐行编号的，所以必须嵌套查询才能正确限制前10条：
- 错误写法：
SELECT * FROM users WHERE ROWNUM （排序发生在 ROWNUM 分配之后，结果不是最新的10条） - 正确写法：
SELECT <em> FROM (SELECT </em> FROM users ORDER BY updated_at DESC) WHERE ROWNUM
Oracle 12c+ 支持标准 SQL 的 FETCH FIRST 10 ROWS ONLY，更直观，也兼容其他支持该语法的数据库（如 PostgreSQL 13+）。
为什么不能只写 SELECT * FROM table LIMIT 10 就完事？
看似简单，但实际中容易踩三个坑：
- 没加
ORDER BY：数据库不保证物理存储顺序，多次执行可能返回不同10条，尤其在有并发写入时 - 在分页场景下误用：比如“第2页”想用
LIMIT 10 OFFSET 10，当表数据频繁增删时，可能漏掉或重复记录 - ORM 自动生成语句时忽略方言差异：Django 的
.[:10]、SQLAlchemy 的.limit(10)通常能适配，但手写原生 SQL 时必须确认目标数据库类型
真正安全地取“前10条”，核心不是语法怎么写，而是你想表达的业务含义是否明确——是任意10条？最新10条？还是按某个字段排好序后的前10？这个意图一旦模糊，后续分页、导出、测试都会出问题。
