当时情况特别棘手：
1.删除日志、垃圾数据，结果发现删的速度远赶不上写入的速度；
2.调度数据迁移，又因为 Raft Snapshot 也会占用磁盘空间，越迁越爆。
我们在客户办公室熬到了凌晨四点，最终想了个折中的办法：
1.大幅降低调度频率，控制 Snapshot 产生；
2.同时限制业务写入速率，让系统慢慢恢复平衡。
虽然最后解决了问题，但这个深夜的经历，再次提醒我们：
“扩展性强意味着责任更大，客户越信任我们，我们身上的担子就越重。”
在海外市场，我们曾经输给过某些知名竞争对手。客户一开始都会选择更有名的竞品，结果过了半年，客户又回来了。
原因很简单： 竞品虽然名气大，但到了真正业务规模上来之后，扩展性撑不住。
而 TiDB 却能实实在在地经受住百 TB 甚至 PB 级别数据规模的考验。
这个时候，我们才真正体会到，扩展性不是喊口号，而是客户真正选型时绕不开的刚需。
TiDB 在 3.0 后发展太顺利，客户增长速度快到不可思议，甚至一度让我们产生了盲目的自信。但后面我们逐渐发现，这种盲目自信埋下了不少隐患，尤其在产品质量上，后来爆发了不少问题。
但这一切，都是后话了。
TiDB 靠扩展性赢得了客户，也背负了更大的责任。越是客户核心的业务系统，越容不得半点闪失。
这段时间我们深刻理解到一句话：
“扩展性，既是我们的超级武器，也是沉甸甸的责任。”
五：从混乱无序到初见曙光（产品驱动与客户成功驱动的转变）
TiDB 早期发展太快了，以至于我们逐渐陷入了一种无序而混乱的状态。最典型的例子就是4.0版本的发布。
当时我们延续着“一年一个大版本”的节奏，看似很稳，但实际内部非常紧张：每年大量的新功能堆叠在一起，导致测试周期严重不足，产品质量逐渐失控。
结果 TiDB 4.0 发布后，我们连续发了 12 个补丁版本才把质量稳定下来，客户的抱怨、投诉几乎把我们的信心打到了谷底。
那时候我经常半夜被电话吵醒，每天早上第一件事就是看有没有客户因为版本 bug 又炸了。
痛定思痛，我们开始反思：
“是时候改变我们的做法了。”
回头看，我们当时犯了一个特别大的错误，就是整个公司几乎没有 PM（产品经理）的角色。
最搞笑的是，我们当时甚至自信满满地说：“我们不需要 PM，程序员自己就是最好的 PM。”
事实证明，这种想法蠢到极点。
没有 PM 导致：
1.功能优先级没人管；
2.产品战略没人想；
3.客户场景没人深度研究；
最后，我们的产品变成了一锅乱炖，没有清晰的战略方向，功能叠加得很随意，也无法真正解决客户最核心的痛点。
后来，我们终于认清了一个事实：
“程序员不可能做好所有的事情，产品必须由专门的角色负责。”
于是，我们开始认真引入了专业的 PM 角色。他们的加入，带来了一个非常关键的变化：
1.明确了功能开发的优先级；
2.每个版本都有了明确的主题；
3.真正以客户需求为中心，逐渐转变成产品驱动和客户成功驱动。
这次转型带来的最大变化，就是让我们从“技术自嗨”变成真正“解决客户问题”，逐渐找回了客户的信任。
TiDB 4.0 的发布惨痛教训，让我们认识到： “一年一版本”看似稳定，实则风险巨大。
于是我们改成了“两个月一次”的“火车发布”模式，快速迭代、小步快跑，每次发布的功能不多，质量更好掌控。
但新问题又来了：版本太多了，客户都不知道怎么选。如果发现一个 bug，要在好几个版本之间不停地 cherry-pick，研发成本又特别高。
于是，我们最后找到了折中的方案——“半年发布”模式：
1.既能兼顾稳定性，又能控制版本数量；
2.同时也给研发团队足够的时间保证产品质量。
经历了 TiDB 4.0 的惨痛经历后，我们在 TiDB 6.0 开始，把质量明确放在了第一位。
这一次，我们真正下了大功夫：
1.大幅优化了内存使用，解决了 OOM 的问题；
2.系统地改善了磁盘 IO 抖动问题；
3.将大量精力放在稳定性优化上，而不是盲目追求新功能。
结果 TiDB 6.0 发布后，客户反馈一下子好了很多。
但云时代来了，情况又发生了变化：
1.我们可以在云上快速发布功能，让客户提前用起来；
2.通过云的快速反馈，验证功能稳定后，再整合到一年一次的 LTS 版本发布中。
这个策略让我们既能保持产品创新速度，又能保证稳定性。用云的力量实现快速反馈，再用LTS版本提供长期稳定的保障，这个组合拳效果非常好。