保留字为什么容易踩坑
字段名与 SQL 保留字同名（order、desc、group、level、current、values）时，多数引擎要求加转义符才能引用，否则解析报错。麻烦在于各引擎的转义符并不统一，一段脚本在 MySQL 里能跑，换到 Hive 或 Spark 就可能直接失败。
基本信息
| 高频冲突词 | order、desc、group、level、current、values、rank |
|---|---|
| MySQL 转义 | 反引号包裹，如 order 列写为 `order` |
| Hive / Spark | 同样使用反引号，跨引擎相对友好 |
| PostgreSQL / Oracle | 双引号包裹，且加引号后变为大小写敏感 |
| 大小写 | 不加引号时标识符通常不区分大小写，加引号后严格区分 |
| 预防手段 | 建表前对照保留字清单检查字段名 |
典型使用场景
- ODS 落地源系统表：源库字段常直接叫 order、status，同步后名字照搬
- 跨引擎取数：同一段 SQL 在 MySQL 与 Hive 之间复用
- 业务字段天然重名：等级、组别、排序在中文语境里就是 level、group、desc
- 代码自动生成建表语句：生成器未做保留字过滤
- 接手他人表结构：字段名需要转义才能查询，排查效率明显下降
冲突写法对照
冲突写法对照
-- 字段名与保留字同名，必须加反引号才能引用（MySQL / Hive / Spark）
SELECT `order`, `desc` FROM dwd_trade_order_di;
-- 建表时把保留字也一并转义，否则创建阶段就失败
CREATE TABLE tmp_demo (
`order` STRING, -- 不推荐：每次引用都要转义
desc_text STRING -- 推荐：改名后无需任何转义
);
-- PostgreSQL / Oracle 使用双引号，加引号后标识符区分大小写
-- SELECT "order" FROM dwd_trade_order_di;引擎转义对照
| 引擎 | 转义符 | 注意点 |
|---|---|---|
| MySQL | 反引号 | 库表名在部分系统上区分大小写 |
| Hive / Spark SQL | 反引号 | 列名与保留字冲突同样需要转义 |
| PostgreSQL | 双引号 | 加引号后名称区分大小写，混用易出错 |
| Oracle | 双引号 | 未加引号时名称被转为大写 |
转义符在不同引擎之间并不通用。脚本需要在多个引擎执行时，优先把字段改名（order 改 order_no、desc 改 desc_text），比到处补转义符更省事，也避免加引号后引入大小写敏感问题。
多数引擎允许保留字直接作为列别名使用，冲突只发生在作为标识符引用时。因此在查询末尾用 AS order 起别名通常没问题，真正的风险点在表结构的列名上。