
php脚本通过浏览器运行时,因会话锁和mysql事务隔离机制,导致长时间查询阻塞其他请求;改用命令行执行可绕过web服务器会话限制,显著提升并发性。
在您的场景中,Script 1 对 TableA 执行全表遍历(SELECT * FROM TableA),并在循环中频繁执行 UPDATE TableA —— 这看似简单,实则隐含严重的并发隐患。根本问题并非单纯“MySQL服务器无响应”,而是由 PHP会话机制 + MySQL默认事务隔离级别 + Web服务器请求生命周期 共同引发的资源争用。
? 根本原因解析
PHP Session 阻塞(最常见主因)
当 Script 1 通过浏览器访问(如 http://localhost/script1.php)启动后,PHP 默认开启 session_start()(即使您未显式调用,某些框架或配置会自动启用)。PHP 的文件型 session 在脚本执行期间会对 session 文件加写锁,直到脚本结束或显式调用 session_write_close()。此时 Script 2(同样通过浏览器访问)尝试启动会话时,会被阻塞在 session_start(),无法继续执行后续数据库查询——表现为“页面卡死”“不响应”,实则卡在 PHP 层,而非 MySQL。-
MySQL 行锁/表锁升级风险
虽然 InnoDB 默认使用行级锁,但以下情况易触发锁升级或长事务:- Script 1 的 SELECT * FROM TableA 若未加 FOR UPDATE 或 LOCK IN SHARE MODE,本身不加锁;但紧随其后的 UPDATE TableA ... 会对匹配行加排他锁(X lock)。
- 若更新涉及大量行、或存在未提交事务、或 autocommit=0 且未手动 COMMIT,这些锁将持续到脚本结束,阻塞 Script 2 的 SELECT ... WHERE ...(尤其当 Script 2 查询的行正被 Script 1 更新时)。
- 更严重的是:若 TableA 使用 MyISAM 引擎(已不推荐),UPDATE 会直接锁定整张表,彻底阻塞所有并发读写。
Web 服务器请求超时与连接池限制
Apache/Nginx 对每个请求有超时设置(如 max_execution_time、Timeout),而长耗时爬虫脚本极易触发超时,导致连接异常中断或堆积,进一步加剧响应延迟。
✅ 正确解决方案(不止“改用 CLI”)
虽然将 Script 1 改为命令行执行(php /path/to/script1.php)能快速见效——因为 CLI 模式默认不启用 session,且不受 Web 服务器超时与并发连接数限制——但这只是治标。专业实践中应组合优化:
✅ 方案一:释放 PHP Session 锁(推荐优先尝试)
// Script 1 开头立即关闭 session 写入(若无需会话数据)
if (session_status() === PHP_SESSION_ACTIVE) {
session_write_close(); // 释放 session 文件锁
}
// 后续数据库操作不再受 session 阻塞✅ 方案二:优化数据库操作,避免长事务
// 关键:分批处理 + 显式事务控制 + 及时提交
$batchSize = 100;
$stmt = $conn->prepare("SELECT id FROM TableA WHERE processed = 0 LIMIT ?");
$stmt->execute([$batchSize]);
$ids = $stmt->fetchAll(PDO::FETCH_COLUMN);
foreach ($ids as $id) {
// 爬虫逻辑...
if ($condition) {
$conn->beginTransaction();
try {
$conn->prepare("INSERT INTO TableB (...) VALUES (...)")->execute([...]);
$conn->prepare("UPDATE TableA SET processed = 1 WHERE id = ?")->execute([$id]);
$conn->commit();
} catch (Exception $e) {
$conn->rollback();
throw $e;
}
}
}
// 小批量提交显著降低锁持有时间✅ 方案三:使用非阻塞队列解耦(生产环境首选)
- 将 TableA 中待处理记录 ID 推入 Redis 队列或消息队列(如 RabbitMQ);
- 启动独立的守护进程(CLI 脚本)持续消费队列,执行爬虫与写库;
- Web 请求(Script 2)完全无感知,毫秒级响应。
⚠️ 注意事项
- 切勿在 Web 请求中执行耗时任务:爬虫、大文件处理、全表扫描等必须剥离至后台;
- 始终检查存储引擎:SHOW TABLE STATUS LIKE 'TableA'; 确认 Engine = InnoDB;
- 监控锁等待:SHOW ENGINE INNODB STATUS\G 查看 TRANSACTIONS 和 LOCK WAIT 部分;
- CLI 执行需注意权限与路径:确保 CLI 版 PHP 加载了所需扩展(cURL、PDO MySQL),并使用绝对路径连接数据库。
通过 session 解耦、事务精细化、任务异步化三层优化,即可在保障数据一致性的同时,彻底解决“脚本一跑,全站卡死”的典型并发陷阱。










