SQLite、MySQL和PostgreSQL 三种关系数据库哪个好？&>>&&>>&SQLite、MySQL和PostgreSQL 三种关系数据库哪个好？ 本站开启个人中心和积分模块，部分资源开启积分下载系统，如果还没有注册为会员，建议在右上角注册处进行注册为提升移动设备访问体验，本站升级为自适应前端，IE6-IE9浏览器或将存在兼容问题，请升级新版浏览器进行访问如果网盘的下载失效，请在对应的文章下评论告知，我会尽快进行处理想要自己的评论显示漂亮的头像吗？可以在个人中心的个人资料里进行头像设置
&6365& 文章评分
5 次，平均分
关系型数据库的使用已经有相当长的时间了。它们变得流行起来托了管理系统的福，关系模型被实现得相当的好，并且被证明是操作数据的好方法（特别是事务性强的应用）。在这篇DigitalOcean文章中，我们将尝试理解一些最常用、最流行的关系型数据库管理系统（RDBMS）的内核区别。我们将会探索最底层的区别——特性与功能，它们如何工作，在哪方面更出色，以帮助程序员选择合适的RDBMS。 目录：一、数据库管理系统 1、关系型数据库管理系统 2、关系与数据类型 3、重要的和流行的关系型数据库二、SQLite 1、SQLite支持的数据类型 2、SQLite的优势 3、SQLite的劣势 4、何时使用SQLite 5、何时不用SQLite三、MySQL 1、MySQL支持的数据类型 2、MySQL的优势 3、MySQL的劣势 4、何时使用MySQL 5、何时不用MySQL四、PostgreSQL 1、PostgreSQL支持的数据类型 2、PostgreSQL的优势 3、PostgreSQL的劣势 4、何时使用PostgreSQL 5、何时不用PostgreSQL&一、数据库管理系统 数据库是有组织地存储模型数据的空间，存储各种类型的信息（数据）。每个数据库，除了无模式型的，都有一个模型，提供数据的结构描述。数据库管理系统是管理数据库结构、大小和排序的应用（或库）。1、关系型数据库管理系统 关系型数据库系统实现了关系模型，并用它来处理数据。关系模型在表中将信息与字段关联起来（也就是schemas），从而存储数据。这种数据库管理系统需要结构（例如表）在存储数据之前被定义出来。有了表，每一列（字段）都存储一个不同类型（数据类型）的信息。数据库中的每个记录，都有自己唯一的key，作为属于某一表的一行，行中的每一个信息都对应了表中的一列——所有的关系一起，构成了关系模型。2、关系和数据类型 关系可以被看做是包含一系列共同表示被保持数据库以及相关信息的属性的数学集合. 这种类型的识别和采集方法可以让关系型数据库以它们自己的方式运作.在定义一个可以向其中插入数据的表时，每一个形成一条记录的元素（例如： 属性）都必须同定义的数据类型相匹配(例如：一个integer, 一个date 等等.). 不同的关系型数据库管理系统实现了不同的数据类型 -- 它们不总是能直接互相转换的.与限制的协作，就像我们之前已经介绍过的，在关系数据库的使用中是很普遍的。事实上，限制形成了关系的核心.3、重要和流行的关系型数据库 本文中，我们将会介绍三种主要而且重要的开源关系型数据库管理系统，是他们影响了应用开发世界。SQLite一个强大的嵌入式关系型数据库管理系统MySQL最流行的RDBMSPostgreSQL最先进SQL型开源objective-RDBMS&注: 开源应用总是可以自由使用的。大多数时候，复制工程（利用代码）创建新应用也是被允许的。如果你对DBMS感兴趣，你可以看看一些基于这些工程的分支项目，例如MariaDB。&二、SQLite SQLite是非凡的数据库，他可以进程在使用它的应用中。作为一个自包含、基于文件的数据库，SQLite提供了出色的工具集，可以处理所有类型的数据，没有什么限制，而且比起服务器运行的进程型服务器使用起来轻松许多。一个应用使用SQLite时，它的功能直接被集成在其中，应用会直接访问包含数据的文件（即SQLite数据库）,而不是通过一些端口（port, socket）来交互。感谢这种底层技术，这使SQLite变得非常快速和高效，并且十分强大。1、SQLite支持的数据类型NULLNULL值INTEGER有符号整数，按照设置用1、2、3、4、6或8字节存储REAL浮点数，使用8字节IEEE浮点数方式存储TEXT文本字符串，使用数据库编码存储（UTF-8, UTF-16BE 或 UTF-16LE）BLOB二进制大对象，怎么输入就怎么存储&2、SQLite 的优点 基于文件整个数据库都包含在磁盘上的一个文件中，因此它有很好的迁移性标准化尽管它看起来像个“简化版”的数据库，SQLite 确实支持 SQL。它略去了一些功能(RIGHT OUTER JOIN 和 FOR EACH STATEMENT)，但是，又同时增加了一些其他功能对开发乃至测试都很棒在绝大多数应用的开发阶段中，大部分人都非常需要解决方案能有并发的灵活性。SQLite 含有丰富功能基础，所能提供的超乎开发所需，并且简洁到只需一个文件和一个 C 链接库&3、SQLite的缺点没有用户管理高级数据库都能支持用户系统，例如，能管理数据库连接对数据库和表的访问权限。但由于 SQLite 产生的目的和本身性质（没有多用户并发的高层设计），它没有这个功能缺乏额外优化性能的灵活性仍然是从设计之初，SQLite 就不支持使用各种技巧来进行额外的性能优化。这个库容易配置，容易使用。既然它并不复杂，理论上就无法让它比现在更快，其实现在它已经很快了&4、什么时候要用 SQLite 嵌入式应用所有需要迁移性，不需要扩展的应用，例如，单用户的本地应用，移动应用和游戏代替磁盘访问在很多情况下，需要频繁直接读/写磁盘文件的应用，都很适合转为使用 SQLite ，可以得益于 SQLite 使用 SQL 带来的功能性和简洁性测试它能秒杀大部分专门针对应用业务逻辑（也就是应用的主要目的：能完成功能）的测试&5、什么时候不要用SQLite多用户应用如果你在开发的应用需要被多用户访问，而且这些用户都用同一个数据库，那么相比 SQLite 最好还是选择一个功能完整的关系型数据库（例如 MySQL）需要大面积写入数据的应用SQLite 的缺陷之一是它的写入操作。这个数据库同一时间只允许一个写操作，因此吞吐量有限&&三、MySQL MySQL 在所有大型数据库服务器中最流行的一个. 它的特性丰富，产品的开源性质使得其驱动了线上大量的网站和应用程序. 要入手 MySQL 相对简单，开发人员可以在互联网上面访问到大量有关这个数据库的信息.注意: 由于这个产品的普及性，大量的第三方应用、工具和集成库对于操作这个RDBCMS的方方面面大有帮助.Mysql没有尝试去实现SQL标准的全部，而是为用户提供了很多有用的功能. 作为一个独立的数据库服务器，应用程序同Mysql守护进程的交互，告诉它去访问数据库自身 -- 这一点不像 SQLite.1、MySQL支持的数据类型TINYINT一个非常小的整数SMALLINT一个小整数MEDIUMINT一个中间大小的整数INT or INTEGER一个正常大小的整数BIGINT一个大的整数FLOAT一个小的 (单精度) 浮点数，不能是无符号的那种DOUBLE, DOUBLE PRECISION, REAL一个正常大小 (双精度) 的浮点数，不能使无符号的那种DECIMAL, NUMERIC没有被包装的浮点数。不能使无符号的那种DATE一个日期DATETIME一个日期和时间的组合TIMESTAMP一个时间戳TIME一个时间YEAR一个用两位或者4位数字格式表示的年份(默认是4位)CHAR一个固定长度的字符串，存储时总是在其固定长度的空间里右对齐VARCHAR一个可变长度的字符串TINYBLOB, TINYTEXT一个BLOB或者TEXT列，最大长度255 (2^8 - 1)个字符BLOB, TEXT一个BLOB或者TEXT列，最大长度 6 - 1)个字符MEDIUMBLOB, MEDIUMTEXT一个BLOB或者TEXT列，最大长度 ^24 - 1)个字符LONGBLOB, LONGTEXT一个BLOB或者TEXT列，最大长度 (2^32 - 1) 个字符ENUM一个枚举类型SET一个集合&2、MySQL的优点容易使用安装MySQL非常容易。第三方库，包括可视化（也就是有GUI）的库让上手使用数据库非常简单功能丰富MySQL 支持大部分关系型数据库应该有的 SQL 功能——有些直接支持，有些间接支持安全MYSQL 有很多安全特性，其中有些相当高级灵活而强大MySQL 能处理很多数据，此外如有需要，它还能“适应”各种规模的数据快速放弃支持某些标准，让 MySQL 效率更高并能使用捷径，因此带来速度的提升&3、MySQL的缺点 已知的局限从设计之初，MySQL 就没打算做到全知全能，因此它有一些功能局限，无法满足某些顶尖水平应用的需求可靠性问题MySQL 对于某些功能的实现方式(例如，引用，事务，数据审核等) 使得它比其他一些关系型数据库略少了一些可靠性开发停滞尽管 MySQL 理论上仍是开源产品，也有人抱怨它诞生之后更新缓慢。然而，应该注意到有一些基于 MySQL 并完整集成的数据库（如 MariaDB），在标准的 MySQL 基础上带来了额外价值&4、何时使用 MySQL？分布式操作当你需要的比SQLite可以提供的更多时，把MySQL包括进你的部署栈，就像任何一个独立的数据库服务器，会带来大量的操作自由和一些先进的功能高安全性MySQL的安全功能，用一种简单的方式为数据访问（和使用）提供了可靠的保护Web网站 和 Web应用绝大多数的网站（和Web应用程序）可以忽视约束性地简单工作在MySQL上。这种灵活的和可扩展的工具是易于使用和易于管理的——这被证明非常有助于长期运行定制解决方案如果你工作在一个高度量身定制的解决方案上，MySQL能够很容易地尾随和执行你的规则，这要感谢其丰富的配置设置和操作模式&5、何时不用 MySQL？SQL 服从性因为 MySQL 没有[想要]实现 SQL 的全部标准，所以这个工具不完全符合SQL。如果你需要对这样的关系数据库管理系统进行整合，从MySQL进行切换是不容易的并发即使MySQL和一些存储引擎能够真地很好执行读取操作，但并发读写还是有问题的缺乏特色再次提及，根据数据库引擎的选择标准，MySQL会缺乏一定的特性，如全文搜索&&四、PostgreSQL PostgreSQL 是一个先进的，开放源代码的[对象]-关系型数据库管理系统，它的主要目标是实现标准和可扩展性. PostgreSQL, 或者说是 Postgres, 试图把对 ANSI/ISO SQL标准的采用与修正结合起来.对比其他的RDBMS, PostgreSQL以它对于对象-关系和或关系型数据库功能，比如对于可靠事务，例如原子性，一致性，隔离性和持久性（ACID）的完全支持，这些东西的高度需求和集合的支持，以示其独特性.由于强大的底层技术, Postgres对于高效的完成许多处理任务很有一手. 得益于其多版本并发控制 (MVCC)的实现，在没有读取锁的前提下也能达成并发, 这也同样确保了ACID的实施.PostgreSQL是高度可编程的, 因而可以使用被称作“存储过程”的自定义程序进行扩展. 这些功能可以被创建用来简化一个写重复、复杂并且常常需要数据库操作的任务的执行.虽然特性强大，但这个 DBMS并没有MySQL那么流行, 可还是有许多迷人的第三方工具和库被设计出来用于使得对PostgreSQL的操作简化. 如今通过许多操作系统默认的包管理器轻松的获取PostgreSQL已成为可能.1、PostgreSQL支持的数据类型bigint有符号的八位整数bigserial自增长的八位整数bit [(n)]固定长度的位串bit varying [(n)]可变长度的位串boolean逻辑布尔值(true/false)box在一个平面上的矩形框bytea二进制数据("位数组")character varying [(n)]可变长度的字符串character [(n)]固定长度的字符串cidrIPv4 或者 IPv6 网络地址circle平面上的一个圆date日历日期 ( 年月日)double precision双精度浮点数（8位）inetIPv4 或者 IPv6 主机地址integer有符号的四位整数interval [fields] [(p)]时间跨度line平面上的一个无限长的直线lseg平面上的一个线段macaddrMAC (媒体访问控制)地址money货币金额numeric [(p, s)]可选精度的精确数字path一个平面上的几何路径point一个平面上的几何点polygon一个平面上的闭合的几何路径real单精度浮点数(4 位)smallint有符号的两位整数serial自增长4位整数text可变长度字符创time [(p)] [without time zone]一天中的时间(无时区)time [(p)] with time zone一天中的时间，包含时区timestamp [(p)] [without time zone]日期和时间（没有时区）timestamp [(p)] with time zone日期和时间，包含时区tsquery文本搜索查询tsvector文本搜索文档txid_snapshot用户级事务ID快照uuid通用的唯一标识符xmlXML 数据&2、PostgreSQL的优点标准支持 SQL 的开源关系型数据库PostgreSQL 是一个开源的，免费的，同时非常强大的关系型数据管理系统强大的社区PostgreSQL 背后有热忱而经验丰富的社区，可以通过知识库和问答网站获取支持，全天候免费强大的第三方支持即使其本身功能十分强大，PostgreSQL 仍附带有许多强大的开源第三方工具来辅助系统的设计、管理和使用可扩展性可以用预先存储的流程来程序性扩展 PostgreSQL ，一个高级的关系型数据库理应如此面向对象PostgreSQL 不只是一个关系型数据库，还是一个面向对象数据库——支持嵌套，及一些其他功能3、PostgreSQL的缺点：性能对于简单而繁重的读取操作, 超过了 PostgreSQL 的杀伤力，可能会出现比同行（如MySQL）更低的性能普及按给出的该工具的性质，从普及度来说它还缺乏足够后台支撑，尽管有大量的部署——这可能会影响能够获得支持的容易程度托管由于上述因素的影响，要让主机或服务提供商提出使用PostgreSQL实例是很难的&4、何时使用PostgreSQL？ 数据完整性当可靠性和数据完整性是绝对必要而无需理由时，PostgreSQL是更好的选择复杂的自定义过程如果你需要你的数据库执行自定义过程，可扩展的PostgreSQL是更好的选择整合在将来，如果可能要把整个数据库系统迁移到另一个适当的解决方案（例如Oracle）中，PostgreSQL对于这种切换将是最兼容和易于操作的复杂的设计相比其他的开源和免费的 RDBMS（关系数据库管理系统）实现来说，对于复杂的数据库设计，PostgreSQL提供了大部分的功能和可能性，同时并没放弃其他有价值的地方&5、何时不用 PostgreSQL？速度如果你需要的只是快速的读取操作, PostgreSQL 不是为此而准备的工具简化体制除非你需要绝对的数据完整性，原子性，一致性，隔离性，耐久性，或复杂的设计，PostgreSQL 对简化体制来说是杀手复制除非你愿意花不少时间，精力和资源，否则对于那些缺乏数据库和系统管理经验的人来说，实现与MySQL的（主从）复制可能不容易&转自开源中国
&除特别注明外，本站所有文章均为原创，转载请注明出处来自
伤逝的安详网站是由系统与软件爱好者阿斯兰萨拉建立，旨在分享更多更好的软件、教程、资讯等内容。如果您有好的文章想在本站发布，欢迎注册后在个人中心进行投稿。
如果您觉得本站不错，请访问下面的链接，您每天的首次访问，我可以得到4分钱，仅是一个网页，不修改浏览器首页，举手之劳，希望您能支持
& 积分排行44610 积分3445 积分2735 积分2025 积分1590 积分赞助站长
友情链接站务合作如果您有站务合作方面的需求，请通过以下方式联系我。Email: (#换成@)mysql与postgresql比较（借鉴）
为了弄明白PostgreSQL和MySQL的差别，我搜索了关键字：MySQL vs PostgreSQL，并看了第一页的几个文章。以下是简单总结：
MySQL与PostgreSQL的区别
MySQL是应用开发者创建出来的DBMS；而PostgreSQL是由开发者创建出来的DBMS [1]。
换句话说，MySQL倾向于使用者的角度，回答的问题是 &你想解决的是什么问题&；而PostgreSQL倾向于理论角度，回答的问题是 &数据库应该如何来解决问题& [2]。
MySQL一般会将数据合法性验证交给客户；PostgreSQL在合法性难方面做得比较严格。比如MySQL里插入 && 这个时间时，会成功，但结果会是 &&；PostgreSQL不允许插入此值。
通常，PostgreSQL 被认为特性丰富，而MySQL被认为速度更快。但这个观点基本是在 MySQL 4.x / PostgreSQL 7.x 的事情，现在情况已经变了，PostgreSQL 在9.x版本速度上有了很大的改进，而MySQL特性也在增加[3]。
在架构上，MySQL分为两层：上层的SQL层和几个存储引擎（比如InnoDB，MyISAM）。PostgreSQL 只有一个存储引擎提供这两个功能。
这两个数据库都可以针对应用的情境被优化、定制，精确的说哪个性能更好很难。MySQL项目一开始焦点就在速度上，而PostgreSQL一开始焦点在特性和规范标准上。
可能是由于历史原因MySQL在开发者中更流行一些。至少我们上学时没听说过PostgreSQL，当时不是MS SQL Server就是MySQL，而MySQL是开源的。实事上PostgreSQL直到8.0才官方支持了Windows系统。
如果没有什么历史原因（比如系统已经基于MySQL多年了），或技术积累原因（同事中MySQL高手多），那么我觉得选择PostgreSQL不会有错。
有趣的是，我在Google上搜索 &switch postgresql to & 时，结果中第一页全是 &Switch to PostgreSQL from MySQL&，第二页终于有个是from PostgreSQL to MySQL，不过只有它一个，而且原因不是说PostgreSQL不好，而是因为作者MySQL经验多些[4]。
附录：简单测试
最后附上我自己对MySQL v5.5 和 PostgreSQL v9.1 在Mac OS，ML上的简单测试。MySQL是用brew安装的，PostgreSQL用的是Heroku提供的app绿色版本。因为都是默认安装，默认的配置，所以比较结果只是拿来参考。
| Modifiers
-------------------+--------------------------+-----------
| not null
created_at
| timestamp with time zone | not null
| character varying(40)
| not null
from_user_id
| not null
from_user_name
| character varying(40)
| not null
| character varying(256)
| not null
iso_language_code | character varying(8)
| not null
| character varying(64)
| not null
| character varying(170)
| not null
| character varying(40)
| not null
to_user_id
| not null
to_user_name
| character varying(40)
| not null
&tweets_tweet_test_pkey& PRIMARY KEY, btree (id)
测试数据为100w多行真实Twitter数据：
$ head -n4 out_pg.sql
INSERT INTO tweets_tweet_test VALUES (624513, ' 07:44:00+08', 'KevinPetrollini', , 'Kevin', '', 'zh', 'web', '给我的鞭子。', '', 0, '');
INSERT INTO tweets_tweet_test VALUES (597952, ' 18:23:54+08', 'mikaweixian', , 'M I K A. ', '', 'zh', 'Instagram', '唔知點解旅行返來日日都覺得好悶 ? 我重係不習慣一個人Oracle DBA（24）
去 IOE，MySQL 完胜 PostgreSQL
PostgreSQL
PostgreSQL官方宣称的是：“The world’s most advanced open source database”。most advanced我不知道是怎么定义的，因为PosgreSQL还是传统B+树索引的数据库，在一些场景下，比如全插入场景，其还是会比其他一些数据库要来得差很多，比如TokuDB，MongoDB。撇开这部分的因素，不得不承认PostgreSQL是最为强大的开源数据库，或许，但是Oracle依然才是最为强大的关系型数据库。PostgreSQL阵营一直标榜自己在优化器和Oracle可移植性方面的优势，我想这对比MySQL或许是成立的。然而，如果上述都成立的话，为什么PostgreSQL在装机量，流行度等指标上上远远地被后起之秀MySQL给超越了呢？全球前20大网站完全看不到PostgreSQL的身影呢？在写本篇文章的时候，我倏地想到了一个类似的问题，业界公认手机质量最好的Nokia，最终为什么会倒下？
PostgreSQL另一个痛点，我想很多人没有会意识到的，就是在在线事务（OLTP）方面的性能问题。PostgreSQL在功能方面或许是比较完整的，但是真的要进入到生产环节，看的不再是简单的功能，因为大部分用户都明白日常所使用的仅是数据库提供的20%功能。MySQL 5.7现在已经可以轻松达到50W QPS的性能，并支持通过NoSQL接口可以达到100W QPS，这是PostgreSQL为什么没有能在互联网时代站住脚跟的一个重要原因之一。在线事务对性能的要求之苛刻，是普通用户所无法感知的。
PostgreSQL最大的优势是在线分析的场景，因为其优化器对于Join的支持堪称全面，对于复杂查询有着良好的支持，从Oracle迁移到PostgreSQL的成本会比较低。基于PostgreSQL的GreenPlum也已经开源，因此PostgreSQL目前在这方便是较为领先的。
MySQL数据库官方的口号是：“&The world’s most popular open source database.”。对比PostgreSQL，这句话简直无法攻击，并且MySQL官方的目标也一直是成为最为流行的数据库。通过互联网浪潮，移动互联的时代，MySQL是真的做到了。
MySQL的优势是开源与开放性架构，使其拥有有着各种分支版本与存储引擎可供选择。除了官方的InnoDB存储引擎，还有TokuDB，Infobright引擎可在特定场合下进行使用。也正是因为MySQL的开源与开放，使得大量的开发人员加入到了MySQL的环抱。MySQL是一个非常成功的开源项目，可能很多人忽略了这个重要的因素。
MySQL被Oracle收购后表现的越来越好，一方面是功能越来越与Oracle数据库接近，很多时候给我的感觉就是开源的Oracle数据库，另一个重要的改进就是bug越来越少，甚至很多遗留了有近10年的bug也已一一修复。官方这样严谨的态度，使得MySQL逐渐站稳了并开始蚕食一部分的企业市场，世界500强的选择就是最好的证明。
MySQL在性能与流行度上的优势我不想再做过多的笔墨，因为这是任何人都无法回避的事实。MySQL数据库之前被PostgreSQL阵营攻击就是优化器，对于多表JOIN的性能以及不支持Hash Join。然而，很多人没有意识到，MySQL已经在5.6版本支持了MRR（Multi-Range Read），ICP（Index Condition Pushdown），BKA（Batched Key Access ）Join这些优化，多表的JOIN性能已经得到了很大幅度的提升。不能否则，MySQL依然不支持Hash
Join，但是这些优化的引入已经使得MySQL的Join性能提升到了一个新台阶。同时，在在线分析的领域，用户真的不关心使用Hash Join可以5分钟出报表，而是用MySQL需要8分钟，这些时间完全是可以容忍的。然在在线事务领域，0.1的时间都是所不能容忍的。因此，本人在这里呼吁，尝试升级MySQL到5.6，5.7版本，而不要依然停留在5.1或者5.5版本。
MySQL替换Oracle另一个被诟病的就是没有Oracle的透明网关(Transparent Gateway)功能，MySQL自带的Fedorate存储引擎支持MySQL数据库间的查询，不支持异构数据库之前的查询。然而，这个问题已经给MariaDB解决，用户只需要通过Connect存储引擎，就能达到类似Oracle透明网关的功能。
另外，还有用户提出MySQL不支持分区的全局索引，物化视图等，其实这些都可以通过变通的方法实现，这在我的书籍《MySQL技术内幕：InnoDB存储引擎》与《MySQL技术内幕：SQL编程》都有提及，而且也在网易、淘宝这样的互联网公司使用。
即使官方的MySQL无法满足你的需求，但是用户依然有InfoBright与TokuDB存储引擎的选择。InfoBright是列存的数据库引擎，非常适用于在线分析领域，这点连PostgreSQL都无法进行匹敌。TokuDB是一种类似LSM数据结构的数据引擎，在大并发的插入生产环境下，其对比各种传统数据库都有着显著的优势，即使对比PostgreSQL与Oracle数据库本身。总之，MySQL能够在各种维度满足用户对于数据库的各种需求。
PosgreSQL与MySQL对比，最为关键的是整个人才的储备。看看中国的互联网公司基本都已将MySQL数据库作为标配，而PostgreSQL甚至连备胎都无法入选。MySQL在互联网行业积累了大量的高可用架构，分布式架构与灾备经验，但是PostgreSQL几乎为0。再看看图书市场，PostgreSQL凤毛菱角，而MySQL则有很好的书籍供DBA，开发人员，架构师等学习。然即使如此，MySQL离Oracle数据库本身的积累还有很长的路要走。
去IOE最早是由淘宝提出，旨在去除IT架构中的IBM小型机，Oracle数据库，EMC存储。去IE是比较简单的事情，因为这仅是硬件的替换。另外，X86技术也越来越成熟，稳定性与小机的差距不断缩小。然而去Oracle数据库才是淘宝去IOE的难点与精华所在。整个去Oracle历时3，4年的时间。其中伴随着功能内部工程师的质疑，大量Oracle人才的流失，但最终已经证明了MySQL数据库替代Oracle的可行性。
笔者高兴的是传统企业也开始有这样的“觉悟”开始逐步进行去IOE的尝试，不管这种尝试是主动还是被动，但都是值得尊敬的行为。原因在于去Oracle数据库这件事情并不那么简单。数据库是传统企业最为核心的资产，任何损失都是不可接受的。而去年银监会的39号文件也坚定了传统企业的去IOE决心。
去IOE风潮显现，一大帮的公司开始进入到这个领域，希望借助这阵风来大赚一笔。这点本无可非议，市场与技术相辅相成。然而，有一个非常不好的现象是，很多公司是为了迎合某些领导的需要，而不是真正的为传统企业构建面向互联网+的安全可控的技术架构。而这其中有着一些不为人知的因素。
首当其冲的是领导们的绩效，传统企业做事，以绩效为导向，这与互联网行业并无不同。但是互联网行业有着技术积累，而且对于技术的选型与转型有着相当的耐心，从淘宝去Oracle用了3，4年就可以看出。而目前摆在传统企业领导面前的现实却是，39号文件要求各银行业金融机构对安全可控信息技术的应用以不低于15％的比例逐年增加，直至2019年达到不低于75％的总体占比。
遇到一些传统企业的朋友，领导要求他们用PostgreSQL替换Oracle数据库，原因在于这是“最快”的替换Oracle成本，但是他们站在IT从业人员的角度来看这件事是不对的，有种敢怒不敢言。当然，这其中也有部分商业公司在其中推动的关系。但是明白人心里都知道，PostgreSQL国内从业人员寥寥，之前在中国没有大规模的使用经验与架构设计，大多停留在找个文档折腾下的水平上。所谓“最快”的替换方案仅是因为不用进行存储过程的移植，如果只是这样使用PostgreSQL，那么仅是应付上层的文件，而没有真正领会到文件的精神。更有商业公司号称有PostgreSQL的专家，然而非常经不起推敲，玩过GreenPlum的就是PostgreSQL专家？而且GreenPlum也仅做研究性质的用途？与专家交流后发现其对锁与并发，高可用这块的掌握更是让人触目惊心。
所以笔者一再和身边的朋友说，去IOE不是一件一蹴而就的事情，需要给MySQL时间，否则这件好事情会像着另一个方向而发展，甚至重复当年年Sybase替换Oracle的事件发生。但是好消息是这次的领导们终于开始认识到互联网的重要性，理解了安全可控对于一个国家的重要性，而互联网公司的成熟经验具有很好的借鉴意义。
MySQL数据库早已不是原来的迷你数据库，其在功能性与性能方面都已经大幅提升，随着SSD的崛起，MySQL数据库已经完全可以替换Oracle数据，而PostgreSQL还需要很长的路要走。但市场是开放的，就像Oracle称雄的年代，还有DB2，Sybase这样的数据库与之一较长短。我相信互联网时代，依然是百花齐放的年代，没有谁可以一直占领优势，即便是MySQL也没有这个能力。
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：5042次
排名：千里之外
原创：21篇
转载：15篇
(1)(1)(1)(1)(10)(2)(4)(6)(7)(1)(2)