浏览器中同时运行多个 php 脚本时，因会话阻塞和隐式事务行为，可能导致 mysql 表级锁或连接排队，使其他请求长时间等待甚至超时；通过命令行执行耗时脚本可绕过 web 服务器会话限制，显著提升并发可用性。
该问题本质并非 MySQL 自身“锁表”（如 MyISAM 的表锁），而是由 PHP 的 Web 运行环境与数据库交互方式共同引发的并发瓶颈。虽然你使用的代码未显式开启事务，但以下关键因素在浏览器环境下叠加放大了阻塞效应：
? 根本原因分析
PHP 会话阻塞（Session Locking）
若两个脚本均调用 session_start()（即使未显式写出，某些框架或配置会自动启用），PHP 默认会对同一会话 ID 的后续请求进行串行化处理——即第二个请求必须等待第一个脚本释放会话文件锁。这是最常见却被忽视的原因，且与 MySQL 无关，却表现为“查询卡住”。长连接 + 隐式事务行为（尤其 InnoDB）
尽管你的 SELECT 和 UPDATE 语句未包裹在 BEGIN/COMMIT 中，InnoDB 在自动提交（autocommit=1）模式下仍为每条 DML 语句创建独立事务。但若脚本执行缓慢（如频繁网络爬虫），大量短事务叠加可能加剧锁竞争；更严重的是：若 UPDATE TableA 涉及非主键/非索引字段，可能触发间隙锁（Gap Lock）或临键锁（Next-Key Lock），导致其他 SELECT ... WHERE ... 查询被阻塞。Web 服务器资源限制
Apache（MPM prefork）或 PHP-FPM 默认配置通常限制并发进程/线程数（如 max_children=5）。当脚本 1 占用一个 worker 长达数分钟，其余请求将排队等待，表现为“页面无响应”，实则是 HTTP 层超时而非数据库层死锁。
✅ 推荐解决方案（按优先级排序）
✅ 方案一：禁用会话或提前关闭（立即生效）
// Script 1 开头添加（若无需 session 数据）
if (session_status() === PHP_SESSION_ACTIVE) {
session_write_close(); // 释放会话锁，允许其他请求并发进入
}
// 后续代码正常执行...✅ 方案二：改用 CLI 模式执行（推荐长期方案）
# 终止浏览器触发，改用终端运行 php /var/www/html/crawl_script.php
CLI 模式无会话机制、无 Web 服务器 worker 限制、超时时间更宽松，是处理批量任务的标准实践。
✅ 方案三：优化数据库操作（治本之策）
- 为 TableA 中 UPDATE 和 Script 2 的 WHERE 条件字段添加复合索引，避免全表扫描与锁升级；
- 将循环内多次 UPDATE 改为批量更新（例如每 100 条合并为一条 INSERT ... ON DUPLICATE KEY UPDATE 或 UPDATE ... WHERE id IN (...)）；
- 显式控制事务粒度：
$conn->beginTransaction(); try { // 批量处理逻辑 $conn->commit(); } catch (Exception $e) { $conn->rollback(); throw $e; }
⚠️ 注意事项
- 不要依赖 set_time_limit(0) 或 ignore_user_abort(true) 来“修复”阻塞——它们掩盖问题而非解决；
- SELECT ... FOR UPDATE 或 LOCK IN SHARE MODE 等显式锁语句需谨慎使用，此处未出现，故排除；
- 使用 SHOW PROCESSLIST; 和 SELECT * FROM information_schema.INNODB_TRX; 可实时诊断活跃事务与锁等待。
综上，优先检查并解除会话锁，再将长时任务迁移至 CLI 环境，并辅以数据库索引与批量操作优化——三者结合，即可彻底消除“脚本一运行，其他页面全部卡死”的现象。
