可用，但仅限MySQL单表DELETE且ORDER BY必须与LIMIT同时使用；PostgreSQL不支持该语法，需用CTE或子查询替代。
ORDER BY + LIMIT 在 DELETE 中是否可用？
MySQL 8.0+ 和 PostgreSQL 支持 DELETE ... ORDER BY ... LIMIT，但 SQLite 和早期 MySQL（DELETE FROM t ORDER BY created_at ASC LIMIT 100 在 MySQL 5.5 上会报错：You have an error in your SQL syntax。
实操建议：
- 先查当前数据库版本：
SELECT VERSION()（MySQL）或SELECT version()（PostgreSQL） - 若版本不支持，必须改用子查询或临时表，不能硬套语法
- 注意：SQL Server 完全不支持
LIMIT，得用TOP+CTE或ROW_NUMBER()
MySQL 5.7+ 安全删除前N条旧数据的写法
假设表 logs 有 id 和 created_at 字段，要删最早插入的 1000 条：
DELETE FROM logs ORDER BY created_at ASC, id ASC LIMIT 1000;
关键点：
-
ORDER BY必须明确、可复现：单靠created_at可能有重复值，加id保序更稳妥 -
LIMIT是硬限制，哪怕只匹配到 2 条也会删 2 条，不会报错 - 执行前务必加事务：
BEGIN; DELETE ...; SELECT ROW_COUNT(); ROLLBACK;确认影响行数 - 避免在大表上无索引删：确保
created_at有索引，否则ORDER BY会全表扫描
兼容旧版 MySQL（如 5.6）的替代方案
用子查询获取待删 id 列表，再主表关联删除：
DELETE t1 FROM logs t1 INNER JOIN ( SELECT id FROM logs ORDER BY created_at ASC, id ASC LIMIT 1000 ) t2 ON t1.id = t2.id;
注意陷阱：
- MySQL 不允许直接
DELETE FROM ... WHERE id IN (SELECT ...)对同一张表操作，会报错：You can't specify target table 'logs' for update in FROM clause - 必须用
JOIN形式绕过该限制 - 子查询里
LIMIT有效，但外层DELETE不再受LIMIT控制——所以子查询必须精准返回目标 ID 集合 - 如果
id是主键，这个写法效率尚可；若非主键，JOIN 可能变慢，考虑加索引
PostgreSQL 和 SQL Server 的等效写法
PostgreSQL 支持 USING + LIMIT 子句：
DELETE FROM logs USING ( SELECT id FROM logs ORDER BY created_at ASC, id ASC LIMIT 1000 ) t WHERE logs.id = t.id;
SQL Server 必须用 CTE：
WITH cte AS ( SELECT TOP 1000 id FROM logs ORDER BY created_at ASC, id ASC ) DELETE FROM logs WHERE id IN (SELECT id FROM cte);
差异提醒：
- PostgreSQL 的
USING比子查询更清晰，且支持窗口函数扩展（比如按分区删） - SQL Server 的
TOP必须配合ORDER BY，否则行为未定义 - 所有方案都依赖排序字段有索引，否则
ORDER BY成为性能瓶颈
真正容易被忽略的是：删完后没及时 VACUUM（PostgreSQL）或 OPTIMIZE TABLE（MySQL），导致磁盘空间不释放，后续查询反而变慢。
