来源：Gitee 封面人物 丨 2025-11-27
四海内皆兄弟
从机械车间到数字世界，薛晓刚完成了一场出色的技术转型。作为一名非科班出身的数据库专家，在实践中逐渐淬炼出“大道至简”的技术哲学。在不同行业的复杂场景中，他见证了数据技术的迭代变迁，也亲历了从引进到自研的时代转折。本期专访将带你走进他的技术人生，聆听一位实践者的思考与洞见。
薛晓刚： 大家好！我叫薛晓刚，非科班出身，进入了命中注定适合我自己的数据库行业。
要简单一点的介绍嘛。说起来简单，实际上也不复杂。要不先上一张我的全景图吧。
是不是简单？就一张图。每一个图标就是一个身份。我们就说几个主要的吧。
薛晓刚： 我记得很清楚911袭击那天是我们专业到工厂和车间去参观学习。看到这个场面，我想如果以后我就做这个那我会奔溃的。我这里并不是说工厂车间的工作不好，而是不适合我。我就想着能换就换吧。
后来在电子通讯领域，这也是不得已。因为并没有其他更加合适我的，况且我就想找工作一样，不能一步到位的话，那就先找一个相近的。
我坦白说我当时没有预见到各种浪潮，也可能一切都是最好的安排吧。我觉得是巧了。
第一份工作就是做系统集成，在系统集成的领域中就涉及到了各种信息化的领域。有硬件、有软件、有网络、有中间件、还有操作系统和工控系统。这里当然还有就是数据库了。慢慢的觉得数据库是信息化的基石，而且在成长中不断遇到各种问题或者事件越发发现--数据库太重要了，以至于属于所谓的“卡脖子”的领域。所以最终就投身于数据库及数据架构的工作中去了。
薛晓刚： 机械的学士和通信的硕士，这都是学业。我更喜欢自己现在所做的数据架构的工作。主要是很少有学校有数据库这个专业啊！要是有我就去学习了，而不是靠自己自学。本硕两个阶段学习的都和现在没什么关系。
我自己在数据库行业有点知名度，也致力于这个领域。所以还是看我当下吧。
薛晓刚： 金融的数据成熟度最高，因为涉及到钱。关系到国计民生。出错了影响恶劣。
公安的成熟的也和金融一样，可以说不相上下。因为涉及到法。作为法律依据以及刑事侦查和技术侦查手段不可以不严谨。
而传统行业受制于松散的供应链和上下游，无法做到较好的数据治理。
薛晓刚： 例如to B的行业、医疗行业、传统的行业等业务逻辑复杂的，需求控制不好的，以及应用开发不受DBA控制的这些场景，替换难度很大。这里并不是说不能，而是代价大。如果不考虑问题性都能替换，如果说能不计代价按照对应的数据库要求重新做一遍也能替换。实在不行砍需求和功能。
因为Oracle仍然是最强大和最优秀的数据库，承认别人优秀不丢人。Oracle强大是公认的。在以上我说的场景中要命是Oracle轻松处理，要么是Oracle也勉强处理。如果是后者，那么在同等硬件下是否可以也勉强支持？这里不要说加硬件，因为现在用户手中的预算极少有条件这样做。
之所以会出现这种情况就是传统行业的业务复杂程度和2c的消费互联网不一样。业务流程长（每个环节都或多或少影响全局），业务周期长（跨年，甚至跨几年的都有），业务逻辑几乎不能纯应用侧解决，必须在数据库中以复杂的SQL处理。很多系统并没有存储过程，但是SQL复杂程度不亚于甚至超过了存储过程。
再加上应用开发人员能力不如大厂的应用开发能力强，所以SQL复杂度超出了大厂研发的认知，也是众多国产数据库没有预见到的。
比如400多个字段的表，几十个表的关联查询，几十万行的SQL，还有达到MB级别容量的SQL。
总结是：复杂且不受控的业务需求、缺乏数据库专业人士的设计、以及简单粗暴的实现是数据库稳定性的重大挑战。
薛晓刚： 这个其实不是我提的。更多的是国产数据库厂家提的。
我这里要说的是兼容性。这里可能大家会说，兼容性不是都做好了吗？你看各家都说兼容性90%-100%了
其实那是给非数据库行业的人看的。因为厂商宣传的兼容性是语法兼容性。意思是原来的SQL在这里运行没有语法错误。但是实际上，运行效果如何？在同等硬件环境下一样吗？注意我这个说的，如果说原来是硬件是一个单位（可以是CPU、内存和磁盘IO能力的组合），那么现在要10倍，甚至30倍的硬件才能有一样的效果。那么这个代价让用户出吗？关键是用之前用户知道这个信息吗？
可能有人说那如果硬件不变慢就慢一点。那么如果一个SQL原来是1秒，现在30秒。也能执行，但是超时是10秒。你说还能用吗？何况有时候还是执行不出来了。
对待祖传代码中复杂SQL：多表关联（几十个表关联），长SQL（几十万行的，甚至MB基本的SQL），超复杂SQL（比存储过程还长的SQL）现在有信心让开发不改，拿过来和以前一样用吗？
其实我觉得兼容性有：
语法兼容性（这点几乎都做到了常用的）；
性能兼容性：（这点几乎都没做到）---硬件兼容性。能做到性能自然硬件的成本也就下来了。不至于堆硬件。
生态兼容性：各种工具还能不能用？比如MySQL的工具可以继续用在TiDB上。OGG也能同步到TiDB上。
业务场景兼容性：做成一个通用场景的。不是只关注金融行业，金融行业是对数据库要求最严苛的。但是也是开发和运维最规矩的场景。非互联网行业和非金融行业的行业呢？占据了绝大部分应用场景。而这些业务场景都是复杂的，开发和运维都不规范的场景。
成本兼容性：综上硬件和应用改造---如果说Oracle、DB2、SQLSERVER这三个商业数据库的切换的成本和使用国产替换这三个的成本差不多。在用户看来都是能接受的。
薛晓刚： 其实我马上就要45岁了，我觉得只要一直从事在一线，保持技术的领先优势，一般来说还不用太担心这个危机。可能有不少技术转管理了，这里说的管理是纯管理，觉得一直做具体事情没有前途。我要说的是技术不能丢，不能因为成为了PPT工程师，而放弃了命令行工程师。技术人员一旦丧失了具体干活的能力（有能力不用和没有能力是两回事），那么危机随时到来。
不过即使能力出众，也不是万无一失。俗称的裁员裁到大动脉，其实就是说即使是动脉也可能被裁员。即使被裁也能再次就业那就不是危机。
我对于技术一直是不断保持着学习。这源于我不断参加各种技术会议和论坛、以及相关的技术社区和组织。长期活跃在这些“综艺”活动中，长期保持着技术的热爱与参与。
薛晓刚： 这个就像现在说的vibe coding一样。我觉得是有的场景合适，有的不合适。适合的就用。不适合的千万别用。
SQL也是如此。如果是简单的明确的可以用，不过AI只负责写SQL，是不是最优的AI不能保证。有没有结合业务？AI无法入侵到业务层面去了解。AI不能知道谓词的逻辑是不是正确，也不知道业务上的数据分布和是不是用到了索引。甚至对于业务的指令对错都不能判断。我见过太多的需求就是错的。
而更多的也是非常重要的，这个需求以及实现的SQL有没有意义或者有没有价值？AI不知道。有人说管的太多了，那是业务的事情，错了也是业务。如果有这种思维，那么就可以回答上一个问题。那30岁都可能是危机。因为让你做和AI做没有区别，那就用AI吧。
我们要做AI无法做到事情。
至于AI工具，我觉得能提高生产效率就用。我现在日常就用，而且用的很多。但是有一点要有识别的能力。要有管好AI的能力。
薛晓刚： 从总体拥有成本来考虑。压缩技术栈种类和系统规模。
能一个数据库解决的不要多个数据库。能用一种数据库解决的不用多种数据库。
数据是架构的中心。数据又存在数据库中。我们自己如果把架构搞得很复杂，开发难度就上升了，运维复杂度也上升了。最后都是公司（企业）的成本。
我经历过很多事情，大家挣个面红耳赤的问题就是数据怎么相互给，以及数据延迟、数据不一致等等基本问题。而如果相关的数据，有条件的放在一起，那么很多问题都解决了。
我经历一个案例。三个团队，三个数据库。其实他们是上下游。一个需求，三个团队都要做。三个数据库还都是异构的。每个团队都说人不够来不及。
最后我和业务方领导一起把数据库的数据合并了。
结果就是三个团队变一个了。一个需求下来，上游做了，下游只要读上游的数据就行。没有接口、没有中间件、没有数据同步和传输。没有扯皮，没有抱怨人手不足。实时性高，一致性完全保证。
当然我们对外部的不能这样。但是企业内部自己控制的还是可以的。
薛晓刚： 旅游、看书和玩游戏。
我优先是工作，毕竟是依靠工作收入。在工作不忙或者是实在没有心情继续下去，以及实在工作太累需要休息的时候转为去做爱好的事情，做一个调节。
薛晓刚： 今年成为了CCF数据库专委会的执行委员，我后续还想就是在学术上提升一下自己。
在数据库技术上更多的参与到各种技术活动中去，保持学习以及技术布道。
薛晓刚： 不要浮躁的折腾，脚踏实地做事。
注意劳逸结合，身体一定要健康。
97
