基于 MySQL 8.0 / PostgreSQL 16+ 最新版本，综合 Stack Overflow 2025 调研、AWS 官方文档及社区实践。
一、基础信息
| 维度 | MySQL | PostgreSQL |
|---|---|---|
| 开发商 | Oracle（2010年收购 Sun 后获得） | 全球社区独立维护，起源于 UC Berkeley POSTGRES 项目 |
| 首次发布 | 1995年 | 1996年（v6.0） |
| 许可证 | GPL（社区版）+ 商业版需付费 | PostgreSQL License（≈ BSD/MIT，完全自由，无商业限制） |
| 当前最新 | 8.4（2025） | 17（2025） |
| 设计哲学 | 简单、快速、宽容 ------ "能跑就行" | 严格、标准、完备 ------ "做正确的事" |
| 定位 | 轻量级 Web 应用之王 | 功能完备的企业级数据库 |
| 归属风险 | ⚠️ Oracle 控制，存在商业锁定风险 | ✅ 纯社区驱动，无厂商锁定 |
二、架构与连接模型
| 维度 | MySQL | PostgreSQL |
|---|---|---|
| 存储引擎 | 插件式（InnoDB / MyISAM / Memory 等），InnoDB 为主导 | 单一集成存储引擎，不可插拔 |
| 连接模型 | 🧵 多线程：每个连接一个线程 | 🔄 多进程：每个连接一个独立进程（~10MB/进程） |
| 进程隔离 | 较弱，一个线程崩溃可能影响整个服务 | ✅ 强隔离，单个进程崩溃不影响其他 |
| 推荐连接池 | 可不用（线程轻量） | ✅ 必须用（PgBouncer / pgcat） |
| 数据库结构 | 4级：实例 → 数据库 → 表 → 列 | 5级：实例（集群）→ 数据库 → Schema → 表 → 列 |
| 跨库 JOIN | ✅ 支持 db1.table JOIN db2.table |
❌ 默认不支持，需用 FDW 扩展 |
三、数据类型支持
| 类型 | MySQL | PostgreSQL | 备注 |
|---|---|---|---|
| 整数 | TINYINT / SMALLINT / INT / BIGINT | SMALLINT / INTEGER / BIGINT / SERIAL | PG 的 SERIAL = 自增序列，非 MySQL 的 AUTO_INCREMENT 缩写 |
| 布尔 | ❌ 无原生类型，用 TINYINT(1) 模拟 |
✅ 原生 BOOLEAN |
PG 中 0/1 不能代替 true/false |
| 字符串 | CHAR / VARCHAR / TEXT / ENUM / MEDIUMTEXT | CHAR / VARCHAR / TEXT | PG 的 TEXT 理论上可存 1GB；MySQL utf8mb4 下 VARCHAR 仅 16,383 字符 |
| JSON | JSON（文本存储，性能一般） |
JSON + JSONB（二进制，可索引，高性能） |
✅ PG 明显胜出 |
| 数组 | ❌ 不支持 | ✅ 原生 INT[] / TEXT[] 等 |
PG 杀手级特性之一 |
| 范围类型 | ❌ 不支持 | ✅ int4range / daterange 等 |
适合时间段查询、价格区间 |
| 地理信息 | 基础空间类型 | ✅ PostGIS 扩展（专业级 GIS） | PG + PostGIS = 开源 GIS 首选 |
| 向量/AI | ❌ 不支持 | ✅ pgvector 扩展（AI Embedding 存储+检索） | 2024-2025 最火扩展 |
| IPv6 | ✅ 支持 | ✅ 原生支持 | --- |
| 货币 | ❌ 用 DECIMAL 模拟 |
✅ 原生 MONEY 类型 |
--- |
| XML | 基础支持 | ✅ 原生支持，可索引 | --- |
| 自定义类型 | ❌ 不支持 | ✅ CREATE TYPE 自定义复合类型 |
PG 杀手级特性 |
| 二进制 | BLOB（max 64KB） |
BYTEA（max 1GB） |
--- |
四、SQL 标准与语法兼容性
| 特性 | MySQL | PostgreSQL | 赢家 |
|---|---|---|---|
| SQL 标准兼容 | 部分兼容，有大量非标准扩展 | ✅ 高度兼容 SQL:2016 | PG |
| GROUP BY 严格性 | ⚠️ 宽松：允许 SELECT 非聚合列 | ✅ 严格：不允许 | PG |
| 大小写敏感 | 默认不敏感 （User = user） |
默认敏感 （"User" ≠ user） |
--- |
| CTE（公用表表达式） | 8.0+ 支持（递归 CTE 支持） | ✅ 完整支持 | PG（更早更完善） |
| 窗口函数 | 8.0+ 支持 | ✅ 完整支持 | PG（更早更完善） |
| 递归查询 | 8.0+ 支持 | ✅ 完整支持 | PG |
| 全外连接 FULL OUTER JOIN | ✅ 8.0+ 支持 | ✅ 支持 | 平 |
| UPSERT 语法 | ON DUPLICATE KEY UPDATE |
ON CONFLICT ... DO UPDATE（可指定冲突列） |
PG 更灵活 |
| 自动类型转换 | ⚠️ 非常宽容（字符串→整数自动转，可能丢数据） | ✅ 严格（类型不匹配直接报错） | PG 更安全 |
| 字符集/排序规则 | ~5 种字符集，几十种排序规则 | ✅ ICU 支持，42 种字符集，815+ 排序规则 | PG 完胜 |
| 触发器 | AFTER / BEFORE | ✅ 额外支持 INSTEAD OF 触发器 | PG |
| 物化视图 | ❌ 不支持 | ✅ 原生支持 | PG |
| 存储过程语言 | 有限（SQL/PSM） | ✅ PL/pgSQL / Python / Perl / C / Java 等 | PG |
| 视图更新 | 有限制 | ✅ 可更新物化视图 | PG |
五、事务与并发控制（MVCC）
| 维度 | MySQL（InnoDB） | PostgreSQL | 赢家 |
|---|---|---|---|
| ACID 合规 | ✅ 仅 InnoDB 引擎支持 | ✅ 所有配置默认支持 | PG |
| MVCC 实现 | ✅ 有，依赖 undo 日志 | ✅ 有，实现更彻底 | PG |
| 读操作锁 | ⚠️ 有读锁，受间隙锁影响 | ✅ 读无锁，读写完全不阻塞 | PG |
| 写-写冲突 | 行锁，冲突少时效率高 | MVCC 减少锁竞争，写入并发更稳定 | PG |
| 事务隔离级别 | READ COMMITTED / REPEATABLE READ / SERIALIZABLE | ✅ 同样支持 + SERIALIZABLE 默认更严格 | PG |
| 行级安全（RLS） | ❌ 需手动建视图模拟 | ✅ 开箱即用 CREATE POLICY |
PG |
六、性能对比
| 场景 | MySQL | PostgreSQL | 赢家 |
|---|---|---|---|
| 简单读查询（单表 CRUD） | ✅ 更快，查询优化器开销小 | 略慢（优化器更复杂） | MySQL |
| 读多写少（CMS、新闻、电商列表） | ✅ 明显优势 | 良好 | MySQL |
| 复杂查询（多表 JOIN、子查询嵌套） | 优化器较弱，索引利用率低 | ✅ 优化器更智能，执行计划更优 | PG |
| 高并发写入 | InnoDB 行锁出色，但有间隙锁问题 | ✅ MVCC 无读写锁，写入并发更稳定 | PG |
| 大批量导入 | ✅ LOAD DATA INFILE 极快 |
✅ COPY 命令同样极快 |
平 |
| 超大表 + 分区 | 分区表较简单 | ✅ 继承表分区更灵活，支持范围/列表/哈希 | PG |
| 并行查询 | 有限支持 | ✅ 原生并行查询（多核利用） | PG |
| 总体差距 | --- | --- | ⚠️ 最多 30% 差异，缺少索引时两者都会 x10~x1000 降级 |
七、索引类型
| 索引类型 | MySQL | PostgreSQL |
|---|---|---|
| B-Tree | ✅ | ✅ |
| Hash | ✅ | ✅ |
| R-Tree（空间） | ✅ | ✅（GiST） |
| GiST（通用搜索树） | ❌ | ✅ 支持几何、全文搜索、范围等 |
| GIN（倒排索引） | ❌ | ✅ JSONB / 数组 / 全文搜索专用 |
| BRIN（块范围索引） | ❌ | ✅ 超大表利器，占用极小 |
| 表达式索引 | ❌ | ✅ CREATE INDEX ON t ((lower(name))) |
| 部分索引 | ❌ | ✅ CREATE INDEX ON t (col) WHERE col > 100 |
PG 索引种类是 MySQL 的 3 倍以上，适配场景更广。
八、复制与高可用
| 维度 | MySQL | PostgreSQL |
|---|---|---|
| 复制方式 | binlog 逻辑复制（异步为主） | WAL 物理复制（流复制） |
| 同步复制 | ⚠️ 半同步插件 | ✅ 原生支持同步/异步/半同步 |
| 复制延迟 | 通常较低 | 物理复制延迟极低 |
| 故障切换 | 需额外工具（MHA / Orchestrator） | ✅ pg_rewind / Patroni / Repmgr |
| 点时间恢复（PITR） | ⚠️ 需 binlog 回放，较复杂 | ✅ 原生 PITR，企业级特性 |
| 集群方案 | MGR（MySQL Group Replication） | ✅ Citus（分布式 HTAP）/ Patroni / PgPool |
九、扩展性
| 维度 | MySQL | PostgreSQL |
|---|---|---|
| 存储引擎扩展 | ✅ 插件式（但 InnoDB 已垄断） | ❌ 不可插拔 |
| 功能扩展 | 有限 | ✅ 极强，官方维护大量高质量扩展 |
| 核心扩展 | --- | PostGIS / pgvector / pg_stat_statements / hstore / pg_partman / pgcrypto / timescaledb / Citus 等 |
| 兼容其他数据库 | ❌ | ✅ Babelfish（兼容 MSSQL）/ OpenHalo（兼容 MySQL 协议）/ FerretDB（兼容 MongoDB） |
| 分布式 | MGR / Vitess / ProxySQL | ✅ Citus / 兼容 Aurora DSQL |
十、安全性
| 维度 | MySQL | PostgreSQL |
|---|---|---|
| RBAC 权限 | ✅ 支持 | ✅ 支持，更细粒度（角色继承、SCHEMA 级权限） |
| 行级安全（RLS） | ❌ 需视图模拟 | ✅ 原生 CREATE POLICY |
| 列级加密 | ❌ 需企业版 TDE | ✅ pgcrypto 扩展，字段级加密 |
| SSL/TLS | ✅ 支持 | ✅ 支持 |
| 认证模块 | PAM 插件 | PAM 插件 |
| 开源审计 | 有限 | ✅ 社区透明，无后门风险 |
| 厂商信任 | ⚠️ Oracle 控制 | ✅ 纯社区，Berkeley 学术背景 |
十一、生态与社区（2025-2026 趋势）
| 维度 | MySQL | PostgreSQL |
|---|---|---|
| 安装量 | ✅ 全球最大开源数据库 | 增速最快，增量已超 MySQL |
| 社区活跃度 | Oracle 主导，更新消极 | ✅ 社区驱动，创新活跃 |
| 云厂商态度 | AWS / GCP 仍支持，但新品优先 PG | ✅ AWS Aurora DSQL / AlloyDB / Google Spanner PG 均只支持 PG |
| 工具链 | ✅ 极其丰富（phpMyAdmin / Navicat 等） | 良好（pgAdmin / DBeaver / DataGrip） |
| 学习曲线 | ✅ 简单，初学者友好 | 较陡，需更多配置经验 |
| Stack Overflow 2025 | 最受欢迎 | ✅ 最受敬仰 + 最渴望使用 |
| 融资/资本 | MariaDB 退市，生态萎缩 | ✅ pgvector / Neon / Supabase 等大额融资 |
| 国内趋势 | MySQL:PG 从 10:1 缩至 5:1 | ✅ 增量已反超 MySQL |
十二、选型决策表
| 你的场景 | 推荐 | 理由 |
|---|---|---|
| 博客 / 小型 CMS / 快速原型 | MySQL | 简单、快、工具多 |
| 读多写少的 Web 应用（电商商品页、新闻站） | MySQL | 简单查询性能优势明显 |
| LAMP 架构 / WordPress / PHP 生态 | MySQL | 生态绑定 |
| 金融 / 电信 / ERP / CRM | PostgreSQL | 强一致性、强事务、PITR |
| 地理信息系统（GIS） | PostgreSQL + PostGIS | MySQL 无对手 |
| AI / 向量检索（Embedding 存储） | PostgreSQL + pgvector | 2024-2025 最火方案 |
| 复杂查询 / 数据分析 / 报表 | PostgreSQL | 优化器更强、并行查询 |
| 高并发写入（如交易系统） | PostgreSQL | MVCC 读写无锁 |
| 需要 JSON 大量存储+查询 | PostgreSQL | JSONB + GIN 索引完胜 |
| 团队新手多 / 快速上线 | MySQL | 学习成本低 |
| 追求长期正确性 / 不想被厂商绑定 | PostgreSQL | 许可证自由、社区独立 |
十三、一句话总结
| MySQL | PostgreSQL | |
|---|---|---|
| 一句话定位 | 互联网时代的"快刀" ------ 简单、快速、够用 | 数据时代的"重剑" ------ 严格、完备、正确 |
| 设计取舍 | 追求性能，牺牲部分正确性 | 追求正确性，性能已不再落后 |
| 2026年趋势 | 存量巨大，但增量被 PG 蚕食 | ✅ 云厂商、资本、社区全面押注 |
💡 2026年的现实 ：如果你在纠结选哪个，新项目优先 PostgreSQL。MySQL 唯一的优势只剩"团队已经会了"和"遗留系统迁移成本"。