用 ROW_NUMBER() 窗口函数标记并删除旧记录直接DELETE时无法“保留最新一条”必须借助排序和行号来识别哪些该删。核心思路是按时间字段如created_at或id降序排给每行打上序号只保留ROW_NUMBER() 1的那条其余全删。常见错误是写成DELETE FROM table WHERE id NOT IN (SELECT MAX(id) FROM table)—— 这在有重复时间、或id不连续/非主键时会漏删或多删更糟的是若表为空或只有 1 行MAX(id)返回NULL导致整张表被误删。务必确保排序依据字段能唯一确定“最新”——优先用带时区的created_at其次才是id前提是自增且不跳号PostgreSQL / SQL Server / Oracle / MySQL 8.0 都支持ROW_NUMBER()但语法细节不同MySQL 要求子查询套一层SQL Server 可直接在DELETE中用 CTE执行前先用SELECT验证要删的行SELECT *, ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at DESC) AS rn FROM logs;确认rn 1的确实是预期旧数据MySQL 8.0 实际可执行的删除语句MySQL 不允许在子查询中直接引用被删表所以必须用 CTE 或派生表绕过限制。以下写法经实测可用假设按user_id分组保留每组最新一条WITH ranked AS (SELECT id, ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at DESC) AS rnFROM logs)DELETEl FROM logs lINNER JOIN ranked r ON l.id r.idWHERE r.rn 1;注意PARTITION BY是可选的——如果目标是全表只留最新一条不分组就把PARTITION BY user_id去掉改成ORDER BY created_at DESC即可。别漏写INNER JOIN否则 MySQL 会报错You cant specify target table for update in FROM clause若用id排序确保它代表插入顺序用created_at更安全但要注意 NULL 值——加WHERE created_at IS NOT NULL过滤大表慎用该操作会锁表或产生大量 binlog建议在低峰期执行并提前备份SQLite 中没有 ROW_NUMBER() 怎么办SQLite 3.25.0 支持窗口函数但旧版本比如 macOS 自带的 3.19不支持。这时得用自关联 子查询模拟DELETEFROM logsWHERE id NOT IN (SELECT MIN(id) FROM logs l2WHERE l2.user_id logs.user_idGROUP BY user_id);这个写法靠GROUP BY MIN(id)找出每组“最小 id”即最早插入的然后删掉所有不在这个集合里的行——但它保留的是“最早一条”不是“最新一条”。要保留最新得把MIN(id)换成MAX(id)前提是id严格递增且能代表时间顺序。如果时间字段是created_at且 SQLite 版本够新优先用ROW_NUMBER() OVER (ORDER BY created_at DESC)如果版本太老又必须按时间删只能先导出最新行到临时表清空原表再导入——没有优雅的单语句解注意NOT IN遇到子查询返回NULL时整个条件为UNKNOWN导致零行被删加AND id IS NOT NULL防御WHERE 条件里的时间字段有 NULL 值怎么办ORDER BY created_at DESC会让 NULL 排在最前面MySQL 默认行为结果可能是删掉了非 NULL 的新记录留下 NULL 的“脏数据”。这不是 bug是 SQL 标准定义。显式控制 NULL 位置ORDER BY created_at DESC NULLS LASTPostgreSQL / Oracle 支持MySQL 和 SQLite 用ORDER BY created_at DESC, id DESC辅助排序更稳妥的做法是过滤掉 NULLWHERE created_at IS NOT NULL加在子查询或 CTE 中避免干扰排序逻辑如果业务允许建表时就给时间字段加NOT NULL DEFAULT CURRENT_TIMESTAMP从源头杜绝这个问题实际执行时分组维度、时间字段是否可靠、数据库版本、NULL 处理这四点卡住大多数人。没跑通之前先用SELECT把rn 1的行查出来看一眼比反复试删安全得多。