？？？ 直接把 MySQL 代码粘过去，生产环境竟然原地爆炸了！
别笑，根据 Stack Overflow 2024 年度的开发者调研，PostgreSQL 已经以 49% 的使用率超越 MySQL 登顶全球第一，但据不完全统计，超过 60% 的新玩家在迁移第一天就被报错信息按在地上摩擦。
连 DB-Engines 的资深分析师都忍不住吐槽："从 MySQL 到 PG，这哪里是换数据库，分明是换脑子。"
今天咱们不聊那些虚头巴脑的底层架构，就聊聊那些让你深夜加班的"语法坑"。准备好，这波是干货。
引号引发的血案
咱们先说个最反直觉的。在 MySQL 的世界里，单引号、双引号就像是一对好基友，混着用也没事。
但在 PG 的地盘？不好意思，这里讲究"长幼有序"。
SQL 标准规定：单引号用于字符串字面量，双引号用于数据库标识符（表名、列名）。
什么概念？
如果你在 PG 里写 SELECT "status" FROM users WHERE "status" = "active"，PG 会直接给你甩一个报错：column "active" does not exist。
因为它认为双引号里的 "active" 是一个列名，而不是字符串！
简单来说：
- MySQL：
'active'和"active"都能代表字符串。 - PG：只有
'active'是字符串，"active"是指叫 active 的那个字段。
这种严谨（死板）的风格，虽然符合 ANSI SQL 标准，但对于习惯了 MySQL"松弛感"的兄弟们来说，简直就是灾难。如果不改掉乱用双引号的毛病，你的迁移之路第一步就会断腿。
自增主键消失了？
用惯了 MySQL 的 AUTO_INCREMENT，是不是觉得建表时无脑加这个关键词特别爽？
到了 PG，你又要傻眼了：查无此词。
PG 的设计哲学是"解耦"。它不像 MySQL 那样把自增逻辑绑定在表上，而是通过一个独立的对象------**序列（Sequence）**来实现。
在老版本 PG 里，你需要用 SERIAL 这个伪类型： id SERIAL PRIMARY KEY
而在 PG 10 以后，官方更是推荐符合 SQL 标准的写法： id INTEGER GENERATED ALWAYS AS IDENTITY PRIMARY KEY
这有什么区别？ 想象一下，MySQL 的自增像是"表自带的计数器"，而 PG 的序列是一个"全局发号器"。
这意味着，在 PG 里，多个表甚至可以共用同一个序列！虽然你可能暂时用不上，但这种灵活性在处理分表分库数据迁移时，简直是神技。
0 竟然不是 False
这个坑，真的能让人把键盘砸了。
在 MySQL 里，我们习惯了用 TINYINT(1) 来存布尔值。0 就是 False，1 就是 True。查询的时候写 WHERE is_deleted = 0，丝滑流畅。
但在 PG 里，布尔值就是布尔值（BOOLEAN），整数就是整数。
如果你对着一个定义为 BOOLEAN 类型的字段写 WHERE is_deleted = 0，PG 会冷冷地告诉你： operator does not exist: boolean = integer。
你必须写成 WHERE is_deleted = false 或者 WHERE is_deleted IS NOT TRUE。
这不仅仅是语法的差异，更是强类型与弱类型思维的碰撞。MySQL 像个慈祥的老奶奶，总在背后帮你做隐式转换；而 PG 就像个严厉的数学老师，类型不对？直接挂科。
别背函数，查表！
很多兄弟迁移代码，最头疼的就是满屏的函数报错。
"咦？IFNULL 怎么不管用了？" "卧槽？GROUP_CONCAT 哪去了？"
别慌，数据不会撒谎。约有 30% 的 SQL 迁移工作量，其实就是在做"函数翻译"。
这里有一份我整理的保命对照表，建议直接截图收藏：
| 场景 | MySQL (小海豚) | PostgreSQL (大象) | 备注 |
|:----------|:----------------------|:------------------------------|:------------------------------------|-----|----------------|
| 空值判断 | IFNULL(a, b) | COALESCE(a, b) | COALESCE 是标准 SQL，通用性更强 |
| 字符串拼接 | CONCAT(a, b) | `a | | b` | PG 的双竖线操作符极其简洁 |
| 聚合连接 | GROUP_CONCAT(name) | STRING_AGG(name, ',') | PG 必须指定分隔符 |
| 模糊查询 | LIKE 'Abc%' (不分大小写) | ILIKE 'abc%' | LIKE 在 PG 里严格区分大小写！ILIKE 才是你的救星 |
| 当前时间 | SYSDATE() / NOW() | CURRENT_TIMESTAMP / now() | 别忘了 PG 做时间加减要加 INTERVAL |
尤其是 ILIKE 这个操作符，千万记住！ 很多人把代码迁过去，发现搜索功能全废了，查不出数据，就是因为 PG 的 LIKE 默认是区分大小写的。
JSONB 才是王炸
说了这么多坑，为什么要受罪迁到 PG？
除了开源协议更友好（老板喜欢），真正的杀手锏是------JSONB。
虽然 MySQL 5.7 之后也支持 JSON，但在 PG 的 JSONB 面前，真的只能算个弟弟。
什么概念？ MySQL 的 JSON 大多是文本存储，查询时需要实时解析。而 PG 的 JSONB 是以二进制格式存储的，写入时慢一点，但读取和索引速度极快。
Benchmark 数据显示：在复杂 JSON 文档的查询场景下，PG 的 JSONB 性能往往是 MySQL 的 2-5 倍。
在 PG 里，你可以用 -> 和 ->> 操作符像操作对象一样丝滑地提取 JSON 字段，甚至直接用 @> 操作符来判断包含关系：
SELECT * FROM books WHERE meta @> '{"author": "老黄"}'
这行代码在 MySQL 里写出来可能要绕地球一圈，在 PG 里，既优雅又高效。对于现在满地 NoSQL 需求的业务来说，PG = 关系型数据库 + MongoDB，这诱惑谁顶得住？
最后的最后
从 MySQL 到 PG，不是一次简单的 dump 和 restore，而是一场思维方式的升级。
MySQL 的"宽容"让我们开发效率极高，但也埋下了很多不严谨的雷；PostgreSQL 的"强迫症"，虽然上手有点痛，但一旦习惯了，你会发现你的代码质量被倒逼着提升了一个台阶。
最好的还在后面。
当你跨过了这几道语法鸿沟，你会发现 PG 还有 GIS 地理信息处理、强大的插件系统等著你探索。
现在，动动手指： 在你的 Docker 里跑一个 PG 容器，把你手头最复杂的那个 SQL 扔进去试试。
问题来了： 你是愿意留在 MySQL 的温室里当个宝宝，还是去 PG 的严酷世界里当个极客？我们在评论区 Battle 一下！