PHP SQL超时需分层处理：脚本层（max_execution_time）管整体执行，驱动层（mysqli/PDO超时参数）管连接与查询，MySQL服务端（max_execution_time）仅限SELECT，还需排查锁等待与事务问题。
PHP执行SQL超时，核心不是“加时间”，而是分清超时发生在哪一层：是PHP脚本自己卡住了，还是数据库连接没建上，或是SQL真在服务器里跑太久被砍了。不同位置得用不同手段拦——改错地方，调再大 timeout 也没用。
PHP脚本层超时（max_execution_time）
这是最常被误认的“SQL超时”。其实它跟数据库无关，只是PHP解析器强制终止整个脚本。比如导出10万行数据时，在PHP里拼CSV、写文件、循环处理耗时过长，max_execution_time 就会炸。
- 默认30秒，可通过
ini_set('max_execution_time', 300)临时延长，但仅对当前请求生效 - 不推荐在web请求中设为0（无限），容易拖垮FPM worker；后台任务或CLI场景可用
set_time_limit(0) - 真正该做的是：查清耗时在哪——用
microtime(true)包裹SQL执行前后、数据处理前后，定位瓶颈是查得慢，还是PHP里处理慢
PDO/MySQLi连接与查询超时（驱动层）
这一层才真正管“发SQL → 等结果”全过程，覆盖建连、发包、收响应。比数据库参数更贴近真实体验，且能捕获网络卡顿等DB层看不到的问题。
- MySQLi：创建连接时传
mysqli_options($conn, MYSQLI_OPT_CONNECT_TIMEOUT, 5)；执行前设mysqli_options($conn, MYSQLI_OPT_READ_TIMEOUT, 10)和MYSQLI_OPT_WRITE_TIMEOUT - PDO（MySQL）：
PDO::ATTR_TIMEOUT只控制连接建立，不控制查询；得靠PDOStatement::setAttribute(PDO::ATTR_TIMEOUT, 10)（PHP 8.2+）或在DSN里加&connect_timeout=5&read_timeout=10 - 注意：PDO MySQL驱动对
read_timeout支持不稳定，生产环境建议统一用mysqli或升级到较新PHP版本
MySQL服务端SELECT超时（max_execution_time）
这个只对 SELECT 语句生效，单位毫秒，由MySQL主动中断正在执行的查询线程，错误码是 1969，报错信息为 Query execution was interrupted, maximum statement execution time exceeded。
立即学习“PHP免费学习笔记（深入）”；
- 必须显式设置：连接后立刻执行
SET SESSION max_execution_time = 60000；不能指望连接字符串里加参数，MySQL协议不认 - ORM如Laravel/Eloquent默认不帮你设，需在DB::statement()里手动塞，或通过事件监听器统一注入
- 设太高有风险：一个没走索引的
SELECT * FROM huge_table WHERE unindexed_col = ?卡住60秒，会占满一个连接线程，拖慢整个池
别漏掉锁等待和事务边界问题
很多“超时”根本不是执行慢，而是卡在等锁。比如PHP里开事务删数据，WHERE没走索引，全表扫描加锁，另一个事务正好要读同一张表——这时你看到的可能是 Lock wait timeout exceeded，而不是执行超时。
- 检查
SHOW PROCESSLIST中状态是否为Locked或Waiting for table metadata lock - 用
SELECT * FROM information_schema.INNODB_TRX查长事务，确认有没有忘记commit的残留 - DELETE/UPDATE 前务必
EXPLAIN，确保type是ref或range，不是ALL；避免隐式转换（如WHERE id = '123'对INT字段）
最容易被忽略的点：PDO连接复用时，max_execution_time 会继承上一次会话的值。一个报表查询设了120秒，下个普通列表请求复用同一个连接，就也扛着120秒阈值——既没必要，又掩盖了它本该3秒返回的问题。安全做法是每次执行关键SQL前，显式重置： $pdo->exec("SET SESSION max_execution_time = 3000")。
