深度对比：PostgreSQL与MySQL的核心差异及选型指南

开发者必须知道的开源资讯网页 OSCHINA - 开源 × AI · 开发者生态社区

在开源关系型数据库领域，PostgreSQL（简称Pgsql）与MySQL无疑是两大主流选择。前者以“功能全面、扩展性强”著称，后者以“轻量高效、易于运维”立足，二者在技术架构、功能支持、性能表现上存在显著差异，适配不同的业务场景。无论是互联网创业公司的高频业务，还是企业级复杂数据处理需求，选型决策都直接影响系统稳定性、扩展性与运维成本。

一、前置认知：两大数据库的核心定位与发展历程

1.1 MySQL的定位与发展

MySQL诞生于1995年，最初由MySQL AB公司开发，后经Sun收购，最终被Oracle纳入麾下。其设计理念以“轻量、高效、易用”为核心，聚焦于互联网场景的高并发读写需求，凭借简洁的架构、较低的资源占用和成熟的生态，迅速成为互联网行业的首选开源数据库。

MySQL的核心优势在于对InnoDB引擎的优化，支持行级锁、事务ACID特性和主从复制，能较好适配中小规模数据量与高并发场景。目前主流版本为8.0，修复了5.7版本的诸多缺陷，增强了安全性、JSON支持和并行查询能力，但整体架构仍延续了“简洁优先”的思路，避免过度复杂的功能设计。

1.2 PostgreSQL的定位与发展

PostgreSQL起源于1986年的POSTGRES项目，由加州大学伯克利分校开发，是开源数据库中历史最悠久、功能最全面的产品之一。其设计理念是“功能完备、标准兼容、高度可扩展”，致力于提供企业级数据库的所有能力，同时保持开源自由的特性。

PostgreSQL支持几乎所有SQL标准，提供丰富的高级功能（如复杂数据类型、自定义函数、存储过程、事务隔离级别、地理信息处理等），架构设计更注重数据一致性与扩展性。目前主流版本为16，进一步优化了性能、并行查询和云原生适配能力，在企业级复杂业务、数据分析场景中优势显著。

二、核心差异：技术特性全方位对比

2.1 数据类型支持

数据类型是数据库适配业务场景的基础，二者在基础类型支持上差异不大，但Pgsql在复杂数据类型和自定义类型上优势明显。

2.1.1 MySQL数据类型特点

MySQL支持常见的基础数据类型（int、varchar、datetime、decimal等），同时提供有限的复杂类型支持：

JSON类型：MySQL 5.7及以上版本支持JSON类型，但仅提供基础的存储与查询能力，不支持JSONB（二进制JSON）的高效索引，复杂JSON查询性能较差。
空间类型：支持简单的空间类型（如POINT、LINESTRING），依赖Spatial扩展，但功能简陋，无法满足复杂地理信息处理需求。
自定义类型：仅支持通过ENUM、SET实现简单的枚举类型，不支持自定义复杂数据类型和域（Domain）。

实操案例：某电商平台需存储商品的多维度属性（如颜色、尺寸、材质，不同商品属性差异较大），采用MySQL JSON类型存储。当需要查询“红色、尺寸XL的服装商品”时，需通过JSON_EXTRACT函数解析，且无法利用索引，查询耗时达数百毫秒，随着数据量增长（超过100万条），查询性能急剧下降。

2.1.2 PostgreSQL数据类型特点

Pgsql不仅支持所有基础数据类型，还提供丰富的复杂类型与自定义能力，覆盖更多业务场景：

JSON与JSONB：原生支持JSON和JSONB类型，JSONB将JSON数据以二进制形式存储，支持GIN、GiST索引，复杂JSON查询性能远超MySQL。例如，对JSONB字段创建GIN索引后，多条件JSON查询耗时可降低至毫秒级。
高级数据类型：支持数组（如int[]、varchar[]）、范围类型（如int4range、daterange）、复合类型（类似结构体）、域（Domain，可自定义约束的类型）等。例如，用范围类型存储“订单有效期”（daterange('2026-01-01', '2026-01-31')），可直接通过范围函数查询有效期内的订单，无需复杂条件判断。
地理信息类型：通过PostGIS扩展提供强大的地理信息处理能力，支持点、线、面、多边形等复杂空间类型，以及空间索引、距离计算、叠加分析等功能，是地理信息系统（GIS）的首选开源数据库。

实操案例：某外卖平台需实现“就近派单”功能，存储商家和骑手的实时位置信息。采用PostgreSQL+PostGIS扩展，将位置存储为POINT类型，创建GiST空间索引。查询“距离用户1公里内的商家”时，通过ST_DWithin函数结合索引，查询耗时仅10毫秒左右，且支持复杂的区域筛选、路径规划等功能，完全满足业务需求。

2.2 事务与并发控制

事务一致性与并发控制能力直接影响数据库在高并发场景下的稳定性，二者均支持ACID事务，但实现机制与优化方向不同。

2.2.1 MySQL的事务与并发控制

MySQL的事务支持依赖存储引擎，InnoDB引擎是目前唯一支持ACID事务的引擎，其并发控制机制如下：

隔离级别：支持读未提交（Read Uncommitted）、读已提交（Read Committed）、可重复读（Repeatable Read，默认）、串行化（Serializable）四种隔离级别。默认的可重复读级别通过MVCC（多版本并发控制）实现，避免了幻读问题，但在某些场景下可能出现数据一致性问题。
锁机制：支持行级锁和表级锁，行级锁基于索引实现，若查询未命中索引则降级为表级锁，容易引发锁冲突。例如，在高并发写入场景中，若多个事务同时操作同一表的非索引字段，会触发表锁，导致写入阻塞。
并发性能：针对高并发读写场景优化较好，InnoDB的缓冲池（Buffer Pool）能高效缓存数据与索引，适合短事务、高频读写的互联网业务，但长事务场景下容易出现锁等待、MVCC版本膨胀问题。

实操案例：某社交APP的用户点赞功能，采用MySQL InnoDB存储点赞记录。由于点赞操作是高频短事务，通过合理设计索引（用户ID+内容ID），行级锁冲突较少，MySQL能支撑每秒数万次的点赞写入，性能稳定。但当出现批量统计点赞数的长事务时，会导致短事务锁等待时间增加，点赞接口响应延迟从10ms升至50ms以上。

2.2.2 PostgreSQL的事务与并发控制

Pgsql全引擎支持ACID事务，并发控制机制更成熟，适配复杂事务场景：

隔离级别：支持与MySQL相同的四种隔离级别，默认隔离级别为读已提交（Read Committed），同时提供“可串行化快照隔离”（Serializable Snapshot Isolation，SSI），能在保证完全串行化的同时，避免传统串行化级别的性能损耗，适合对数据一致性要求极高的场景（如金融交易）。
锁机制：提供更精细的锁粒度，包括行级锁、表级锁、页级锁，同时支持意向锁、共享锁、排他锁等多种锁类型，能有效减少锁冲突。例如，Pgsql的行级锁不依赖索引，即使查询未命中索引，也不会降级为表级锁，仅锁定符合条件的行。
并发性能：MVCC实现更高效，长事务场景下版本管理更优秀，不易出现版本膨胀；同时支持并行查询、并行索引创建等功能，在复杂查询与长事务并发场景下性能优于MySQL，但短事务高频读写场景下，性能略低于MySQL（主要因缓冲池优化侧重不同）。

实操案例：某银行的转账业务系统，采用PostgreSQL存储交易记录。转账业务涉及多表关联、长事务操作，且对数据一致性要求极高。通过设置SSI隔离级别，确保转账过程中数据无歧义，同时Pgsql的锁机制能避免长事务阻塞其他业务，支撑每秒数千笔转账交易，零数据一致性问题。

2.3 索引机制

索引是提升查询性能的核心，二者均支持基础索引类型，但Pgsql的索引功能更丰富，适配更多查询场景。

2.3.1 MySQL的索引机制

MySQL的索引主要依赖InnoDB引擎的B+树索引，功能相对基础：

支持索引类型：主要支持B+树索引（主键索引、二级索引）、哈希索引（仅Memory引擎支持，InnoDB自适应哈希索引为隐式创建，不可手动配置）、全文索引（基于ngram分词，功能简陋）。
索引优化：针对B+树索引优化较好，支持覆盖索引、联合索引、前缀索引，能有效提升高频查询性能。但不支持部分高级索引功能，如部分索引、表达式索引、GiST/GIN索引等。
索引维护：索引创建、删除过程会阻塞读写操作（MySQL 8.0支持并行索引创建，但仍有一定性能影响），高并发场景下索引维护成本较高。

实操案例：某电商平台的订单查询功能，通过MySQL联合索引（用户ID+订单创建时间）优化“查询用户近3个月订单”的场景，查询耗时从数百毫秒降至20ms左右。但当需要查询“用户近3个月金额大于1000元的订单”时，无法通过索引直接过滤金额条件，需回表查询，性能提升有限。

2.3.2 PostgreSQL的索引机制

Pgsql支持多种索引类型，能适配复杂查询场景，索引功能更全面：

基础索引类型：支持B+树索引（默认）、哈希索引，B+树索引优化更成熟，支持部分索引（仅对表中部分数据创建索引，减少索引体积）、表达式索引（基于字段表达式创建索引，如lower(username)）、函数索引等。
高级索引类型：支持GIN（通用倒排索引）、GiST（通用搜索树）、SP-GiST、BRIN等索引。GIN索引适合JSONB、数组、全文检索场景；GiST适合空间数据、模糊匹配场景；BRIN索引适合时序数据（如日志、监控数据），能大幅减少索引存储空间。
索引维护：支持并发索引创建（CREATE INDEX CONCURRENTLY），创建索引过程中不阻塞表的读写操作，适合高并发生产环境；同时支持索引重建、碎片整理等操作，维护更灵活。

实操案例：某日志分析平台存储海量应用日志，每条日志包含多个标签（数组类型，如['error', 'login', 'mobile']）。采用PostgreSQL的GIN索引对标签字段建立索引，查询“包含error标签且来自mobile端的日志”时，能直接通过GIN索引过滤数据，查询耗时仅50ms，相比MySQL的全表扫描（耗时数秒）性能提升显著。同时，通过BRIN索引对日志时间字段优化，索引体积仅为B+树索引的1/10。

2.4 扩展性与定制化

扩展性是数据库适配业务增长与个性化需求的关键，二者在扩展性设计上差异较大。

2.4.1 MySQL的扩展性

MySQL的扩展性相对有限，主要依赖第三方工具与插件，核心架构扩展性较弱：

插件支持：支持简单的插件扩展（如全文检索插件、审计插件），但插件生态相对薄弱，高级功能插件较少，且插件对性能影响较大。
集群扩展：原生不支持集群功能，需通过第三方工具实现主从复制、读写分离、分库分表（如MyCat、Sharding-JDBC）。主从复制基于binlog实现，延迟相对较高（默认异步复制，同步复制性能差），集群运维复杂度较高。
定制化能力：核心代码封闭性较强，定制化开发难度大，企业难以根据自身需求修改数据库内核功能。

实操案例：某电商平台业务增长迅速，MySQL单库数据量突破1000万，查询性能下降。通过Sharding-JDBC实现分库分表（按用户ID哈希分片），同时搭建一主多从架构实现读写分离。但分库分表后，跨分片查询、事务一致性维护难度增加，且主从复制延迟导致部分读请求获取旧数据，需额外开发数据同步补偿机制。

2.4.2 PostgreSQL的扩展性

Pgsql以“高度可扩展”为核心设计理念，支持多种扩展方式，适配复杂业务场景：

扩展生态：拥有丰富的官方与第三方扩展，如PostGIS（地理信息）、pg_stat_statements（性能监控）、pgcrypto（加密）、pg_buffercache（缓冲池监控）等，能快速扩展数据库功能，且扩展对性能影响较小。
集群扩展：原生支持流复制（主从复制），延迟极低（毫秒级），同时支持逻辑复制（基于事务日志的逻辑数据同步），能实现跨版本、跨库的数据同步；通过第三方工具（如Patroni、PgBouncer）可实现高可用集群、读写分离、自动故障转移，运维复杂度低于MySQL集群。
定制化能力：支持自定义函数（PL/pgSQL、Python、Java等多种语言）、存储过程、触发器、操作符等，用户可根据业务需求扩展数据库功能；内核代码开放性强，定制化开发难度低于MySQL。

实操案例：某政务平台需存储海量地理信息数据（如城市道路、社区边界），并支持复杂的空间分析功能。通过PostgreSQL+PostGIS扩展快速实现核心功能，同时搭建主从流复制集群，主库负责写入，从库负责查询与分析，集群延迟控制在10ms以内。通过自定义PL/pgSQL函数实现个性化数据校验逻辑，无需修改应用代码，大幅提升开发效率。

2.5 SQL标准兼容性

SQL标准兼容性直接影响应用迁移成本与开发效率，Pgsql在兼容性上显著优于MySQL。

MySQL：不完全支持SQL标准，存在较多自定义语法与特性。例如，不支持WITH RECURSIVE（递归查询）、MERGE语句、CHECK约束（语法支持但无实际效果）、窗口函数（MySQL 8.0才支持部分窗口函数）等。这导致应用迁移时需修改大量SQL语句，且开发时需适配MySQL的特有语法。
PostgreSQL：高度兼容SQL标准（SQL:2016），支持几乎所有SQL标准特性，包括递归查询、MERGE语句、CHECK约束、窗口函数、公用表表达式（CTE）、数组操作、正则表达式等。开发时可遵循标准SQL语法，应用迁移成本低，且能无缝对接BI工具、ETL工具等第三方组件。

实操案例：某企业级BI系统需对接多个数据库，统计各业务线数据。最初采用MySQL存储数据，由于MySQL不支持复杂窗口函数与递归查询，统计SQL需拆分多个步骤实现，且无法直接对接BI工具的标准SQL查询功能。迁移至PostgreSQL后，直接使用标准SQL编写递归查询与窗口函数，统计逻辑简化60%，且能无缝对接BI工具，无需额外适配。

三、优缺点深度解析：结合场景谈优劣

3.1 MySQL的优缺点

3.1.1 核心优点

轻量高效，资源占用低：MySQL架构简洁，对CPU、内存、磁盘资源占用较低，在低配服务器（如2核4G虚拟机）上也能稳定运行，适合中小规模业务与创业公司。
高并发读写性能优异：针对互联网高频短事务场景优化充分，InnoDB引擎的缓冲池与行级锁能支撑每秒数万次的读写操作，是电商、社交、资讯等互联网业务的首选。
易于部署与运维：安装配置简单，官方文档完善，运维工具成熟（如phpMyAdmin、Navicat、MySQL Workbench），普通运维人员即可快速上手；故障排查难度低，社区资源丰富，问题解决方案易获取。
生态成熟，兼容性广：支持绝大多数编程语言与开发框架（Java、Python、PHP、Go等），适配各类云服务与容器化部署，第三方工具（如备份工具、监控工具）丰富。

3.1.2 主要缺点

功能相对薄弱：缺乏复杂数据类型、高级索引、高级SQL特性支持，无法满足企业级复杂业务与数据分析需求。
数据一致性保障有限：默认隔离级别下存在潜在数据一致性问题，长事务场景下性能与稳定性不足，不适合金融、政务等对数据一致性要求极高的场景。
扩展性差：原生不支持集群功能，分库分表、高可用集群需依赖第三方工具，运维复杂度高，且跨分片查询、事务一致性维护难度大。
开源协议风险：被Oracle收购后，存在闭源风险，社区版本与商业版本功能差异逐渐扩大，企业级功能（如高级安全特性、集群管理）需付费使用。（这也是为什么很多企业和个人开发者开始转用Pgsql的原因）

3.2 PostgreSQL的优缺点

3.2.1 核心优点

功能全面，特性丰富：支持复杂数据类型、高级索引、标准SQL特性、自定义函数、地理信息处理等，能满足企业级复杂业务、数据分析、GIS等多样化需求。
数据一致性与稳定性强：成熟的事务机制与并发控制，支持SSI隔离级别，长事务场景下性能稳定，数据一致性保障能力强，适合金融、政务、医疗等核心业务。
高度可扩展：丰富的扩展生态与定制化能力，原生支持流复制，集群扩展与运维复杂度低于MySQL，能适配业务从中小规模到大规模的增长需求。
开源自由，无商业风险：采用PostgreSQL许可证，完全开源自由，无闭源风险，企业可免费使用所有功能，且能基于内核进行定制化开发。

3.2.2 主要缺点

资源消耗较高：架构复杂，对CPU、内存资源占用高于MySQL，在低配服务器上性能表现不佳，适合中高配服务器部署。
短事务高频读写性能略逊：针对互联网高频短事务场景优化不足，短事务并发写入性能比MySQL低10%-20%，需通过优化配置提升性能。
运维门槛高：功能复杂导致运维难度增加，高级特性（如扩展配置、集群优化、性能调优）需专业运维人员操作，社区资源虽丰富，但针对性问题解决方案获取难度高于MySQL。
部分场景兼容性不足：部分互联网开源项目（如早期的WordPress、Discuz）对PostgreSQL适配不佳，需修改代码才能兼容。

四、市场使用情况：行业分布与大厂实践

4.1 市场份额与趋势

DB-Engines 2026年1月的排名：DB-Engines Ranking - popularity ranking of database management systems

这张图表展示了全球数据库管理系统的月度流行度排名，我们先聚焦红框标注的前四名核心玩家，再延伸解读整体趋势：

🔹 前四名（红框内）核心数据拆解

排名	DBMS	数据库类型	2026 年 1 月分数	环比（Dec 2025）	同比（Jan 2025）	趋势解读
1	Oracle	关系型 + 多模型	1237.34	+2.94（微涨）	-21.42（下滑）	连续 1 年稳居第 1，短期微涨但长期略有承压，凭借企业级生态和多模型能力维持统治力
2	MySQL	关系型 + 多模型	867.52	-0.97（微跌）	-130.63（大跌）	连续 1 年第 2，开源属性仍受青睐，但同比跌幅较大，或受 PostgreSQL 等竞品冲击
3	Microsoft SQL Server	关系型 + 多模型	706.26	-16.26（明显跌）	-92.30（大跌）	绑定微软生态但增长乏力，受云原生、开源数据库双重挤压，分数持续下滑
4	PostgreSQL	关系型 + 多模型	666.27	+6.84（显著涨）	+2.86（微涨）	前四里唯一同比 + 环比双涨的数据库，开源 + 多模型 + 云原生适配能力突出，增长势头强劲

🔹 整体市场格局洞察

头部稳固但内部分化传统四大关系型数据库仍占据前四，但 PostgreSQL 逆势增长，Oracle、MySQL、SQL Server 则呈现微涨或下滑，这也是没办法的，类似这种专注于数据库的团队或者公司，唯有做出商业化才有的赚钱，包括所有国产操作系统和数据库也是一样的路。
多模型成为标配前四名均标注 “Multi-model（多模型）”，说明主流数据库已从单一关系型转向支持文档、键值等多模型，以应对复杂业务场景（如电商、物联网）的需求。
开源 vs 商业的博弈开源数据库（MySQL、PostgreSQL）的增长势头，与商业数据库（SQL Server）的下滑形成鲜明对比，体现市场对 “开源 + 云原生 + 灵活部署” 的偏好。
场景化数据库崛起非传统数据库如 MongoDB（NoSQL 多模型，第 5）、Snowflake（云数据仓库，第 6）、Databricks（湖仓一体，第 8）的分数环比上涨，说明云原生、垂直场景的数据库正在快速抢占市场。

4.2 行业分布与大厂实践

4.2.1 MySQL的行业应用

MySQL主要主导互联网行业，在电商、社交、资讯、游戏等高频读写场景应用广泛，典型大厂实践包括：

Facebook（Meta）：早期核心业务采用MySQL，通过自定义优化实现大规模集群部署，支撑数十亿用户的社交数据存储与读写。
阿里巴巴：淘宝、天猫等电商业务早期采用MySQL，后基于MySQL研发OceanBase数据库，但仍有大量业务保留MySQL部署。
腾讯：微信、QQ等社交业务的部分模块采用MySQL，通过主从复制与分库分表实现高可用与高并发。
字节跳动：抖音、今日头条等产品的部分业务采用MySQL，适配高频短事务场景，结合自研工具实现集群管理。

行业特点：互联网行业对性能、易用性要求高于功能完整性，MySQL的轻量高效与成熟生态完美适配这类需求，是中小互联网公司的入门首选。

4.2.2 PostgreSQL的行业应用

PostgreSQL主要应用于企业级业务、数据分析、GIS、金融等场景，典型大厂实践包括：

阿里云：AnalyticDB for PostgreSQL基于PostgreSQL研发，面向企业级数据分析场景，服务于政务、金融、零售等行业客户。
微软：Azure云平台提供PostgreSQL托管服务，同时内部部分业务采用PostgreSQL存储复杂数据与分析任务。
华为：政务云、金融云业务中大量采用PostgreSQL，依托其数据一致性与扩展性，支撑核心业务系统。
高德地图、百度地图：地理信息数据存储与分析采用PostgreSQL+PostGIS扩展，实现地图渲染、路径规划、位置检索等功能。

行业特点：企业级业务、金融、政务、GIS等场景对功能完整性、数据一致性要求极高，PostgreSQL的全面功能与稳定性能满足这类需求，近年来在互联网大厂的数据分析场景中应用占比也逐渐提升。

五、适用场景对比与选型指南

5.1 优先选择MySQL的场景

互联网高频短事务场景：如电商订单、用户点赞、资讯评论、游戏道具交易等，这类场景对并发读写性能要求高，事务短，MySQL的优化更适配。
中小规模业务与创业公司：创业公司资源有限，运维人员不足，MySQL部署简单、运维成本低、社区资源丰富，能快速支撑业务上线。
对功能需求简单的场景：仅需基础的CRUD操作、简单查询与事务支持，无复杂数据类型、高级索引、数据分析需求。
已有MySQL技术栈的团队：团队熟悉MySQL的开发与运维，无需额外学习成本，且现有系统与MySQL兼容性良好，无需迁移成本。

选型案例：某初创社交APP，核心功能为用户注册、发布动态、点赞评论，团队仅2名开发人员，无专职运维。选择MySQL作为数据库，通过Docker快速部署，依托主从复制实现简单高可用，无需复杂配置，即可支撑初期数万用户的业务需求，开发与运维成本极低。

5.2 优先选择PostgreSQL的场景

企业级复杂业务场景：如金融交易、政务系统、医疗数据管理等，这类场景对数据一致性、事务完整性、功能完整性要求极高，PostgreSQL的SSI隔离级别、丰富功能能提供保障。
数据分析与数据仓库场景：如BI报表、数据统计、批量分析等，PostgreSQL的窗口函数、CTE、并行查询、扩展生态能大幅提升分析效率。
GIS与位置服务场景：如地图应用、外卖派单、物流轨迹追踪等，PostgreSQL+PostGIS扩展是开源领域的最优解决方案。
需要自定义功能与扩展的场景：如需要自定义函数、存储过程、复杂数据类型，或需集成加密、监控等扩展功能，PostgreSQL的扩展性更具优势。
长期发展的大规模业务：业务从中小规模向大规模扩展，对数据库扩展性、稳定性要求逐渐提升，PostgreSQL能更好地适配业务增长，减少后期迁移成本。

选型案例：某城市政务平台，需存储市民信息、政务办理记录、地理信息数据，同时支撑复杂的统计分析与跨部门数据共享。选择PostgreSQL作为核心数据库，通过PostGIS扩展管理地理信息，自定义PL/pgSQL函数实现业务逻辑校验，搭建流复制集群保障高可用，完全满足政务系统对数据一致性、功能完整性、稳定性的要求。

5.3 选型核心原则

业务需求优先：明确业务核心诉求（是高并发读写还是复杂功能），优先选择适配业务场景的数据库，而非盲目追求“功能全面”或“性能极致”。
团队能力匹配：结合团队技术栈与运维能力，若团队无PostgreSQL运维经验，且业务简单，优先选择MySQL；若有专业运维团队，且业务复杂，可选择PostgreSQL。
长期成本考量：考虑后期业务扩展、维护成本、迁移成本，避免因初期选型不当导致后期大规模重构。
生态适配性：确认现有应用框架、第三方工具与数据库的兼容性，减少适配成本。

六、总结

MySQL与PostgreSQL并非“谁优谁劣”，而是适配不同场景的两种优秀开源数据库：MySQL以“轻量高效、易用易运维”为核心优势，是互联网高频短事务场景的首选；PostgreSQL以“功能全面、稳定可靠、高度可扩展”为核心优势，是企业级复杂业务、数据分析、GIS场景的最优解。

二者的核心差异源于设计理念的不同：MySQL追求“做减法”，聚焦核心场景优化；PostgreSQL追求“做加法”，提供全场景功能支持。选型时需摒弃“非此即彼”的思维，结合业务需求、团队能力、长期规划综合决策，甚至可在同一系统中混合使用（如MySQL存储业务数据，PostgreSQL存储分析数据）。

事实上，或许再过个一两年，mysql的被使用程度会大大降低，因为随着mysql管理团队的决策，mysql最后可能会闭源，或者 mysql 的社区版功能会直接被阉割到只有皮毛，只能供给学生进行简单的 SQL 语句学习，更多的更能基本上会被搬运到企业版中去。闭源就是这样，古往今来所谓的开源闭源就是一个循环，这也是为什么作为开发者的我们一定要与时俱进，不断迭代自己的技术。