php清理logs怎样避免锁表_php无锁清logs技巧【无锁】

php清理日志锁表本质是因日志存mysql导致，根本解法是改用文件日志+logrotate：PHP写文件（error_log或file_put_contents加LOCK_EX），由logrotate按天切割压缩、保留30天，彻底规避数据库锁与全表扫描风险。

PHP 清理日志时为什么会锁表

本质问题不在 PHP，而在你用的存储方式。如果日志写进 MySQL 的 logs 表，并用 delete FROM logs WHERE created_at 批量删，InnoDB 默认走行锁+间隙锁，大范围 DELETE 会升级为表级锁或长事务阻塞读写。尤其在高并发写日志场景下，select 查询可能被卡住，表现就是“锁表”。

用 TRUNCATE + 分区表绕过锁（MySQL 8.0+）

真正无锁清理的关键是避免逐行判断和事务回滚段膨胀。TRUNCATE 是 DDL 操作，不走事务、不记录 undo log，也不触发触发器，天然不锁表（但会短暂加 MDL 锁，毫秒级）。前提是：日志表按时间分区，比如按月分区：

ALTER table logs PARTITION BY RANGE (TO_DAYS(created_at)) (     PARTITION p202312 VALUES LESS THAN (TO_DAYS('2024-01-01')),     PARTITION p202401 VALUES LESS THAN (TO_DAYS('2024-02-01')),     PARTITION p202402 VALUES LESS THAN (TO_DAYS('2024-03-01')),     PARTITION p_future VALUES LESS THAN MAXVALUE );

清理旧日志就变成：

ALTER TABLE logs DROP PARTITION p202312;

• 这个操作是元数据变更，几乎瞬时完成，不扫描数据，不锁表
• 必须确保 created_at 是分区键且类型为 date/DATETIME
• 注意：DROP PARTITION 后磁盘空间不会立即释放，需后续执行 OPTIMIZE TABLE logs（该操作会锁表，建议低峰期跑）

用归档表 + RENAME 替代 DELETE（兼容老版本 MySQL）

不依赖分区也能接近无锁：把要删的数据先挪到临时表，再原子性地重命名替换。步骤如下：

立即学习“PHP免费学习笔记（深入）”；

CREATE TABLE logs_archive LIKE logs; INSERT INTO logs_archive SELECT * FROM logs WHERE created_at < '2024-01-01'; CREATE TABLE logs_new LIKE logs; INSERT INTO logs_new SELECT * FROM logs WHERE created_at >= '2024-01-01'; RENAME TABLE logs TO logs_old, logs_new TO logs;

• RENAME TABLE 是原子操作，客户端几乎感知不到切换
• 原 logs 表被重命名为 logs_old，可异步 DROP
• 全程没有长时间持有 logs 表的写锁；但 INSERT ... SELECT 阶段会对源表加一致性读锁（不影响写入），影响取决于数据量
• 务必在事务外执行，否则 RENAME 会失败

彻底避开数据库：改用文件日志 + logrotate

最轻量、最无锁的方案，是别让 PHP 写数据库日志。直接写文件，交给系统工具清理：

• PHP 中用 error_log() 或 file_put_contents($log_file, $msg, FILE_appEND | LOCK_EX) 写日志（注意：LOCK_EX 是文件锁，不是表锁，不影响 DB）
• 配置 linux logrotate，按天切割、压缩、保留 30 天，完全不经过 PHP
• 若必须查日志，用 grep/zcat 或 elk 收集，不走 MySQL 查询路径

这招的代价是放弃 SQL 查询灵活性，但换来的是零锁、零慢查询、零运维干预——多数业务日志真不需要实时 JOIN 或聚合分析。

真正容易被忽略的点：分区表和 RENAME 方案都依赖精确的时间字段索引，如果 created_at 没建索引，前面所有 INSERT/SELECT 都会全表扫，反而更卡。别只盯着“无锁”，忘了基础索引。