-
我在一个事务里反复查同一行数据,想等它被别的流程改成功就继续,结果别人明明早就改了、也提交了,我这边却怎么查都还是旧值、活活卡死在那里,排查半天发现是可重复读隔离级别下的快照读在作怪的深度复盘
我有段业务逻辑:开一个事务、做了些前置操作,然后轮询数据库里的某一行,等另一个流程把它的状态改成已完成就继续。我想当然认为别人改了并提交后我再查一次自然就能查到最新值。可上线后这段逻辑诡异卡死:我明明能用另一个连接直接查到状态早就是已完成、事务也提交成功了,可我这个事务里的轮询无论查多少次读到的永远是那个旧的处理中,像被冻住,死活等不到、最后超时。我一度怀疑缓存、主从延迟、别人没提交,逐一排除都对…- 0
- 0
-
从粗放 MySQL 交易库 @Transactional 包住整个大方法连远程支付调用都裹进事务里行锁被慢接口绑架数秒高峰锁等待瀑布堆积连接池占满雪崩 + 压根不懂隔离级别用默认或乱设脏读不可重复读幻读分不清还把快照读和 FOR UPDATE 当前读混用读出灵异结果 + 凡是更新就无脑 select for update 悲观锁把读多写少场景的并行更新硬串行化 + 加锁顺序五花八门死锁频发只能靠重启清场 + 更新条件不走索引 InnoDB 行锁退化成扫描路径锁住一大片甚至全表把无关更新全阻塞 + 热点大商家账户单行被每秒上万笔成交更新行锁让请求排成长龙吞吐卡死 + 库存扣减用裸 read-modify-write 并发下丢失更新导致严重超卖发不出货 + 大事务循环更新几万行跑几分钟持锁堆 undo 拖慢全库还有僵尸事务赖着不走 + 锁等待死锁长事务全是黑盒出事才 SSH 上去 show processlist 肉眼抓瞎 → 2026 现代高并发数据库工程 短事务只包必须原子的 DB 写远程调用挪到事务外 + 理解四个隔离级别权衡默认 RR 分清 MVCC 快照读当前读 + 读多写少用乐观锁版本号 CAS + 统一按主键升序加锁加死锁监控加自动重试 + 写条件必走索引 EXPLAIN 确认行锁精准只锁命中行 + 热点账户余额分桶拆成多行分散并发读时 SUM 合并 + 原子 UPDATE x=x±? 加 stock>=1 条件根治丢失更新和超卖 + 批量拆成分批小事务加长事务监控告警 + performance_schema 持续度量锁等待和长事务做大盘告警 87 天战役复盘:47 套工程修法 + 7 个 P0 复盘 + 6 条工程哲学
8 人的数据库与交易平台团队 87 天把一套跑了五年、日订单量从每天几十万笔涨到上千万笔、大促高峰每秒上万笔并发写入后种种粗放并发写法集中爆雷的核心交易数据库——@Transactional 习惯性地甩在最外层大方法上把查库改库远程支付调用发消息发短信统统圈进同一个事务里一次慢支付就让账户行锁被绑架数秒高峰期锁等待瀑布式堆积连接池被长事务占满整个交易服务超时雪崩、压根不懂事务隔离级别要么手欠调到串…- 5
- 0
-
PostgreSQL 高频 UPDATE 表 bloat 到 1.4TB 拖垮 P99 的 5 天复盘:autovacuum 调参 + pg_repack 在线重建实战
一张 8.4 亿行的 user_events 表,P99 从 80ms 一路缓慢飙到 800ms,EXPLAIN 看起来正常。5 天定位根因:autovacuum 跟不上高频 UPDATE 产生的 dead tuple,表物理大小膨胀 6.3 倍。本文完整复盘 PG MVCC dead tuple 机制、autovacuum 瓶颈、pg_repack 在线重建,落地 9 条治理纪律。- 2
- 0
-
PostgreSQL bloat 治理实战:1.2 亿行表从 380GB 压到 152GB
1.2 亿行 orders 表磁盘占 380GB,死元组占 47%,查询 p99 飙到 10 秒。本文实录 PG MVCC 膨胀定位 + pg_repack 在线清理 + autovacuum 调优 + 长事务监控 + fillfactor + 分区化迁移全过程,附 VACUUM FULL / pg_repack / 分区三套方案对比。- 2
- 0
-
MVCC 完全指南:从 ReadView 到 InnoDB 多版本并发控制
MVCC(Multi-Version Concurrency Control,多版本并发控制)是现代数据库实现"读不阻塞写,写不阻塞读"的关键技术。MySQL InnoDB、PostgreSQL、Oracle 全用它。但大多数人对 MVCC 的理解停留在"有多个版本",问起 ReadView 怎么算、四个隔离级别下具体怎么工作、为什么 RR 隔离级别能解决幻…- 0
- 0
MVCC
-
￥优惠劵使用时效：无法使用使用时效：
之前
使用时效：永久有效优惠劵ID：×