Hyperf 中 MySQL 查询不自动重试，因框架未封装 SQL 层重试逻辑；需手动用 hyperf/retry 组件、封装退避查询或优化连接池健康检查。
Hyperf 里 MySQL 请求异常不会自动重试——框架本身不提供 SQL 层面的重试能力，必须手动封装或借助第三方组件。直接依赖 PDO 或 Db::select() 发起查询，失败就真失败了。
为什么 MySQL 查询不自动重试
Hyperf 的数据库组件（hyperf/database）本质是协程化 PDO 封装，它不拦截或重试底层 PDOException；async-queue 的 $maxAttempts 只作用于 Job 执行生命周期，和单次 DB 查询无关。
- 连接超时、
MySQL server has gone away、死锁、网络中断等错误都抛出PDOException，但框架默认不做捕获重试 - ORM 模型方法如
User::find()或Db::transaction()内部也不含重试逻辑 - 若业务强依赖“查不到就再试一次”，必须在调用侧显式控制
用 hyperf/retry 组件包装查询调用
这是最轻量、侵入最小的方式：把 DB 操作包进一个可重试的闭包或方法，交由 Retry 组件统一调度。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 安装组件：
composer require hyperf/retry - 在 Service 或 Command 中使用闭包方式重试：
use Hyperf\Retry\Retry;
use Hyperf\Database\Exception\QueryException;
<p>$result = Retry::call(function () {
return Db::table('orders')->where('status', 'pending')->first();
}, [
'attempts' => 3,
'delay' => 500, // 毫秒
'retry_if' => function ($e) {
return $e instanceof QueryException || $e instanceof PDOException;
}
]);
-
retry_if是关键：只对数据库类异常重试，避免把逻辑错误（如空参数）也反复执行 - 注意
delay单位是毫秒，不是秒；过短可能加剧雪崩，建议从 500ms 起步 - 不要在事务块内直接套 Retry——重试会重复开启/提交事务，导致数据错乱
在模型或 Repository 中封装带退避的查询方法
适合高频、核心路径的查询（如用户余额、库存扣减），需控制重试节奏且避免阻塞协程。
- 禁用
sleep()，改用Coroutine::sleep() - 实现简单指数退避（例如第1次等 0.5s，第2次等 1s，第3次等 2s）
- 示例写法：
use Hyperf\Coroutine\Coroutine;
use Hyperf\Database\Exception\QueryException;
<p>public function findWithRetry($id, $maxAttempts = 3)
{
for ($i = 1; $i <= $maxAttempts; $i++) {
try {
return User::findOrFail($id);
} catch (QueryException | PDOException $e) {
if ($i === $maxAttempts) throw $e;
$delay = min(4, pow(2, $i - 1)); // 最大退避 4 秒
Coroutine::sleep($delay);
}
}
}
-
Coroutine::sleep()前提是config/autoload/coroutine.php中must_use_scheduler为true，否则退化为同步阻塞 - 退避上限建议设为 4~10 秒，防止下游服务持续承压
- 幂等性必须由业务保证：比如
find安全，但increment类操作不能盲目重试
连接池配置 + 健康检查比重试更治本
很多所谓“查询失败”，其实是连接池返回了已失效的连接。与其反复重试，不如让连接池自己剔除坏连接。
- 在
config/autoload/databases.php中启用验证查询：
'pool' => [
'min_connections' => 2,
'max_connections' => 20,
'connect_timeout' => 5.0,
'wait_timeout' => 5.0,
'heartbeat' => 30, // 每30秒发一次 select 1 心跳
'max_idle_time' => 30.0,
],
'options' => [
\PDO::ATTR_TIMEOUT => 3, // PDO 层超时 3 秒
],
'commands' => [
'create' => ['CREATE DATABASE IF NOT EXISTS %s CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci'],
],
'validation_query' => 'SELECT 1', // 关键：每次取连接前执行
-
validation_query是连接复用前的“体检”，比应用层重试更前置、更高效 -
heartbeat配合max_idle_time可主动清理空闲过久的连接，避免被 MySQL 的wait_timeout杀掉 - 如果仍频繁出现
Lost connection，优先检查 MySQL 侧wait_timeout是否小于max_idle_time
真正难处理的不是“要不要重试”，而是“重试什么”和“重试几次”。DB 查询重试必须绑定明确的错误类型、有上限的退避策略，并永远让连接池健康检查走在重试前面——否则你只是在给坏连接反复续命。
