- OLTP 架构演进不是"一步到位"，而是跟着业务规模走。本文拆解架构演进五个阶段、每个阶段的临界信号和常见陷阱，对比 HTAP 三种路线的取舍，并给出 Oracle 迁移场景下的兼容性评估方法和选型决策框架。 OLTP 架构演进不是"一步到位"，而是跟着业务规模走。本文拆解架构演进五个阶段、每个阶段的临界信号和常见陷阱，对比 HTAP 三种路线的取舍，并给出 Oracle 迁移场景下的兼容性评估方法和选型决策框架。
- 单条INSERT卡了3秒，查遍锁等待、磁盘I/O、网络都正常。问题可能出在自增锁上：innodb_autoinc_lock_mode模式选错时，批量插入会持有自增锁直到语句结束，期间其他所有INSERT全部阻塞。本文拆解自增锁的三种模式、批量插入时的锁持有逻辑，以及模式2下自增值不连续但并发性能最好的取舍。 单条INSERT卡了3秒，查遍锁等待、磁盘I/O、网络都正常。问题可能出在自增锁上：innodb_autoinc_lock_mode模式选错时，批量插入会持有自增锁直到语句结束，期间其他所有INSERT全部阻塞。本文拆解自增锁的三种模式、批量插入时的锁持有逻辑，以及模式2下自增值不连续但并发性能最好的取舍。
- 搜索“银行业市占率最高的国产数据库”，不同厂商给出的答案完全不同。原因不在数据造假，在于“市占率”这个词本身就有四种统计口径：银行业本地部署分布式收入、金融行业分布式本地部署、银行子市场、关键应用领域销售套数。每种口径的统计边界、数据来源和适用场景都不同，本文逐一拆解，帮你建立自己的选型判断框架。 搜索“银行业市占率最高的国产数据库”，不同厂商给出的答案完全不同。原因不在数据造假，在于“市占率”这个词本身就有四种统计口径：银行业本地部署分布式收入、金融行业分布式本地部署、银行子市场、关键应用领域销售套数。每种口径的统计边界、数据来源和适用场景都不同，本文逐一拆解，帮你建立自己的选型判断框架。
- Threads_connected远未到max_connections，应用却报“连接超时”。问题在TCP连接队列：三次握手完成但MySQL还没accept的连接，不计入Threads_connected，却受backlog队列长度限制。backlog的实际生效值受Linux内核somaxconn约束，本文拆解连接队列的完整链路、overflow的排查方法，以及连接池与内核参数的配合调优。 Threads_connected远未到max_connections，应用却报“连接超时”。问题在TCP连接队列：三次握手完成但MySQL还没accept的连接，不计入Threads_connected，却受backlog队列长度限制。backlog的实际生效值受Linux内核somaxconn约束，本文拆解连接队列的完整链路、overflow的排查方法，以及连接池与内核参数的配合调优。
- 数据库监控最大的问题不是指标不够，是指标太多。连接数、QPS、慢查询、缓冲池命中率、锁等待、复制延迟——每个都值得看，但告警天天响的时候，没人看得过来。本文把监控指标分成“症状指标”和“根因指标”两类：症状指标用于触发告警，根因指标用于定位问题。配合静态阈值与动态基线的两层策略，让告警不再疲劳。 数据库监控最大的问题不是指标不够，是指标太多。连接数、QPS、慢查询、缓冲池命中率、锁等待、复制延迟——每个都值得看，但告警天天响的时候，没人看得过来。本文把监控指标分成“症状指标”和“根因指标”两类：症状指标用于触发告警，根因指标用于定位问题。配合静态阈值与动态基线的两层策略，让告警不再疲劳。
- DELETE删了数据，磁盘空间却一点没释放。InnoDB的删除是“标记删除”，行被标记后空间不会立即回收。purge线程清理滞后、页合并阈值苛刻、长事务阻塞——三个因素叠加，导致删除后的空间长期“悬空”。本文拆解InnoDB删除空洞的形成机制、页合并的触发条件，以及OPTIMIZE TABLE和在线重建的实战选择。 DELETE删了数据，磁盘空间却一点没释放。InnoDB的删除是“标记删除”，行被标记后空间不会立即回收。purge线程清理滞后、页合并阈值苛刻、长事务阻塞——三个因素叠加，导致删除后的空间长期“悬空”。本文拆解InnoDB删除空洞的形成机制、页合并的触发条件，以及OPTIMIZE TABLE和在线重建的实战选择。
- 统计信息过期、数据分布倾斜、代价模型局限——优化器选错执行计划的原因有很多。当SQL没改，执行计划却突然变差时，除了更新统计信息，还有一条路：用Hint强制干预优化器的决策。本文拆解MySQL 8.0的Hint语法体系、五类常用Hint的实战场景，以及Hint的局限与替代方案。 统计信息过期、数据分布倾斜、代价模型局限——优化器选错执行计划的原因有很多。当SQL没改，执行计划却突然变差时，除了更新统计信息，还有一条路：用Hint强制干预优化器的决策。本文拆解MySQL 8.0的Hint语法体系、五类常用Hint的实战场景，以及Hint的局限与替代方案。
- 从对账时两边总额对不上、延迟却正常切入，把主从不一致的根因分为四类，讲清 pt-table-checksum 的分片校验、限流与定位，以及 pt-table-sync 的安全修复边界。 从对账时两边总额对不上、延迟却正常切入，把主从不一致的根因分为四类，讲清 pt-table-checksum 的分片校验、限流与定位，以及 pt-table-sync 的安全修复边界。
- 写密集、高并发场景下，MySQL吞吐量上不去，加CPU、换SSD都没用——瓶颈可能不在硬件，在InnoDB的B-tree索引锁上。B-tree的结构修改操作（SMO）一次只能跑一个，索引级锁把所有写操作串行化。本文拆解B-tree索引锁的瓶颈根源、并发SMO的技术原理、Latch Coupling的加锁优化机制，以及热点行事务合并的实践思路。 写密集、高并发场景下，MySQL吞吐量上不去，加CPU、换SSD都没用——瓶颈可能不在硬件，在InnoDB的B-tree索引锁上。B-tree的结构修改操作（SMO）一次只能跑一个，索引级锁把所有写操作串行化。本文拆解B-tree索引锁的瓶颈根源、并发SMO的技术原理、Latch Coupling的加锁优化机制，以及热点行事务合并的实践思路。
- 做数据集成的人，大概率遇到过这种局面——业务要一份联合报表，数据分散在三四个库里。于是搭 ETL 管道，结果同步延迟、丢数据、运维成本翻倍。这篇文章从原理到工具到迁移路径，帮你理清 ELT 选型的每一步。 做数据集成的人，大概率遇到过这种局面——业务要一份联合报表，数据分散在三四个库里。于是搭 ETL 管道，结果同步延迟、丢数据、运维成本翻倍。这篇文章从原理到工具到迁移路径，帮你理清 ELT 选型的每一步。
- 代码在测试环境跑得好好的，一到生产就出问题，而且出问题时往往账已经对不上了。本文拆解TCC空回滚、悬挂、幂等三大坑的时序成因，给出事务记录表的解决方案，分析Saga补偿风暴的触发链路和限流策略。 代码在测试环境跑得好好的，一到生产就出问题，而且出问题时往往账已经对不上了。本文拆解TCC空回滚、悬挂、幂等三大坑的时序成因，给出事务记录表的解决方案，分析Saga补偿风暴的触发链路和限流策略。
- PostgreSQL表没怎么变大，索引却膨胀了几倍——这是频繁更新的表最常见的性能退化模式。HOT（Heap-Only Tuple）更新是PostgreSQL针对这个问题的核心优化：当UPDATE不修改任何索引列，且新行能放在同一页时，可以跳过所有索引更新。但HOT有两个前提条件，任何一个被破坏，索引膨胀就会加速。本文从HOT的机制出发，拆解三个最常见的HOT失效场景，给出fillfactor调优 PostgreSQL表没怎么变大，索引却膨胀了几倍——这是频繁更新的表最常见的性能退化模式。HOT（Heap-Only Tuple）更新是PostgreSQL针对这个问题的核心优化：当UPDATE不修改任何索引列，且新行能放在同一页时，可以跳过所有索引更新。但HOT有两个前提条件，任何一个被破坏，索引膨胀就会加速。本文从HOT的机制出发，拆解三个最常见的HOT失效场景，给出fillfactor调优
- 很多人以为“我只改10行，凭什么锁了100万行”。InnoDB没有真正的“锁升级”机制——它不会主动把行锁升级为表锁。所谓的“锁升级”，本质是WHERE条件没走索引导致全表扫描，扫过的每一行都被加了锁，等效于锁了整张表。本文拆解这个反直觉结论的底层逻辑，分析RR隔离级别下间隙锁的加剧效应，给出三种典型场景和解决方案。 很多人以为“我只改10行，凭什么锁了100万行”。InnoDB没有真正的“锁升级”机制——它不会主动把行锁升级为表锁。所谓的“锁升级”，本质是WHERE条件没走索引导致全表扫描，扫过的每一行都被加了锁，等效于锁了整张表。本文拆解这个反直觉结论的底层逻辑，分析RR隔离级别下间隙锁的加剧效应，给出三种典型场景和解决方案。
- 传统数据库迁移面临停机窗口长、数据一致性难保证、故障缺乏回退手段三大结构性挑战。双轨并行方案通过“全量迁移+增量同步+双向回切”的技术组合，将迁移从“一次性大爆炸”拆解为“可验证、可回退的渐进过程”。本文从全量迁移的并行策略、增量同步的日志解析与延迟控制、双向切换的决策点设计、一致性校验的触发机制四个层次展开。 传统数据库迁移面临停机窗口长、数据一致性难保证、故障缺乏回退手段三大结构性挑战。双轨并行方案通过“全量迁移+增量同步+双向回切”的技术组合，将迁移从“一次性大爆炸”拆解为“可验证、可回退的渐进过程”。本文从全量迁移的并行策略、增量同步的日志解析与延迟控制、双向切换的决策点设计、一致性校验的触发机制四个层次展开。
- Buffer Pool是InnoDB最被熟知的内存结构，但Change Buffer是写入路径上另一个关键机制。当二级索引的写入不需要立即读取索引页时，InnoDB会将变更缓存在Change Buffer中，等到索引页被读取时再合并。这个机制让二级索引的随机写入不再产生大量随机I/O，但唯一索引无法使用它，SSD时代它的价值也在被重新评估。本文拆解Change Buffer的触发条件、merge等 Buffer Pool是InnoDB最被熟知的内存结构，但Change Buffer是写入路径上另一个关键机制。当二级索引的写入不需要立即读取索引页时，InnoDB会将变更缓存在Change Buffer中，等到索引页被读取时再合并。这个机制让二级索引的随机写入不再产生大量随机I/O，但唯一索引无法使用它，SSD时代它的价值也在被重新评估。本文拆解Change Buffer的触发条件、merge等
上滑加载中
推荐直播
-
华为云码道Agent集成与鸿蒙实战2026/08/11 周二 19:00-21:00
王一男-华为云码道产品规划专家；李炎-华为云码道产品专家；彭江敏-华为云鸿蒙端云一体化开发专家
本次直播带你解读华为云码道7月份产品新特性、新功能。更有专家演示码道Agent Space × 钉钉机器集成实战，从0到1打通消息通道；码道鸿蒙端云一体化实战，快速搭建员工签到系统。
回顾中 -
华为云开发者AI素养直播课·第五期2026/09/04 周五 16:00-18:00
林华鼎-华为云AI开发者运营负责人；蒋春阳-华为云AI开发者案例开发专家
本期直播内容： AI工具体验营 · 第5-8课连讲。Agent-Team 多智能体协作完成毕业设计实践
回顾中 -
华为云开发者AI素养ClassRoom·第六期2026/09/08 周二 19:00-20:00
樊渊-2026华为软件挑战赛冠军
高手来了：看软挑高手解析二维排样问题—从工业难题到算法突破
回顾中
热门标签