因为“自研数据库”这个词比较敏感，几乎所有的国产数据库厂商都号称自己是自研的，所以今天的文章可能会有些争议。其实我眼中的“自研国产数据库”是指数据库核心代码走自主发展道路的数据库产品，可能最初某些数据库产品最初参考了某些开源数据库的设计思想，甚至使用或者参考了开源数据库的代码，但是公司的核心研发人员已经总体上掌握了代码，并且对这些代码进行改写，数据库产品已经脱离开源社区独立发展，今后内核升级不再跟随开源数据库的核心，那么就可以将此数据库归类为自研数据库。
自研并不等同于每一行代码都是自己写的，我不太认同一些国产数据库厂商所宣称的每一行代码都是自己写的，因为这种做法太浪费有限的 资源。只要不违反开源协议，合法使用开源代码，用于自己的产品，那么就没什么可被诟病的。即使每一行代码都是自己敲下的也不排除某些代码是利用开源代码或者利用前人留下的代码库来构建的，真的没必要去纠结这些字眼。目前大家比较纠结“自研”这个字眼，很大程度是因为相关政策制定得不够合理，为了内卷，大家都非要违心地强调完全自研，这种情况反而让某些用户很反感。
国测其实是一个检验数据库自研比例的炼金石，特别是今年的第二期。其代码扫描工具会针对性地对核心代码的业务逻辑进行分析，并评估出自主可控的分数。只有超过一定分数才认为符合安可要求。根据这个原则判断，只要通过了最新一期国测的产品，其团队对代码的掌握程度大体上还是靠谱的。关于国测的一些细节，不方便在公众号上描述，今年已经有四十多个数据库产品参加了国测，有兴趣的朋友可以去咨询参加过的朋友吧。
基于上面的规则，如果某个数据库产品虽然脱胎于开源代码，但是已经脱离开源社区代码独立发展其核心代码，我们也认可它们是自研数据库。因此如果我今后再次重写这个话题，可能清单会越来越长。因为我已经看到不少没有在我今天所写的清单里的数据库产品，已经开始脱离开源社区的版本独立发展了。
另外一句话我要先说一下，今天我只是举例了一些产品，并没有涵盖所有的自研数据库产品，如果贵司的产品没有在我介绍之列，请多多体谅。
达梦DM8是被大多数人认可的自研数据库，代码自主率很高。2013年编者与达梦核心研发团队交流的时候，他们告知DM7的代码被他们进行了新一轮的重构，目前代码的自主率已经相当高了。有外界传闻说达梦当年购买了Oracle 9i的代码，并在此基础上研发了现在的DM8/DM DSC/DM DPC等一系列的数据库产品。对此我觉得不大靠谱，根据我的分析，DM8数据库行存的存储结构与Oracle 9i采用的HEAP结构完全不同，是类似于MySQL InnoDB的B-TREE结构。同时DM 8的UNDO也没有采用Oracle的CR BLOCK结构，而是采用基于行数据库的UNDO。在DM DSC中也没有类似Oracle PI BLOCK的结构。达梦数据库仅仅是在SQL引擎上与Oracle保持了高度的兼容性，并针对Oracle的各种特性做了兼容性的学习，但是存储引擎是完全不同的。对数据库技术有比较深入理解的朋友都清楚，不同存储架构的数据库产品不可能来源于相同的RDBMS核心代码。
OceanBase是除了达梦之外最无争议的自研国产数据库。OceanBase早期是不支持SQL的，专门为了淘宝部分场景设计的专用数据库，参考了谷歌的模型，不过是完全自主研发的。在目前的OceanBase 主流版本中（3.x,4.x），有MySQL兼容租户和Oracle兼容租户（开源版本只有MySQL兼容租户）。虽然MySQL兼容租户支持MySQL的 应用和客户端之间连接，不过其核心代码，特别是SQL引擎都没有采用拿来主义。OceanBase的SQL引擎虽然兼容MySQL但是是完全重构的，因此与MySQL 5.7/8.0等版本在SQL语法上并不是完全兼容的，有时候可能会遇到一些不兼容的BUG。
TiDB是另外一个容易被误解的自研数据库，虽然TiDB中使用了大量的开源代码和组件，不过TiDB的核心都是自研的。SQL引擎和OceanBase一样，都是网络协议兼容，实际上TiDB的SQL引擎是go语言写的，和MySQL的C++完全不同。
另外一个争议比较多的数据库是GaussDB和openGauss，GaussDB的核心与开源的PostgreSQL 9.x有渊源，不过华为首先将代码由C语言改写为C++,然后在此基础上研发了GaussDB。虽然说很多代码只是做了简单的迁移，不过这一步走出说明了GaussDB今后会完全脱离PostgreSQL开源生态。从GaussDB的基于PG的版本来看，GaussDB开始研发的时间是很早的，至少是十多年前。虽然今后PostgreSQL开源代码还能够给GaussDB一些启示和参考，不过数据库产品是完全走向了脱离社区的自研道路，因此我们也可以将其列入自研的行列。
神舟通用OSCAR数据库虽然最初是在PostgreSQL 的基础上研发的，不过其存储引擎已经完全改写，采用了类似Oracle的段页式存储结构，没有沿用PostgreSQL的ASTORE。在SQL引擎方面，也做了大量的Oracle数据库兼容改造，自研比例也是相当高的,而且也已经无法回归到社区版了。
YashanDB也是一款自研数据库产品，其特点是与Oracle RAC的兼容度较高。为了对标Oracle RAC，YashanDB在底层存储引擎上做了较大的优化，实现了类似Oracle的一致性读和PI BLOCK。其实崖山的核心研发团队来自于当年的GaussDB-T，这也难怪他们能够在短短的几年时间里自研出一款数据库产品来。
不少朋友在诟病国产数据库套壳，当然我也能尊重他们的看法。自研数据库时不去参考前人的成果，闭门造车是比套壳更不好的事情，能够站在巨人的肩膀上发展自研的产品也是值得尊重的。著名的SQL SERVER数据库，如果没有当年微软和SYBASE合作，拿到了SYBASE的源码，可能也不一定会有今天的辉煌。既然你能为套壳的SQL SERVER喝彩，又为啥不能认可国产数据库呢？
我觉得历史走到今天的位置，质疑国产数据库的人，反对国产数据库的人，不愿意融入国产数据库世界的人，都应该反思一下了。既然你还在吃数据库这碗饭，后面怎么去发展自己呢？如果执念能解决一切问题，这个世界就完全不同了。前两年一个德国企业和我探讨去O的事情的时候，我就明白了，这个世界已经变了。
全文完，希望可以帮到正在阅读的你，如果觉得有帮助，可以分享给你身边的朋友，同事，你关心谁就分享给谁，一起学习共同进步~~~
欢迎关注我的公众号【JiekeXu DBA之路】，一起学习新知识！
分享几个数据库备份脚本
一文搞懂 Oracle 统计信息
我的 Oracle ACE 心路历程
MOP 系列|MOP 三种主流数据库索引简介
Oracle 主流版本不同架构下的静默安装指南
关机重启导致 ASM 磁盘丢失数据库无法启动
Oracle SQL 性能分析(SPA)原理与实战演练
Oracle 11g 升级到 19c 需要关注的几个问题
Windows 10 环境下 MySQL 8.0.33 安装指南
SQL 大全（四）|数据库迁移升级时常用 SQL 语句
OGG|使用 OGG19c 迁移 Oracle11g 到 19C(第二版)
Oracle 大数据量导出工具——sqluldr2 的安装与使用
从国产数据库调研报告中你都能了解哪些信息及我的总结建议
使用数据泵利用 rowid 分片导出导入 lob 大表及最佳实践
在归档模式下直接 rm dbf 数据文件并重启数据库还有救吗？
——————————————————————————
公众号：JiekeXu DBA之路
墨天轮：https://www.modb.pro/u/4347
CSDN ：https://blog.csdn.net/JiekeXu
ITPUB：https://blog.itpub.net/69968215
腾讯云：https://cloud.tencent.com/developer/user/5645107
————————————————————————
