p应使用 WHERE created_at DATE_SUB(NOW(), INTERVAL 1 DAY) 而非 WHERE NOW() - created_at 86400以确保索引有效利用。/pWHERE 条件里用 created_at 而不是 now() 直接减时间直接写 WHERE created_at 看似简洁但多数 MySQL 版本尤其 5.7 及更早会为每行都重新计算 codeNOW()导致无法使用 created_at 字段上的索引。实际执行变成全表扫描几千万行日志可能卡住十几分钟。实操建议先算好边界时间戳用应用层或 MySQL 客户端执行一次 SELECT DATE_SUB(NOW(), INTERVAL 30 DAY)拿到确定值如 2024-04-01 00:00:00DELETE 语句中硬编码该值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助手依托大模型帮助用户记录、整理和分析音视频内容体验用大模型做音视频笔记、整理会议记录。