mysqli_query本身不支持单次查询超时，需通过mysqli_options设置read_timeout控制读响应上限，或在mysql服务端用set session max_execution_time=5000（仅对select生效）。
mysqli_query 怎么设超时
MySQLi 原生不支持单条 mysqli_query 的超时控制，底层用的是 MySQL C API，超时由连接层或服务器决定。想让某次查询在 5 秒内失败，不能靠改 mysqli_query 参数实现。
可行路径只有两个：一是设置连接级 socket 超时（影响所有后续查询），二是换用 PDO + PDO::ATTR_TIMEOUT（但注意它只控制连接建立，不控查询执行）。
- 对
mysqli，必须在创建连接时通过mysqli_options($link, MYSQLI_OPT_CONNECT_TIMEOUT, 3)设连接超时；查询中止需依赖 MySQL 服务端的max_execution_time（5.7.4+）或SET SESSION max_execution_time = 5000 - 若用
mysqli_real_connect，可传入connect_timeout、read_timeout、write_timeout三个参数，其中read_timeout最接近“查询超时”语义——它控制从服务器读取响应的阻塞上限 -
read_timeout设太小易误杀慢查询（如带 GROUP BY 的大表聚合），设太大又失去意义；生产环境建议 10–30 秒，配合应用层断路器使用
pdo_mysql 中 timeout 参数到底管什么
PDO::ATTR_TIMEOUT 只作用于连接建立阶段，和查询执行无关。很多人配了这个还遇到查询卡死，就是因为误解了它的作用范围。
真正能干预查询执行时间的，是 MySQL 服务端配置：
- 全局生效：
SET GLOBAL max_execution_time = 5000（单位毫秒），要求 MySQL ≥ 5.7.4 且引擎为 InnoDB - 会话级生效：
SET SESSION max_execution_time = 3000，可在PDO::exec("SET SESSION max_execution_time = 3000")后再执行业务 SQL - 该机制对
SELECT有效，但对INSERT ... SELECT、存储过程内部查询等场景可能不触发中断
cURL 风格的查询超时有没有替代方案
PHP 没有内置类似 cURL 的 CURLOPT_TIMEOUT_MS 那样精细控制单次 SQL 执行的机制。所谓“查询超时”，本质是客户端等待响应的 socket 超时 + 服务端主动中止执行的组合策略。
如果你需要强保障的超时（比如支付类接口必须 800ms 内返回），推荐分层处理：
- PHP 层：用
pcntl_alarm()+pcntl_signal()注册超时信号（仅 CLI 模式可用；FPM 下不可靠） - 中间层：用消息队列 + 异步任务 + TTL 控制，把长查询移出主请求链路
- 数据库层：在 SQL 前加
/*+ MAX_EXECUTION_TIME(2000) */（MySQL 5.7+ hint 语法），比 SET SESSION 更精准，且随语句生效
容易被忽略的 read_timeout 和 connect_timeout 区别
这两个参数都通过 mysqli_options() 设置，但行为完全不同，混用会导致预期外的失败。
connect_timeout 是 TCP 握手+认证阶段的上限，一般设 3–5 秒足够；而 read_timeout 是查询发出后，等待第一个字节响应的最长时间——它才是真正影响“查询卡住”的关键参数。
- 如果
read_timeout设为 0，表示无限等待，这是 mysqli 默认值，也是线上慢查询积压的常见原因 - FPM 模式下，
read_timeout还受max_execution_time（PHP 配置）制约：即使 MySQL 返回了，PHP 脚本超时也会 kill 掉整个请求 - 调试时可用
mysqli_get_client_info()和mysqli_get_server_info()确认版本兼容性，避免在旧 MySQL 上误用max_execution_time
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
