SQL Server 创建主XML索引必须先在表上定义主键或唯一非空约束，因XML索引依赖唯一稳定的行定位器；二级索引按查询模式选PATH（固定路径）、VALUE（任意路径值）或PROPERTY（属性+主键绑定），且需权衡读写性能。
SQL Server 中 CREATE PRIMARY XML INDEX 必须先建主键或唯一非空约束
没有主键的表上直接建 XML 索引会报错：Msg 6310, Level 16, State 1: XML index creation failed because the base table does not have a clustered index or a unique nonclustered index on the primary key.
这是因为 SQL Server 的 XML 索引底层依赖行定位器（row locator），而该定位器必须能唯一、稳定地指向某一行——只有主键或唯一非空索引才能提供这种保证。
- 主键不是可选，是硬性前提；即使表有
IDENTITY列也不行，必须显式定义PRIMARY KEY或UNIQUE NOT NULL约束 - 聚集索引（
CLUSTERED）优先于非聚集索引，但只要满足“唯一 + 非空”，非聚集也可以支撑 XML 索引 - 如果表已有数据且无主键，别想着绕过：先加约束（可能需处理重复值），再建 XML 索引，顺序不能颠倒
SELECT 查询中用 .value() 比 .query() 更快，但类型必须匹配
XML 列上做标量提取时，.value() 直接返回 SQL 类型值，引擎能走索引；而 .query() 返回 XML 片段，无法利用 XML 索引加速，还会触发额外序列化开销。
常见翻车点是类型声明写错：.value('(/root/id)[1]', 'int') 如果实际 XML 里 id 是字符串或为空，会直接报错 NULL is not allowed as a value for type int，而不是静默转成 NULL。
- 强制指定类型时，确保 XPath 路径确实能取到值，否则加
text()[1]或用xs:integer?（XQuery 类型）更稳妥 - 对不确定是否存在的节点，优先用
.value('(/root/optional)[1]', 'varchar(50)')—— SQL Server 会自动转NULL，不报错 - 别在
WHERE子句里对 XML 列用.exist()做高基数过滤：它不走主 XML 索引，性能和全表扫描差不多
二级 XML 索引（PATH/VALUE/PROPERTY）选哪个取决于查询模式
主 XML 索引本身不加速具体路径查询，只是为二级索引打基础。选哪种二级索引，得看你最常怎么查 XML 内容。
-
PATH索引适合固定路径查询，比如总是查/order/item/price，它把路径哈希+值一起存，.value()和.exist()都能命中 -
VALUE索引适合“查某个值出现在任意路径下”，比如找所有含"Urgent"的节点，但没法加速带路径的.value() -
PROPERTY索引只在已知 XML 结构固定、且常用“按 ID 查整条记录”时有用，比如WHERE xmlcol.value('(/doc/@id)[1]', 'int') = 123，它把属性值和主键绑定存储 - 别同时建多个二级索引：每个都会增加 INSERT/UPDATE 开销，且它们不共享数据，磁盘和内存占用是叠加的
XML 索引会让 UPDATE 变慢，尤其批量更新时
每次更新 XML 列，SQL Server 不仅要改原数据，还要同步维护主索引和所有二级索引的 B 树结构。实测显示：单行 UPDATE XML 列耗时可能增加 3–5 倍；批量更新 1000 行时，若没关索引，可能比关掉后慢一个数量级。
- 大批量导入或清洗 XML 数据前，先
DROP INDEX主 XML 索引和所有二级索引，操作完再重建 - 日常业务中避免高频更新 XML 列——考虑拆成关系型字段，XML 只存真正需要树形结构的部分
- 监控
sys.dm_db_index_usage_stats里的user_seeks和user_updates，如果后者远高于前者，说明索引收益远低于维护成本
XML 索引不是银弹，它把查询代价转移到了写入端，而且对半结构化程度高、路径多变的数据效果很有限。真要优化，先确认你是不是非得用 XML 列存，而不是把 JSON 或规范化字段当成备选方案忽略掉了。
