5.2 SQL兼容性与方言

5.2 SQL兼容性与方言

本节摘要：DuckDB 高度兼容 SQL 标准，从 MySQL 或 PostgreSQL 搬迁日常查询基本无痛；真正的雷区集中在分页、日期函数与隐式类型转换三个区域。同时它带来一批现代语法糖——GROUP BY ALL、EXCLUDE、QUALIFY——学一次就能在所有场景反复受益。

兼容性从哪里来

SQL 标准是纸面共识，各数据库的方言是生存现实——兼容性的实际问题从来不是"支不支持 SELECT"，而是那些标准没管死的边角。DuckDB 的策略是贴紧标准语义，再补齐主流方言里最常用的扩展，于是迁移的大头自动消失：JOIN、窗口函数、CTE、集合运算这些核心件，写法和你熟悉的库几乎一致。真正需要你动手的地方集中在三类，逐个过。

雷区一：分页与限行

行数截取是最常见的差异源。MySQL 的 LIMIT offset, count 双参数写法、PostgreSQL 的 LIMIT ALL、SQL Server 的 TOP——各家一家样。DuckDB 用标准风格：LIMIT 加 OFFSET，同时支持更简洁的链式：

-- 标准写法，跨方言通用度最高
SELECT * FROM trades_clean ORDER BY trade_time DESC LIMIT 10 OFFSET 20;

-- 也支持这种连写风格，语义同上
SELECT * FROM trades_clean ORDER BY amount DESC LIMIT 5;
​

迁移心法：旧 SQL 里的双参数 LIMIT 要手工改写成 LIMIT 加 OFFSET 的组合，语义别想当然。

雷区二：日期与时间函数

日期函数是方言差异的重灾区，几乎没有两个库的名字完全一致。DuckDB 提供的是标准化的类型与间隔算术，外加一批惯用函数。对照记最有效：

-- 间隔算术与截断的标准姿势
SELECT date_trunc('week', trade_time) AS 周,
       count(*) AS 笔数
FROM trades_clean
WHERE trade_time >= TIMESTAMP '2024-06-01' + INTERVAL 7 DAY
GROUP BY 周;
​

迁移时把所有日期处理点列成清单逐条核对，比整体"感觉差不多"可靠得多——日期 bug 的特点是悄悄错，报表上不容易被发现。

雷区三：隐式类型转换

DuckDB 对类型比较严格：字符串和数字比较、不同宽度的整数混算，很多方言里"能跑但结果可疑"的写法在这里会直接报错。短期看是麻烦，长期看是保护——那些可疑结果正是数据事故的温床。迁移旧 SQL 时，遇到报错别急着绕，先把显式转换补上，语义就清楚了。这个严格性还有一个迁移之外的馈赠：它逼你搞清楚每条旧 SQL 里"一直没人敢动"的比较逻辑到底在比什么——许多团队在迁移时发现某些 WHERE 条件从头到尾就没命中过，全靠隐式转换的巧合活着。严格类型是给数据质量做的免费体检。

值得学走的现代语法

除了避坑，DuckDB 还有几个语法糖值得反向带走，它们解决的是标准 SQL 长年累赘的老问题：

-- 聚合列自动分组：GROUP BY ALL 免去手抄一遍列名
SELECT status, vip_level, count(*) AS 笔数
FROM trades_clean JOIN users u ON user_id = u.id
GROUP BY ALL;

-- 通配排除列：SELECT 反着写，宽表探索时极省事
SELECT * EXCLUDE (raw_payload) FROM events_raw LIMIT 5;

-- 窗口过滤：QUALIFY 直接对窗口结果过滤，免套一层子查询
SELECT user_id, amount,
       row_number() OVER (PARTITION BY user_id ORDER BY amount DESC) AS rn
FROM trades_clean
QUALIFY rn <= 3;
​

三条各有妙处：GROUP BY ALL 消灭了"SELECT 里加列、GROUP BY 忘了同步"的经典报错；EXCLUDE 让宽表预览不再刷屏；QUALIFY 把"每组取前N"这个高频需求从三层子查询简化成一行。写惯之后再回头看老方言，会有明显的解脱感。糖要用在正处：探索性查询是它们的最大受益者——列名临时改、分组随时调，机械同步交给引擎；但固化到生产脚本的 SQL 反而建议保守写法，显式列出让半年后的维护者一眼看清依赖，这是糖与纪律的分界。

主线案例的方言体检

主线案例全程用到的语法都落在安全区：聚合、条件表达式、日期截断、窗口函数。唯一一次踩线是把金额列当文本比较——CSV 嗅探把一列脏数据读成了 VARCHAR，比较不报错但结果为空，最后用显式 CAST 收编。这次小事故的教训写进第7章的陷阱清单：类型问题宁可让它报错，不要让它静默。

一次迁移实战的完整清单

把三条雷区连同核对方法收进一份可执行的迁移清单，按操作顺序走。第一步，盘点方言特征：旧 SQL 全量扫一遍，标记所有分页、日期函数、类型转换、字符串拼接的行——这四类覆盖九成改写点。第二步，逐条改写并双跑对账：改一条，新旧各跑一遍、结果做差——DuckDB 侧可以挂载旧库直查旧表（第1.3节的 ATTACH），对账连导出都省了。第三步，收集报错建台账：改写中撞的每个类型报错都记一笔，它们是旧系统隐式转换的藏宝图——每个报错背后都是一处"原来那边一直在静默转类型"。第四步，抽样深查：随机抽几百行，新旧系统的聚合结果对粒度、对空值、对边界日期。清单走完，迁移就不再是"感觉差不多"，而是每条语句都有对账记录的工程。这份清单的副产品常被低估：第二步的台账往往顺带揪出旧系统里潜伏多年的类型隐患——迁移是给老数据做体检的最好机会。

方言糖的背后：为什么值得学

GROUP BY ALL、EXCLUDE、QUALIFY 这类语法常被当作"锦上添花"，本节想替它们正名：它们修正的是 SQL 的历史设计债。GROUP BY 修的是"SELECT 与 GROUP BY 列表必须手工同步"这个纯机械负担——五十列的宽表每加一列要改两处，改漏就报错；EXCLUDE 修的是宽表探索的反人类体验；QUALIFY 修的是"每组取前N"这个高频需求的绕路写法。学它们的本质，是让引擎接管一类机械劳动。方言糖还有一个隐藏收益：新写的 SQL 可读性更好——QUALIFY 一行顶三层子查询，半年后回读时理解成本天差地别。工具在学习曲线上的投资，回报的不只是速度，还有可维护性。

本节要点回顾

• 核心件无痛，边角有雷：JOIN、窗口、CTE 直接搬；分页、日期、类型转换三区必查。
• 分页改写：双参数 LIMIT 一律换成 LIMIT 加 OFFSET 组合。
• 日期函数列清单核对：截断用 date_trunc，间隔用 INTERVAL，格式化注意格式符体系。
• 三个语法糖反向带走：GROUP BY ALL、EXCLUDE、QUALIFY，学一次处处受益。