引擎 SQL 方言差异与兼容写法
跨引擎 SQL 存在实实在在的差异：日期截断与格式化函数、字符串拼接、类型转换的严格程度、正则写法、窗口函数支持范围，甚至标识符大小写与转义规则。可行的做法是把方言集中在少数脚本或 UDF 里，主链路尽量用各引擎都支持的标准写法，迁移时才不会变成全量重写。
基本信息
| 主要差异面 | 日期函数、拼接、类型转换、正则 |
|---|---|
| 方言收敛 | 集中在少数脚本与 UDF |
| 标识符 | 大小写与转义规则不同 |
| 迁移成本 | 取决于方言散落程度 |
| 验证方式 | 在目标引擎实跑样例与对账 |
典型使用场景
- 多引擎链路（Hive、MySQL 系、ClickHouse）：主链路尽量用标准写法
- 迁移评估：先梳理出用到的引擎特有函数清单，再估工作量
- 类型转换：MySQL 系 cast 更严格，宽松引擎能容忍的写法可能直接报错
- 日期处理：优先依赖规范化的日期字段与统一格式，减少引擎函数依赖
- 上线验证：迁移后跑一遍对账用例，而不是只看语句能否执行成功
兼容写法
兼容写法
-- 尽量使用跨引擎都支持的标准写法
SELECT store_id,
CAST(pay_amt AS DECIMAL(18,2)) AS pay_amt, -- 显式转换，避免隐式行为差异
substr(dt, 1, 7) AS mon -- 字符串截取替代引擎特有日期函数
FROM dwd_trade_order_di
WHERE dt = '2026-10-12';
-- 差异点：Hive/Spark 用 date_trunc，MySQL 系常用 date_format，复杂逻辑封装成 UDF常见差异点
| 能力 | Hive / Spark | MySQL 系（含 Doris） |
|---|---|---|
| 日期截断 | date_trunc | date_format 等，视版本而定 |
| 字符串拼接 | concat | concat |
| 类型转换 | 较宽松，失败可能得 NULL | 较严格，可能直接报错 |
| 正则 | regexp_extract 等函数 | REGEXP 函数族 |
方言差异集中在少数脚本与 UDF 里，换引擎时改动面才是可控的；散落在几百条 SQL 里的特有函数，迁移基本等于重写。
类型转换的严格程度不同：在宽松引擎里得到 NULL 的表达式，在严格引擎上可能直接让整批任务失败，迁移评估要把脏数据一起算进去。