我记得北美有个客户，他们的研发负责人以前在 Google 负责 Spanner 和 Bigtable，整整干了 20 多年分布式系统。当我们 TiDB 出现一些问题时，他们给了我们不少宝贵建议。
这种来自客户的“高手过招”，真正让我们团队水平大幅提升。
更夸张的案例发生在另一个北美客户身上，他们提出一个我们完全没想到的需求：
“能不能支持导入单表 50TB 的数据？”
50TB 单表，这在当时对我们来说简直就是一个疯狂的要求。 最初几次尝试全部失败了，客户非常愤怒，甚至威胁：“一个星期内搞不定，合同就终止！”
我们连夜死磕技术难题，优化流程、提升性能，最终成功了。
刚想松口气，又有个客户来了更大的挑战：“我们这里有个单表要导入 100TB 数据，可以吗？”
幸好有之前的 50TB 经验，客户自己竟然导入成功了。
这次经历给了我们巨大自信：
“原来 TiDB 可以做到我们从没想过的极致场景。”
另一个让我们印象深刻的是一个头部的 SaaS 客户。
客户问：“TiDB 能不能支持 100 万张表？”
我们当时非常震惊：
1.一般 OLTP 系统咋可能有这么多表；
2.但这家公司是 SaaS 模式，每个租户单独数据库，每个数据库又几张表；
3.因为租户数量巨大，一个集群必须承载百万张表的需求。
这种规模，我们之前从未考虑过。
为了满足客户需求，我们直接对TiDB底层架构做了大规模重构：
1.优化 Schema 层；
2.重构优化器；
3.大量减少单表管理的内存占用。
最终成功支持了百万张表的极限场景。
后来其他 SaaS 客户听说了这件事，也开始尝试和选择了 TiDB。 可以说，这个客户需求，直接帮助我们打开了一个全新的市场领域。
TiDB 研发早期，有一种争论：“研发要不要直接支持客户？”
毕竟研发团队都喜欢安静地写代码，谁也不愿意天天接客户电话、跑客户现场。
但我们最终还是决定：研发必须支持客户。
我们甚至专门成立了一个叫 Customer Advocate 的项目：
1.对于重要客户，分配一位研发负责人；
2.研发负责人需要深入理解客户场景和需求；
3.一旦客户有问题，可以求助这位研发负责人协调解决。
有一个研发负责人一年跟同一个客户开了超过 200 次会，听起来简直疯狂。
但结果却非常好：
1.客户获得了最专业的支持；
2.工程师获得了最真实的场景反馈；
3.产品获得了更高的客户满意度和忠诚度。
客户自己也开始用脚投票，先将他们的 HBase 切换到 TiDB，现在开始切更大规模的 Aurora。
回头看，我们才深刻认识到：
1.客户是真正的专家；
2.真实的业务场景比纸面上的技术设计更重要；
3.只有深入客户一线，我们才能真正做出客户想要的数据库产品。
这种坚持客户成功的策略，也为我们赢得了大量全球客户的认可。
从“技术导向”到“客户成功导向”的转变， 对我们这群程序员来说，并不是一件容易的事。
但当我们真正做到时，我们才发现：
“客户成功，才是我们作为程序员最大的骄傲。”
客户的每一句感谢，每一次信任，每一次业务的成功，都成为我们不断前进的动力。
而TiDB能走到今天，靠的正是这种“客户成功”的理念。
未来，我们仍将坚定地践行：
以客户成功为唯一目标，持续打造更好的数据库产品。
九：我的十年成长，从程序员到技术管理者的蜕变
作为“员工一号”的十年旅程，十年前，我以 PingCAP 第一个正式员工的身份加入，亲身参与了 TiDB 从零到一的全过程。这十年间，公司的快速成长与变化，也带动了我个人成长的巨大转型。
从一个单纯热爱技术的程序员，到如今带领整个研发团队的技术管理者，这条成长之路充满挑战与收获。