SQL SELECT语法在SQL Server 2019和2022中有什么区别？-SQL-PHP中文网

SQL Server 2019与2022的SELECT语法完全一致，差异在于兼容性级别控制的查询优化行为：如自适应联接、交错执行、基数估计反馈、OFFSET/FETCH执行计划、标量UDF内联及JSON/XML解析严格性等。

sql select语法在sql server 2019和2022中有什么区别？

SQL Server 2019 和 2022 的 SELECT 语法本身没有新增或删减关键字，核心结构（如 FROM、WHERE、ORDER BY、TOP、OFFSET/FETCH）完全一致——你写在 2019 上能跑的 SELECT，换到 2022 里照样能执行，不报错。

真正影响你实际体验的，是底层查询优化器行为和兼容性级别控制的隐性变化，不是语法变了，而是“怎么执行”变了。

COMPATIBILITY_LEVEL 决定是否启用新优化逻辑

触发器、视图、函数里的 SELECT 是否走自适应联接、交错执行（Interleaved Execution）、基数估计反馈（CE Feedback），全看数据库的 COMPATIBILITY_LEVEL，而不是 SQL Server 版本号。

即使装的是 SQL Server 2022，若数据库设为 COMPATIBILITY_LEVEL = 150（对应 2019），所有智能查询处理（IQP）功能默认关闭
SQL Server 2019 实例无法设置 COMPATIBILITY_LEVEL = 160 或 170，所以天然用不了 2022 新增的优化路径
修改命令：ALTER DATABASE your_db SET COMPATIBILITY_LEVEL = 160;，但会清空计划缓存，后续首次查询需重新编译

OFFSET/FETCH 分页行为表面一致，但执行计划可能不同

SELECT * FROM t ORDER BY id OFFSET 1000 ROWS FETCH NEXT 10 ROWS ONLY 这种写法在两个版本都支持，但实际执行时：

2022（COMPATIBILITY_LEVEL ≥ 160）更倾向生成带 TopNSort 的轻量级计划，尤其当 ORDER BY 列有索引时
2019 或低兼容级别下，可能退化为完整排序 + 偏移跳过，对大偏移量（如 OFFSET 100000）性能更敏感
注意：如果 ORDER BY 列存在重复值且未加 WITH TIES，两版返回结果顺序理论上都“不确定”，但 2022 在某些场景下更容易暴露该问题

标量 UDF 内联对 SELECT 性能影响显著且版本间不一致

当你在 SELECT 列表中调用 T-SQL 标量函数（如 SELECT id, dbo.fn_get_name(id) FROM t），2019 引入的内联机制在 2022 中继续增强，但行为受 CU 补丁和兼容级别双重影响：

2022 默认启用更强的内联尝试，但遇到 sql_variant 返回类型、CHECKSUM()、未初始化变量等边界情况，可能报错或返回意外结果（KB4538581 已修复部分问题）
2019 CU9 及之后版本对内联失败的降级更保守；2022 CU 可能直接禁用内联并回退到传统逐行调用，导致性能骤降
验证方式：查 sys.dm_exec_query_plan 中是否含 UdfInlined="true"，或开启 query_tsql_scalar_udf_inlined 扩展事件

JSON 和 XML 相关 SELECT 功能无语法差异，但解析行为有细微差别

SELECT ... FOR JSON 和 SELECT ... FOR XML 语法完全相同，但底层 JSON 解析器在 2022 中对非法 Unicode 字符（如 surrogate pairs 不配对）更严格，可能在 2019 中静默截断，在 2022 中直接报 Msg 13609 错误。