SQL批量删除旧日志数据_根据创建时间戳进行清理方案

<p>应使用 WHERE created_at >= DATE_SUB(NOW(), INTERVAL 1 DAY) 而非 WHERE NOW() - created_at < 86400，以确保索引有效利用。</p>WHERE 条件里用 created_at 而不是 now() 直接减时间直接写 WHERE created_at 看似简洁，但多数 MySQL 版本（尤其 5.7 及更早）会为每行都重新计算 <code>NOW()，导致无法使用 created_at 字段上的索引。实际执行变成全表扫描，几千万行日志可能卡住十几分钟。实操建议：先算好边界时间戳：用应用层或 MySQL 客户端执行一次 SELECT DATE_SUB(NOW(), INTERVAL 30 DAY)，拿到确定值如 '2024-04-01 00:00:00'DELETE 语句中硬编码该值：WHERE created_at ，确保走索引如果必须动态，改用 WHERE created_at ，MySQL 8.0+ 能优化为单次计算分批删除避免锁表和事务日志爆炸一次性删百万行，InnoDB 会把所有被删记录的 undo log 都保留在事务里，可能撑爆 ib_logfile，同时长时间持有表级/行级锁，阻塞业务写入。实操建议：用 LIMIT 控制单次数量，例如每次删 10000 行：DELETE FROM logs WHERE created_at 检查影响行数，SELECT ROW_COUNT()，为 0 时停止循环两次删除之间加 SLEEP(0.1)（在存储过程里）或应用层延时，缓解 I/O 压力不要用 ORDER BY 配合 LIMIT——没索引时排序开销巨大；有索引也未必提升效率确认 created_at 列上有有效索引没有索引的 WHERE created_at 就是全表扫，无论数据量多小，批量删都会变慢。常见误区是以为“字段名含 time 就自动有索引”，或者建了联合索引但顺序不对（比如 <code>(status, created_at) 对纯时间查询无效）。 通义听悟 阿里云通义听悟是聚焦音视频内容的工作学习AI助手，依托大模型，帮助用户记录、整理和分析音视频内容，体验用大模型做音视频笔记、整理会议记录。