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 会升级为表级锁或长事务阻塞读写。尤其在高并发写日志场景下，<code>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）
不依赖分区也能接近无锁：把要删的数据先挪到临时表，再原子性地重命名替换。步骤如下：
Linux Security Scanner
下载
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
立即学习“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 都会全表扫，反而更卡。别只盯着“无锁”，忘了基础索引。
