1. 持久化统计信息概述

在 MySQL 中，持久化统计信息通过将数据存储在磁盘上（mysql.innodb_table_stats 和 mysql.innodb_index_stats 表），确保数据库重启后优化器仍能获得一致的数据样本。这对于维持执行计划的稳定性至关重要。

当全局变量 innodb_stats_persistent 开启，或者表定义中包含 stats_persistent=1 时，统计信息便会进入持久化模式。系统通过 innodb_stats_auto_recalc（默认开启）来决定是否在表数据变动超过 10% 时自动重新计算统计信息。

由于统计信息的收集是由后台线程异步处理的，大批量 DML 操作后，统计数据的更新可能会有数秒的滞后。如果需要立即生效，通常手动执行 ANALYZE TABLE。然而，一个值得关注的问题是：事务的提交（Commit）或回滚（Rollback）是否会干扰这一自动触发机制？

2. 事务行为对统计信息收集的实测

以下测试在标准 InnoDB 环境下进行，确认相关变量处于开启状态：

mysql> SHOW VARIABLES LIKE 'innodb_stats_auto_recalc';
+--------------------------+-------+
| Variable_name            | Value |
+--------------------------+-------+
| innodb_stats_auto_recalc | ON    |
+--------------------------+-------+

2.1 插入操作与回滚的影响

我们创建一个名为 data_sync_test 的表，并尝试在事务中插入大量数据但不提交。

-- 清空表并开启事务
TRUNCATE TABLE data_sync_test;
BEGIN;

-- 模拟插入 50,000 行数据
INSERT INTO data_sync_test (col_val) 
SELECT 'sample_data' FROM dual 
WHERE 1=1 LIMIT 50000;

-- 此时事务尚未提交，观察统计信息表
SELECT table_name, n_rows, last_update 
FROM mysql.innodb_table_stats 
WHERE table_name = 'data_sync_test';

实验发现，即使事务处于 Uncommitted 状态，后台线程仍会检测到行数的变化并更新 innodb_table_stats。这意味着统计信息反映的是"脏数据"或中间状态。

接着执行回滚：

ROLLBACK;

-- 检查表行数
SELECT COUNT(*) FROM data_sync_test; -- 结果为 0

-- 再次检查统计信息
SELECT table_name, n_rows FROM mysql.innodb_table_stats WHERE table_name = 'data_sync_test';

现象： 回滚后，表内数据已清空，但持久化统计信息表中的 n_rows 依然维持在 50,000 左右。统计信息与实际数据发生了严重偏离。

2.2 删除操作与异步更新

当对已有大量数据的表执行 DELETE 操作时，情况类似：

BEGIN;
DELETE FROM data_sync_test;

-- 等待约 10 秒，查看统计信息
SELECT table_name, n_rows FROM mysql.innodb_table_stats WHERE table_name = 'data_sync_test';
-- 结果显示 n_rows 接近 0

即便不执行 COMMIT，统计信息也会因为 DELETE 操作触发的变更阈值而自动更新。如果随后执行 ROLLBACK，表内数据恢复，但优化器看到的统计信息仍会认为表是空的，从而可能导致查询计划选择错误（例如放弃索引扫描而改为全表扫描）。

3. 核心结论与建议

• 触发机制独立性： InnoDB 统计信息的自动收集是由数据页的变动触发的，它并不感知事务的边界。只要变更行数超过阈值，后台线程就会启动收集。
• 回滚导致偏差： 事务回滚（Rollback）不会反向触发统计信息的重新计算。这会导致 mysql.innodb_table_stats 中的数据与实际物理数据严重不符。
• 运维建议： 在生产环境中，如果执行了涉及大量数据的事务回滚，建议紧接着手动执行 ANALYZE TABLE，以修正统计信息，避免优化器产生错误的执行计划。