sql server 不支持 using 关键字，仅支持 on 进行 join；其语法缺失导致迁移、bi 工具、联邦查询等场景报错，并引发列名歧义、提示失效及元数据不可靠等问题。
USING 在 Oracle 和 PostgreSQL 中能用，但在 SQL Server 里根本不存在
SQL Server 完全不支持 USING 关键字，写完直接报错：Incorrect syntax near 'using'。这不是配置问题，是语法层面缺失——它的 JOIN 只认 ON。很多企业数仓底层是 SQL Server（尤其金融、政务类老系统），开发人员若从 Oracle 或 PG 迁移过来，习惯性写 USING (id)，上线就失败。
常见错误现象：
- 本地用 PostgreSQL 测试通过的视图，在 SQL Server 部署时报语法错误
- BI 工具自动生成的 SQL 含
USING，导入到 SQL Server 环境后执行失败 - 团队共用一套 DDL 脚本，跨数据库迁移时漏掉语法适配
USING 导致列名歧义，JOIN 后无法安全引用同名字段
USING 会把连接列自动“合并”成单列输出，但后续 WHERE、GROUP BY 或 SELECT 中再引用该列时，必须不带表别名。一旦误写成 t1.id 或 t2.id，Oracle/PG 就报错：column "id" does not exist（因为已归并）。
企业级数仓常需多层嵌套查询、物化视图或下游 ETL 解析字段名，这种隐式归并极易引发下游解析失败。比如 Doris 3.0 的联邦查询或 Flink CDC 同步任务，依赖明确的列结构，USING 会让字段元数据丢失原始归属。
实操建议：
- 所有 JOIN 显式用
ON t1.col = t2.col，哪怕两边列名完全一致 - SELECT 列全部带表别名，如
t1.id, t2.name，避免歧义 - 禁用
USING的 CI 检查规则可加在 SQL Lint 工具中，匹配正则\bUSING\s*\(\w+\)
USING 无法配合表提示（Table Hints）和查询提示（Query Hints）使用
SQL Server 的性能调优重度依赖 WITH (NOLOCK)、WITH (INDEX(...)) 或 OPTION (LOOP JOIN) 这类提示。但这些提示只能作用于具体表别名，而 USING 不允许给连接列指定别名，导致提示无法精准绑定。
例如想对大表加 NOLOCK 并强制走某个索引：
SELECT * FROM orders o WITH (NOLOCK, INDEX(ix_order_date)) INNER JOIN customers c WITH (NOLOCK) ON o.cust_id = c.id
换成 USING (cust_id) 就没法指定哪个表加什么提示——USING 本身不暴露表粒度控制点。
更麻烦的是：某些企业数仓要求所有 SQL 必须附带 WITH (READUNCOMMITTED) 以规避锁等待，禁用 USING 实则是强制统一提示写法，降低运维风险。
USING 在跨源联邦场景下元数据不可靠
Doris、StarRocks 或 Trino 这类支持跨源查询的引擎，对外部 Hive/Iceberg 表做 JOIN 时，列类型推断依赖显式 ON 条件。而 USING 要求两边列名与类型严格一致，但实际中 Hive 表字段可能是 STRING，Iceberg 是 UUID，PostgreSQL 外表映射为 TEXT —— 类型不一致时 USING 直接失败，ON 却能配合 ::uuid 或 CAST() 显式转换。
企业数仓越来越倾向“不搬数据、只查数据”的湖仓一体架构，这时 USING 的僵化语义反而成了障碍。一个字段名相同但语义不同的列（比如两个系统的 user_id 实际指向不同主键体系），用 ON 还能加注释或中间转换，用 USING 就只能硬扛。
真正容易被忽略的点是：不是 USING 本身有问题，而是它把“列名一致”当作契约，而真实生产环境里，契约从来都是靠文档、靠注释、靠显式转换来维系的——不是靠语法糖。
