我想这个话题一定会引发热议，毕竟我们很多方面都已经“遥遥领先”了。这里我想从几个小的点来简单比较一下我们与漂亮国之间关系型数据库是否还有差距，或者说差距有多大。我想用一些数据来证明或许更好。
研发投入、营收、人员规模
达梦数据库在2022年提交了IPO申请，因为一些原因中止后，近期又更新了数据再次提交（最新消息科创板已经批复)，由于数据都是公开的（应该是真实数据）。因此我们尝试从公开财报来看一些端倪。首先看财报：
从营收来看，达梦的收入还是一如既往的猛，但是看利润和增长都有一定下降的趋势(前几年靠政策，最近2年竞争比较激烈了)。这不是重点，我们重点看一下研发投入：
我们可以看到，截止到2023/6/30号，达梦一共有1402人，其中研发人员是430人；我们假定这430人都是数据库研发人员（包括内核，内核测试,配套工具等），因为从收入来看，达梦的营收主要是关系型数据库软件（收入占比90.29%）：
从实际研发投入来看2023年上半年是7553.26万元，其中研发人数是430人（研发人员占比30%）。那么研发人员人均成本是17.56万（包含社保、公积金等支出,这数据明显偏低，一个数据库内核开发人员应该不会低于40w年薪，实习生校招生除外）；一年大概是1.4亿~1.5亿之间，上半年研发投入成本大概26%，考虑到下半年往往收入占大头并结合2022年的情况，我认为研发成本在20%左右是相对合理的。我们假定这是一个行业通用数据，数据库研发投入占比20%（也有些处于增长期的公司，研发投入会更大，比如我们云和恩墨，22年研发投入占比40%左右）。
达梦作为一家国产老4家的Top 1企业，无疑研发投入和人数都是最多的，其次是南大通用和人大金仓。金仓2022年披露的营收数据是3.44亿，如果也是20%研发投入，那么研发投入应该是接近7000万，假定人均成本是35万(考虑到金仓在北京)，那么应该是200人左右（天眼查显示2022年社保人数是435人)。
从之前IDC发布的的数据来看，南大通用的市场份额是7.5%，金仓是13.9%；根据比例大致计算下，南大通用2022年数据库软件收入应该在1.8亿左右。如果我们这里仍然按上面的标准来简单估算一下，假定研发投入比在20%~40%，那么南达的研发投入应该是3600~7200w，研发人员应该在120~240人左右(从天眼查看2022年报告社保信息是394人),大约也是30%的研发人员占比。作为集中式数据库的玩家，上述3家毫无疑问是规模最大的，我相信研发投入也是最高的；但是3家研发人员加起来也就在1000人规模左右。
其他的集中式数据库厂家大约该有160家，规模较大的应该在过百人的研发团队，规模较小的我认为也就10-20人，我们假定平均50人，那么就是8000人。
最后我们再来看下主流的几家分布式厂商的情况：
OceanBase：天眼查显示2022年社保160人，据传一年研发投入5个亿，信息似乎有点不对，之前从小道消息听闻研发人员300人左右。
TDSQL：之前看腾讯公布的2023 Q3财报金融科技及企业服务 板块收入422亿，其中toB企业服务收入占比超过30%，TDSQL收入占企业服务5%，那么可以倒推一下：6.33亿（第3季度);收入同步增长30%，我估计2023年TDSQL 总收入会超过25亿RMB（应该是包括公有云RDS的部分）。以此推算，假定人均年薪100w，那么数据库研发总人数应在700人左右。
阿里云：阿里云数据库较多，根据IDC公布的2023年上半年数据，阿里云整个关系型数据库收入占比国内（公有云+本地部署）27%，总规模17.5亿美金；根据最新汇率计算，阿里云数据库2023年上半年营收在33.5亿 RMB；全年营收70亿左右（中国数据库领域绝对的王者),假定研发投入占比30%，人均年薪100w，那么总人数在2100人左右（数据库内核，数据库生态工具等所有)
GoldenDB：天眼查显示2022年社保337人，假定都是研发人员，且年薪百万，那么一年大概3.3亿研发投入。
GaussDB：根据IDC 2022年数据，华为云数据库收入占比10%出头，比TDSQL略低，估计一年营收在20亿左右，据称研投入一年10个亿，人员估计有近1000人。
TiDB：听说TiDB人数在500~600人，研发占大头,假定300人数据库研发；人均80w，那么每年研发成本2.4亿左右。
巨杉：没找到22年数据，看21年社保数据是108人，考虑到这几年经济，我估计截止到22年，人数规模差不了太多。
GreateSQL：根据了解数据库研发团队在80~100人左右，研发投入5000w左右。
HotDB：热璞科技，这些年也在很多行业有过不少案例，据了解研发团队应该应该不会超过30人（天眼查显示22年社保人数28人)
当然还有一些其他的厂商，据了解规模应该都相对更小一些。
综上，头部厂商研发成本总数大概在30亿左右，假定其他的厂商平均每家4000w，那么160家也就64亿投入，因此整个国内数据库研发投入我估计在100亿左右（我相信这个数据还有点偏高了，我们姑且就往高了算）。从人数上来看，目前国产数据库研发人员（包括内核，数据库配套工具等)，我估计全部加起来也就1.2-1.5万人(实际上这里面不少人员可能还是数据库配套工具，生态产品的一些研发人员并非数据库内核)。
最后我们来看下甲骨文的实际情况：
我们可以看到最近1年财报显示，Oracle营收是499.5亿美金，研发投入是86.23亿美金，其中从2018年 至今，每年的研发投入均超过60亿美金。如果你登录Oracle官网会发现，提示全球有17万员工，其中数据库研发人员是48000人，人均研发成本大概是18万美金左右。研发投入占比大概是17%左右。
接下来我们继续看下Oracle的收入组成：
我们看到Oracle在亚太地区的收入占比并不高，才13.25%（难道因为国内大部分用户都是白嫖的原因？）。根据了解其中许可证收入包括：云与本地许可证业务主要涵盖软件/应用程序、数据库和中间件等，客户可以使用甲骨文提供的云基础设施，或客户自己的云设施、本地设施部署产品。
1）软件/应用程序产品主要包括E-Business套件，PeopleSoft，JD Edwards和Siebel等，主要用于企业核心业务的管理和自动化。
2）数据库产品可帮助企业对数据进行安全可靠的存储、检索和读取等，甲骨文Oracle数据库是全球最流行的企业数据库之一。
3）中间件采用Oracle的Java技术平台构建，旨在跨平台环境（云、本地或混合）中简化和缩短应用程序和服务的部署流程与时间。
4）Java许可，甲骨文是Java平台和生态的管理者，客户通过订阅包含Java许可和支持的服务来购买Java产品。
假定其中数据库软件占据大头，60%。那么数据库软件收入是55.79*0.6=34.6亿，如果仍然按18w美刀的人员成本；那么数据库软件的研发人员数量应该是：346000万*0.17/18=3267 人。 实际数据可能会更多一些。我记得盖总2021年写过一篇相关文章，提到Oracle2个核心数据库大部分人数大约在4000人左右，考虑到近2年其研发投入增长了40%，那么如果人员也同样增加40%的话，那么数据库研发总人数应该在5600人左右。
最后我们再来看看Gartner的数据：
如果Gartner的数据相对准确的话，那么我想应该把许可证支持都算成是软件收入才相对接近真实数据，如果是这样，那么估算出来数据库研发人员数量应该是23705人。这个数字就非常的庞大了；大概率国内所有数据库的数据库研发人员加起来，应该都没有这么多。
不管怎么算来算去，我们都可以看到其研发投入是巨大的，人员规模也是巨大的。如果我们国产数据库真的要超越甚至弯道超车，我想难度还是很大的，路漫漫其修远兮。
之前看网上有人讨论说Oracle的代码超过2000万行，改动很困难，以至于创新不足。我想可能这是个误区，如果真的创新不足了，大可不必每年这么高的研发投入，老美的钱也不是大风刮来的。大家如果去看人家的官方文档，也会发现，不断的在推出新功能，真的还是非常强大，我们要实事求是。
从营收上来看，甲骨文目前的收入仍然是非常高，虽然已经被AWS超越，毕竟甲骨文是全球市场，我们现在主要还是国内战场。中国数据库市场占比全球来讲，比例并不高。因此从整体营收来说，差距还是非常巨大的。
最后从研发投入和人数上，大家自行算数一下，我们和Oracle的差距有多大? 好在这些年，国家越来越重视基础软件的研发投入，各个大厂也开始卷进来，我相信假以时日，国产数据库一定会走出国门（OceanBase已经在印尼版支付宝大面积上线），在国际市场上也大放异彩的。毕竟在过去5000年的历史长河中，我们有数千年都是No 1，遥遥领先，我相信这次也不会例外！
从一个SQL执行时快时慢的问题展开
最近有网友私信问到SQL优化,说一个系统有些业务SQL经常出现时快时慢的情况，发了一个脚本给对方查看了该SQL最近一周的执行情况。
我们可以清楚的看到确实这个业务SQL的执行计划有很多个plan hash value。如果我们不去分析SQL本身是否还有优化空间的话，单纯为了解决这个问题，是相对简单的。比如Oracle 提供了很多种固定SQL执行计划的方式;从ountline到sql profile 再到后面的SPM，以及自适应调整执行计划等等。
如果细看上面SQL的结果，你会发现还有很多查询value，从这个角度来讲，目前很多国产数据库还没有这些统计信息，也就是说你想要更加深入的分析一下SQL的执行计划，可能都无能为力，这应该算是数据库观测性的一方面。其次，如果我们要去固定SQL的执行计划，那么也并非所有国产数据库都支持这些功能点。
比如MogDB 在3.1 引入了SQL Patch功能，类似Oracle SQL Profile，可以去固定或者干预SQL执行计划。又比如OceanBase在2.2.x版本也引入了SPM功能（DBMS_SPM)，从官方文档 介绍来看，是类似Oracle SPM功能的。
其次我们说数据库最为核心的几个方面，存储引擎、SQL引擎和事务引擎，就拿SQL引擎来讲，如果我们看OceanBase 企业版4.x的最新文档中，其中关于查询转换的内容，你会发现目前仅支持 OR-Expansion；也就是说只支持把子查询转成union all，其他的都暂时还不支持(比如视图合并、谓词推入 、星形查询等等)。实际上这方面，如果大家去看甲骨文，你会发现有数十种查询重写规则（大家可以去看看12c之后版本的优化器相关参数即可)。我个人认为这方面是最牛的，为何这样讲？因为优化器强大，任你SQL再差，都可以跑呀。这也就是解释了一些网友在群里讲的，一个复杂SQL在oracle上跑的很快，到某国产数据库上后执行很慢很慢，完全跑不出结果。
关于这方面的内容，后面有机会我们再展开细说。
生态、工具、文档
近期知名的咨询机构沙利文发布了分布式数据库的情况，从这份简报中我们也能看出一些端倪；其中报告中提到国产数据库产品文档还需要进一步加强；比如产品特性、开发指南、优化手册、最佳实践等等。
如下内容摘自沙利文《2023年金融级分布式数据库市场报告》：
大家学习国产数据库这么久，应该对上面的说法是感同身受的；就拿分布式数据库来讲，TiDB的文档应该算是做的最好的，其次是OceanBase。如果要说传统集中式数据库，那么达梦的文档相对是不错的，其他厂家都还需要加强，甚至很多数据库厂商的文档，根本找不到。找一份文档，跟寻宝一样的困难。
除了文档就是配套的一些生态工具，分布式数据库厂家都是有自己的运维平台，外加一些命令行小工具。其他厂家可能就是全命令行，或者就是利用一些开源工具封装的。当然现在也有一些开源工具做的不错，比如国产的ByteBase CI/CD工具(希望能早点支持openGuass、MogDB)，我看就做的很不错，希望能支持更多的数据库类型，为国内数据库开发、运维人员提供一个更好的选择。
除了文档、工具本身，就是数据库生态建设了，我想所有厂商都意识到了这个问题，分布式数据库领域目前做的比较好的应该就是TiDB、OceanBase，大量的meetup活动、宣传以及行业最佳实践输出；传统行业数据库厂家相对来讲要低调的多，实际上我们应该再高调一些，毕竟酒香也怕巷子深。
