SQL:2023未改变SELECT基础语法与执行逻辑，仅扩展其可操作的数据形态，新增GRAPH TABLE、MATCH_RECOGNIZE及JSON_TABLE等表源类型与函数支持，但SELECT本身保持不变。
SQL:2023 没有改动 SELECT 的基础语法、执行顺序或语义，它不新增 SELECT 关键字本身的功能，也不改变 WHERE、GROUP BY、ORDER BY 等子句的行为。
SQL:2023 新增的是查询能力的“外延”，不是 SELECT 本身的重构
很多人看到“SQL:2023”就默认 SELECT 会变，其实标准演进逻辑很务实：核心 DML（包括 SELECT）在 SQL:1999 后已高度稳定。SQL:2023 的突破点是让 SELECT 能“接入新数据形态”，而不是重写老规则。
- 它新增了
GRAPH TABLE和MATCH_RECOGNIZE的正式支持（后者其实在 SQL:2016 就引入，2023 是强化规范），但这些是独立于SELECT的子句或表构造器，SELECT仍照常引用它们，就像引用普通表一样 -
SELECT查询属性图（PGQ）时，实际靠的是新语法SELECT ... FROM GRAPH TABLE ( ... )，SELECT本身没加新关键字，只是多了个可被FROM引用的新表源类型 - JSON 相关函数（如
JSON_TABLE）升级为“核心特性”，意味着SELECT * FROM JSON_TABLE(...)在所有合规引擎中必须可用——但SELECT的解析逻辑和执行流程完全不变
真正影响你写 SELECT 的，是底层数据类型和函数支持度
如果你在用 PostgreSQL 17、MySQL 8.4 或 SQL Server 2022+，SELECT 语句能写的表达式范围确实扩大了，但这来自引擎实现，不是标准强制。比如：
-
SELECT中可直接用JSON_ARRAY()、JSON_OBJECT()构造值，前提是数据库实现了 SQL:2023 的 JSON 核心支持；旧版本可能只支持JSON_EXTRACT这类有限函数 -
SELECT引用多维数组列（如INT[3][4]）时，下标语法col[1][2]是否合法，取决于引擎是否按 SQL:2023 实现了数组类型——而 Oracle 目前仍不支持该语法 -
SELECT配合MATCH_RECOGNIZE时，模式匹配结果被当作虚拟表暴露给SELECT，但SELECT自身不做模式识别，它只负责投影匹配后的行
容易被忽略的兼容性坑：别把“标准支持”当“开箱即用”
SQL:2023 是纸面标准，落地依赖厂商节奏。目前（2026年7月）真实情况是：
- PostgreSQL 17 声称“部分支持 SQL:2023”，但
GRAPH TABLE仅限扩展插件（如age），原生SELECT FROM GRAPH不可用 - MySQL 8.4 实现了
JSON_TABLE全功能，但MATCH_RECOGNIZE仍未提供——这意味着你不能用SELECT ... MATCH_RECOGNIZE做序列分析，哪怕标准写了 - SQL Server 2022 对 SQL:2023 的响应集中在 JSON 函数增强（如
JSON_VALUE支持路径通配符），但对属性图查询（PGQ）零支持；想用图查询，还得走Cypher或图扩展 - 最隐蔽的坑：
SELECT中调用标准函数时，参数类型检查更严了。例如 SQL:2023 要求LISTAGG必须接受ON OVERFLOW ERROR子句，旧版引擎若忽略该子句，可能静默截断而非报错
真正要改的不是你写 SELECT 的习惯，而是查文档时得确认：你用的那条 SELECT 语句里出现的函数、类型、表构造器，是否被当前数据库版本明确声明支持 SQL:2023 对应条款。
