SQL Server 2019与2022的SELECT语法完全一致，差异在于兼容性级别控制的查询优化行为：如自适应联接、交错执行、基数估计反馈、OFFSET/FETCH执行计划、标量UDF内联及JSON/XML解析严格性等。
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 错误。
- XML 处理同理：
SELECT ... FOR XML PATH('')在 2022 中对嵌套空节点的序列化更规范，旧版可能多出冗余空格或换行 - 这些不是语法错误，而是数据保真度提升——如果你依赖字符串级比对（比如做哈希校验），必须测试实际输出
真正容易被忽略的点：你改了兼容级别，但没检查触发器/视图里嵌套的 SELECT 是否因基数估计变化导致计划回归；或者你升级了实例，却忘了更新 CU 补丁来修复标量 UDF 内联引发的偶发错误。语法没变，但执行路径和稳定性边界已经悄悄移动了。
