MySQL并发执行时表锁导致脚本阻塞：原因分析与解决方案

php脚本通过浏览器运行时，因会话锁和mysql事务隔离机制，导致长时间查询阻塞其他请求；改用命令行执行可绕过web服务器会话限制，显著提升并发性。

在您的场景中，Script 1 对 TableA 执行全表遍历（SELECT * FROM TableA），并在循环中频繁执行 UPDATE TableA —— 这看似简单，实则隐含严重的并发隐患。根本问题并非单纯“MySQL服务器无响应”，而是由 PHP会话机制 + MySQL默认事务隔离级别 + Web服务器请求生命周期 共同引发的资源争用。

? 根本原因解析

1. PHP Session 阻塞（最常见主因）
   当 Script 1 通过浏览器访问（如 http://localhost/script1.php）启动后，PHP 默认开启 session_start()（即使您未显式调用，某些框架或配置会自动启用）。PHP 的文件型 session 在脚本执行期间会对 session 文件加写锁，直到脚本结束或显式调用 session_write_close()。此时 Script 2（同样通过浏览器访问）尝试启动会话时，会被阻塞在 session_start()，无法继续执行后续数据库查询——表现为“页面卡死”“不响应”，实则卡在 PHP 层，而非 MySQL。

2. 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 会直接锁定整张表，彻底阻塞所有并发读写。

3. 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 解耦、事务精细化、任务异步化三层优化，即可在保障数据一致性的同时，彻底解决“脚本一跑，全站卡死”的典型并发陷阱。

# ai  # 爬虫  # 浏览器  # redis  # curl  # session  # select  # php  # for  # mysql  # apache  # nginx  # php脚本  # rabbitmq 

相关栏目： <？ｍｕｍａ $count = M('archives')->where(['typeid'=>$field['id']])->count(); ?> 【 AI推广<？ｍｕｍａ echo $count; ?> 】 <？ｍｕｍａ $count = M('archives')->where(['typeid'=>$field['id']])->count(); ?> 【 SEO优化<？ｍｕｍａ echo $count; ?> 】 <？ｍｕｍａ $count = M('archives')->where(['typeid'=>$field['id']])->count(); ?> 【 技术百科<？ｍｕｍａ echo $count; ?> 】 <？ｍｕｍａ $count = M('archives')->where(['typeid'=>$field['id']])->count(); ?> 【 谷歌推广<？ｍｕｍａ echo $count; ?> 】 <？ｍｕｍａ $count = M('archives')->where(['typeid'=>$field['id']])->count(); ?> 【 百度推广<？ｍｕｍａ echo $count; ?> 】 <？ｍｕｍａ $count = M('archives')->where(['typeid'=>$field['id']])->count(); ?> 【 网络营销<？ｍｕｍａ echo $count; ?> 】 <？ｍｕｍａ $count = M('archives')->where(['typeid'=>$field['id']])->count(); ?> 【 案例网站<？ｍｕｍａ echo $count; ?> 】 <？ｍｕｍａ $count = M('archives')->where(['typeid'=>$field['id']])->count(); ?> 【 精选文章<？ｍｕｍａ echo $count; ?> 】