报表查询不适合默认repeatable read，因其在长事务中持续持有间隙锁和记录锁，阻塞写入、占用内存高、快照静止但锁资源长期占用；而read committed配合start transaction read only可大幅缩短锁持有时间、降低内存开销、跳过undo log分配，提升并发性能。
对报表查询来说，把隔离级别设为 READ COMMITTED 通常比默认的 REPEATABLE READ 更合适，但必须配合只读事务显式声明，否则收益有限甚至引入幻读风险。
为什么报表查询不适合默认的 REPEATABLE READ
MySQL 8.0 默认的 REPEATABLE READ 在报表类长事务中会持续持有间隙锁（gap lock）和记录锁，尤其当查询带范围条件（如 WHERE create_time BETWEEN '2025-01-01' AND '2025-12-31'）时，InnoDB 会锁定整个索引区间。这会导致：
- 其他写事务在该时间范围内插入/更新被阻塞，报表一跑，业务写入就卡住
- 锁占用内存随扫描行数线性增长，大表扫描容易触发
ER_LOCK_TABLE_FULL错误 - MVCC 快照从事务开始时刻起固定，报表中途看到的数据“静止”，但代价是锁资源长期占用
READ COMMITTED 能带来什么实际好处
READ COMMITTED 下，InnoDB 不使用间隙锁（仅在唯一索引等极少数场景例外），每次 SELECT 都基于语句执行时刻的最新已提交快照——这对报表很友好：
- 锁持有时间大幅缩短：查完即放，不拖累写操作
- 锁内存占用下降，降低
ER_LOCK_TABLE_FULL概率 - 配合
START TRANSACTION READ ONLY，InnoDB 能跳过 undo log 分配等开销，进一步提速 - 注意：它不解决幻读，比如两次
SELECT COUNT(*)可能返回不同结果；但报表多数场景可接受这种“最终一致性”
必须搭配 START TRANSACTION READ ONLY 才有效
光改隔离级别不够。MySQL 8.0 对只读事务有专门优化路径，但前提是显式声明：
- 错误写法：
SET SESSION transaction_isolation = 'READ-COMMITTED'; SELECT * FROM sales_report;→ 仍是普通读写事务，锁和 undo 开销照旧 - 正确写法：
START TRANSACTION READ ONLY; SELECT * FROM sales_report; COMMIT;→ InnoDB 知道无需维护事务级快照、不分配 undo segment、不加间隙锁 - 若用连接池，记得在执行前重置事务状态，避免复用连接时残留
READ WRITE模式
配置方式与易踩的坑
全局设为 READ COMMITTED 是基础，但真正起效依赖会话级控制和应用层配合：
- 配置文件里加
transaction-isolation = READ-COMMITTED，避免重启失效；别用SET GLOBAL，需要 SUPER 权限且不作用于已有连接 - 不要在存储过程中动态
SET SESSION transaction_isolation后再查报表——如果事务已开启，该语句会被忽略 - 确认生效用
SELECT @@transaction_isolation，不是@@tx_isolation（8.0+ 已废弃） - 如果报表需强一致性（如财务对账），
READ COMMITTED+READ ONLY不够，得回退到REPEATABLE READ并控制事务粒度，比如按天分段查
真正影响报表性能的从来不是隔离级别本身，而是它背后锁行为、MVCC 快照机制和 undo 开销的组合。不声明 READ ONLY，调再低的隔离级别也白搭；不理解间隙锁释放时机，就容易把报表变成业务写入的瓶颈源。
