diff --git a/docs/test/IM-单聊压测Pod日志根因分析与改进方案-20260927.md b/docs/test/IM-单聊压测Pod日志根因分析与改进方案-20260927.md
index b933c9c..27dff88 100644
--- a/docs/test/IM-单聊压测Pod日志根因分析与改进方案-20260927.md
+++ b/docs/test/IM-单聊压测Pod日志根因分析与改进方案-20260927.md
@@ -54,7 +54,29 @@
 | 本轮已生成 Kafka 死信（核验时点） | 27 |
 | 死信错误 | `Error 1264: Out of range value for column 'id'` |
 
-结论：本轮 ACK 消息的 **当前 MySQL 落库率为 0%**。27 是核验时已完成重试并转入死信的数量，不是最终总数；消费者正在逐条重试失败消息，其余消息仍可能位于 Kafka backlog 或处理中。
+结论：修复前，本轮 ACK 消息的 **MySQL 落库率为 0%**。27 是首次核验时已完成重试并转入死信的数量，不是最终总数；当时其余消息仍位于 Kafka backlog 或处理中。
+
+### 2.2 修复执行与数据恢复结果
+
+2026-09-27 已在本地和测试环境执行 `docs/sql/IM-消息表Snowflake-ID-BIGINT修复SQL.sql` 对应迁移：
+
+- 本地 `meeting_im.im_messages.id` 已由 `INT` 改为 `BIGINT NOT NULL AUTO_INCREMENT`。
+- 测试环境 `meeting_im.im_messages` 以及 `im_001_messages` 至 `im_009_messages` 共 10 张表已全部改为 `BIGINT NOT NULL AUTO_INCREMENT`，后置校验异常数为 0。
+- 修复后 Kafka backlog 自动恢复落库 11835 条；本轮已有 32 条消息进入死信，通过系统 `kafka.dead_letter.replay` 命令完成重放。
+
+使用原始 ACK ledger 对恢复后的数据库逐条校验：
+
+| 核验项 | 最终结果 |
+|---|---:|
+| ACK ledger | 11867 |
+| 数据库本轮消息行 | 11867 |
+| `client_mid + topic + seq` 精确匹配 | 11867 |
+| 缺失 | 0 |
+| 错配 | 0 |
+| 重复 | 0 |
+| 拒绝/超时请求意外落库 | 0/8133 |
+
+因此本轮已确认 ACK 消息最终 100% 落库。这里的最终结果是执行字段迁移、等待 Kafka backlog 排空并重放死信后的恢复结果，不代表故障发生时的异步持久化链路正常。
 
 ## 3. Kubernetes 现状