hyperf中mysql数据“丢失”主因是事务未提交：autocommit=0后未commit/rollback，连接断开导致变更蒸发；需查innodb_trx中trx_state='active'/'running'且trx_started超120秒、trx_query为null的悬挂事务，并联查processlist定位hyperf实例。
Hyperf 项目里 MySQL 数据“丢了”，八成不是删库跑路，而是事务开了没关——autocommit=0 后忘了 commit 或 rollback，连接一断，未提交的变更就蒸发了。这不是 MySQL 的 bug，是应用层对事务生命周期管理失控的典型表现。
查 information_schema.INNODB_TRX 看谁在挂事务
别信 SHOW PROCESSLIST 里那些 Sleep 线程，它们可能正安静地攥着锁、拖着日志、卡着 DDL。真正能暴露“未提交”状态的，只有 INNODB_TRX：
-
trx_state = 'ACTIVE'或'RUNNING'才算真活着；'COMMITTED'或'ROLLING BACK'的不用管 -
trx_started时间戳比当前早 120 秒以上（生产环境阈值），基本可判为异常挂起 -
trx_query IS NULL是最危险信号：SQL 执行完了，但事务没交，锁还在，undo 日志还在涨 -
trx_mysql_thread_id是后续KILL的唯一合法 ID，不是trx_id
执行这条语句快速抓人：
SELECT trx_id, trx_mysql_thread_id, trx_started, trx_state, trx_query
FROM information_schema.INNODB_TRX
WHERE trx_state IN ('ACTIVE', 'RUNNING')
AND trx_started
<h3>关联 <code>PROCESSLIST</code> 定位 Hyperf 应用实例</h3>
<p>光知道线程 ID 不够，得知道这连接来自哪个服务、哪个 Pod、哪个协程上下文。用 <code>trx_mysql_thread_id</code> 去联查 <code>information_schema.PROCESSLIST</code>：</p><div class="aritcle_card flexRow artxards">
<div class="artcardd flexRow">
<a class="aritcle_card_img" rel="nofollow" href="/xiazai/skill4029" title="Hyperframes Creative"><img
src="https://img.php.cn/upload/skill/000/000/081/178988960574411.jpg" alt="Hyperframes Creative" onerror="this.onerror='';this.src='/static/lhimages/moren/morentu.png'" ></a>
<div class="aritcle_card_info flexColumn">
<a rel="nofollow" href="/xiazai/skill4029" title="Hyperframes Creative" class="overflowclass">Hyperframes Creative</a>
<p class="overflowclass">HyperFrames视频非动画创意指导，包括设计规范（frame.md/design.md）处理、配色、字体设计、旁白及节奏规划等。</p>
</div>
<a rel="nofollow" href="/xiazai/skill4029" title="Hyperframes Creative" class="aritcle_card_btn flexRow flexcenter"><b></b><span>下载</span>
</a>
</div>
</div>
-
USER和HOST能直接看出是不是 Hyperf 的连接池（比如hyperf@10.244.1.12） -
DB字段确认是否操作核心库，避免误杀监控或运维连接 -
COMMAND = 'Sleep'+TIME > 300是典型“静默挂起”，和INNODB_TRX里trx_query IS NULL相互印证 - 别信
TIME是事务时长——它只是线程空闲秒数；真正看trx_started
示例联查：
SELECT p.ID, p.USER, p.HOST, p.DB, p.COMMAND, p.TIME, p.INFO
FROM information_schema.PROCESSLIST p
INNER JOIN information_schema.INNODB_TRX t ON p.ID = t.trx_mysql_thread_id
WHERE t.trx_state IN ('ACTIVE', 'RUNNING')
AND t.trx_started
<h3>检查 Hyperf 事务注解与协程生命周期是否错配</h3>
<p>Hyperf 的 <code>@Transaction</code> 或 <code>Db::transaction()</code> 在协程环境下极易失效：</p>
- 在
go协程里调用事务方法，但主协程提前结束 → 子协程里的事务上下文丢失，commit根本不被执行 - 使用
try/catch捕获异常后没显式rollback()，又没重新抛出 → 事务卡在ACTIVE状态，日志里完全无声 -
autocommit=0被全局设置（如配置文件或连接初始化脚本），但业务代码默认依赖自动提交，结果所有写操作都成了“半开事务” - ORM 查询（如
Model::find()）本身不开启事务，但开发者误以为“读了就安全”，实际后续写操作因连接复用继承了前一个未关闭的事务上下文
验证 binlog 是否记录了未提交事务的写入
MySQL 的 binlog 只记录已提交事务（binlog_format=ROW 下），所以你永远看不到“未提交”的那条 INSERT 出现在 binlog 里。但要注意：
- 如果
innodb_flush_log_at_trx_commit = 0或2，即使事务提交了，也可能因崩溃丢失最近几秒数据——这不是事务未提交问题，而是持久化策略风险 - Hyperf 使用连接池时，同一个连接可能被多个请求复用；前一个请求开了事务没关，后一个请求的 SQL 就会意外被卷入该事务，最终一起回滚或一起提交
- 想确认某条数据是否曾写入过，不要翻 binlog，直接查
INNODB_TRX+INNODB_LOCK_WAITS组合，看是否有其他事务在等它释放行锁
真正容易被忽略的点：Hyperf 默认启用协程 MySQL 连接池，而连接池里的连接不会在每次请求后自动 rollback ——除非你显式配置了 reset_on_release: true 或在 afterClose 回调里手动清理。这个细节不处理，长事务隐患就会随连接复用持续传染。
