SQL Server 2017 图形数据库功能需预先创建节点表（AS NODE）和边缘表（AS EDGE），不可在存储过程中动态创建；存储过程可封装MATCH查询、DML操作及参数化图逻辑，但须规避SQL注入与跨平台兼容性问题。
SQL Server 2017 的图形数据库功能不能直接在普通 CREATE PROCEDURE 中“调用”或“启用”，它是一套独立的建模与查询机制，需配合特定语法和表结构使用。存储过程本身不感知“图”语义，但可以封装基于图的 MATCH 查询、节点/边操作逻辑。
图节点与边缘表必须先显式创建
图形功能不是开关式特性，而是依赖两类特殊表：节点表（带 AS NODE）和边缘表（带 AS EDGE）。这些表不能在存储过程中动态 CREATE TABLE ... AS NODE —— SQL Server 不允许在存储过程里执行含 AS NODE 或 AS EDGE 的 CREATE TABLE 语句，会报错 Incorrect syntax near 'NODE'。
- 必须在存储过程之外，用独立脚本提前建好节点表（如
Person）和边缘表（如Friends） - 节点表主键自动成为
$node_id，不可手动指定；边缘表必须包含$from_id和$to_id列 - 若尝试在存储过程中用动态 SQL 拼接并执行
CREATE TABLE ... AS NODE，仍会失败 —— 图语法仅在批处理顶层生效
存储过程里能安全使用的图相关操作
一旦图结构就位，存储过程可正常封装以下图查询逻辑：
- 使用
MATCH进行模式匹配，例如：SELECT p1.name FROM Person p1, Friends f, Person p2 WHERE MATCH(p1-(f)->p2) AND p2.name = @target - 对节点表或边缘表做
INSERT/UPDATE/DELETE（注意：插入边缘表时必须显式提供$from_id和$to_id值，不能只写业务字段） - 把
MATCH查询结果存入临时表或表变量，供后续 T-SQL 处理 - 接受参数（如起点 ID、关系类型）并拼入
MATCH子句 —— 但禁止用参数拼接图结构名（如表名），否则触发 SQL 注入风险
常见错误：混淆图语法与普通 JOIN
开发者常误以为 MATCH 是 JOIN 的替代写法，试图在存储过程中混用两者逻辑。实际区别很关键：
-
MATCH只能在图表间使用，且路径表达式（如p1-(f)->p2）是原子语法，不能拆解为条件子句 - 无法在
WHERE中对$edge_id或$node_id做函数运算（如LEFT($node_id, 5)），SQL Server 会报Invalid column name '$node_id' - 边缘表上的非图字段（如
since年份）可参与过滤，但必须放在MATCH外的WHERE子句中，而非嵌在MATCH内部
真正容易被忽略的是：图功能在 SQL Server 2017 中默认可用，但 Azure SQL 数据库直到 2020 年后才逐步支持，且 Microsoft Fabric 中的 SQL 数据库完全不支持图语法 —— 如果你的存储过程要跨平台复用，MATCH 必须作为可选分支存在，不能成为主干逻辑。
