MySQL vs PostgreSQL：怎么选？
MySQL 更简单易用、生态成熟，PostgreSQL 功能更强大、标准兼容性更好
对比
| 维度 | MySQL | PostgreSQL |
|---|---|---|
| 易用性 | 上手简单，文档丰富，社区活跃，新手友好 | 学习曲线稍陡，配置项多，但文档质量高 |
| 性能（读多写少） | 简单查询性能优秀，读密集场景表现好 | 复杂查询优化器更智能，大数据量分析更强 |
| 性能（写密集） | InnoDB 写入性能好，适合高并发 OLTP | MVCC 实现不同，高并发写入时需要定期 VACUUM |
| 数据类型 | 基础类型完善，JSON 支持（5.7+） | 类型极其丰富：数组、JSONB、范围类型、几何类型、自定义类型 |
| SQL 标准兼容 | 部分兼容，有 MySQL 特有语法 | 高度兼容 SQL 标准，支持窗口函数、CTE、递归查询等 |
| 扩展性 | 通过存储引擎扩展（InnoDB、MyISAM） | 插件系统强大，支持自定义类型、函数、索引方法 |
| 复制与高可用 | 主从复制成熟，Group Replication、InnoDB Cluster | 流复制、逻辑复制，Patroni/Citus 等生态 |
| 生态与工具 | 生态最大，几乎所有框架和云平台都支持 | 生态完善，云平台支持好，但部分老工具不支持 |
| 许可证 | GPL（社区版），商业版需付费 | PostgreSQL License（类 MIT），完全免费无限制 |
| 适合场景 | Web 应用、电商、CMS、中小型 OLTP | 复杂业务、数据分析、GIS、金融、需要高级 SQL 特性 |
使用场景
什么时候用 MySQL
- Web 应用和互联网项目（PHP/Java/Node.js 生态）
- 团队对 MySQL 更熟悉，运维经验丰富
- 读多写少的典型 OLTP 场景
- 需要成熟的主从复制和读写分离方案
- 中小型项目快速开发，追求简单易用
什么时候用 PostgreSQL
- 需要复杂 SQL 特性（窗口函数、CTE、递归查询）
- 数据类型复杂（JSON 文档、地理信息、数组）
- 对数据完整性和一致性要求极高（金融、医疗）
- 需要强大的扩展能力（自定义类型、插件）
- 混合 OLTP + OLAP 场景
示例
mergeExample
-- MySQL 典型用法：电商订单查询 SELECT o.order_no, o.total_amount, u.username FROM orders o INNER JOIN users u ON o.user_id = u.id WHERE o.status = 1 ORDER BY o.created_at DESC LIMIT 20;
rebaseExample
-- PostgreSQL 典型用法：窗口函数 + CTE
WITH monthly_sales AS (
SELECT user_id,
DATE_TRUNC('month', created_at) AS month,
SUM(total_amount) AS total
FROM orders
GROUP BY user_id, DATE_TRUNC('month', created_at)
)
SELECT user_id, month, total,
RANK() OVER (PARTITION BY month ORDER BY total DESC) AS rank
FROM monthly_sales;常见错误
因为「PostgreSQL 更强大」就无脑选 PostgreSQL，忽略团队经验和运维成本
在 MySQL 中写复杂分析查询，不如用 PostgreSQL 或专门的分析数据库
忽略云平台的托管服务差异（如 AWS RDS 对两者支持程度不同）
迁移时忽略 SQL 语法差异（如 MySQL 的反引号 vs PostgreSQL 的双引号）
建议
大多数 Web 应用选 MySQL 就够了，简单、成熟、生态好。如果业务逻辑复杂、需要高级 SQL 特性或对数据完整性要求极高，选 PostgreSQL。两者都是优秀的数据库，关键看团队经验和业务需求。