CI4 查询超时需在数据库连接组配置中显式设置 'timeout' 参数（单位秒，默认0），仅对 Query Builder 或 $this->db->query() 生效，且受驱动实现影响：mysqli 映射为 MYSQLI_OPT_READ_TIMEOUT，pdo_mysql 需配合 DSN 中 timeout=5。
CI4 中 DB 查询超时在哪设？不是靠 MySQL 全局参数
CodeIgniter 4 的查询超时（query timeout）不响应 wait_timeout 或 interactive_timeout 这类 MySQL 服务端配置，也不受 PHP 的 default_socket_timeout 影响。它由 CI4 的 DBConnection 实例在执行语句时主动控制，且仅对 Query Builder 或 $this->db->query() 生效。
关键点是：必须在连接组配置中显式设置 'timeout' 参数，单位为秒（整数），默认为 0（即不限制）。该参数会传递给底层驱动的执行逻辑（如 mysqli_stmt::execute 或 PDOStatement::execute），但实际行为依赖驱动实现：
-
mysqli驱动下，timeout会映射为MYSQLI_OPT_READ_TIMEOUT，仅作用于查询执行阶段，不影响连接建立 -
pdo_mysql驱动下，需配合 DSN 中的timeout=5（注意不是connect_timeout），否则'timeout'配置可能被忽略
示例（app/Config/Database.php）：
'default' => [
'DSN' => 'mysqli://user:pass@127.0.0.1:3306/dbname',
'hostname' => '127.0.0.1',
'username' => 'user',
'password' => 'pass',
'database' => 'dbname',
'DBDriver' => 'mysqli',
'timeout' => 15, // ← 此处生效
// ...
]
为什么加了 timeout 还不生效？常见配置陷阱
即使写了 'timeout' => 10，查询仍可能卡死或超时延迟远超预期，原因往往不在 CI 层：
- MySQL 服务端设置了极高的
max_execution_time（8.0.19+），会覆盖客户端 timeout，需确认是否启用：SELECT @@max_execution_time; - 使用了存储过程或触发器，其内部执行时间不受 CI 的
timeout约束 - 开启了
pconnect（持久连接），旧连接可能携带过期的 socket 状态，导致 timeout 不触发重连 - Query Builder 的
join()或子查询涉及多表，某些驱动（尤其 pdo_mysql）对复杂语句的 timeout 检查不严格
验证是否真正生效：在查询前加日志，用 microtime(true) 包裹 $this->db->query()，观察耗时是否被截断；若超过设定值才返回，说明 timeout 未起作用。
主从分离场景下，从库查询超时要单独配
主从架构中，从库常因复制延迟或负载高导致慢查询，但 CI4 不会自动继承主库的 timeout 值。若你通过 \Config\Database::connect('slave') 手动获取从库连接，必须确保 'slave' 组也定义了 'timeout'，且建议值略高于主库（例如主库 10 秒，从库 20 秒）。
容易忽略的是：从库连接还受 connect_timeout 控制（通过 DSN 设置），这和查询超时无关，但首次连接失败时会掩盖真正的 query timeout 问题：
- 错误写法：
'DSN' => 'mysqli://u:p@sl1:3306/db?connect_timeout=3'→ 连接失败快，但查询仍可能卡住 - 正确做法：同时设
'connect_timeout'（防连接挂起）和'timeout'（防查询阻塞）
从库配置片段示例：
'slave' => [
'DSN' => 'mysqli://u:p@sl1:3306/db?connect_timeout=5',
'hostname' => 'sl1',
'username' => 'u',
'password' => 'p',
'database' => 'db',
'DBDriver' => 'mysqli',
'timeout' => 20,
// ...
]
连接池不存在，复用连接靠手动管理
CI4 官方不提供连接池，\Config\Database::connect() 每次调用都新建连接实例（除非传入 reuse 参数且底层支持）。这意味着：
- 控制器里反复写
\Config\Database::connect('slave')→ 快速耗尽 MySQL 的max_connections - Model 构造函数中硬编码
$this->db = \Config\Database::connect('slave')→ 整个 Model 生命周期绑定单一连接，无法动态切回主库
更稳妥的做法是封装一个轻量服务类，内部缓存连接实例：
class DbService
{
private static $connections = [];
public static function slave(): BaseConnection
{
if (! isset(self::$connections['slave'])) {
self::$connections['slave'] = \Config\Database::connect('slave');
}
return self::$connections['slave'];
}
}
然后在业务逻辑中调用 DbService::slave()->table('logs')->get()。这样既避免重复建连，又保留按需切换的灵活性。
真正难处理的是长事务 + 查询超时的组合：CI4 的 timeout 在事务内不会中断正在执行的语句，只影响后续新查询。如果一个事务里包含多个慢操作，得靠 MySQL 的 max_execution_time 或应用层拆分事务来兜底。
