企业官网建设流程全解析

1. 刚接手老库那天，我才知道SQL Server的注释不是写在建表语句里的

如果你被叫去整理一个跑了七八年的SQL Server数据库，打开设计表页面，发现几十张表、几百个字段全靠开发时的记忆硬撑，字段名全是缩写——UserNm、CreDt、UpdBy——你大概率会和我当初一样，先骂一句“为什么没有注释”，然后才开始认真研究怎么给SQL Server数据库表字段添加注释SQL。

表字段注释这件事，SQL Server和MySQL完全是两套逻辑。MySQL的字段注释直接写在列定义里，导出建表脚本就能看到；SQL Server却把它存在另一套叫“扩展属性（Extended Properties）”的元数据机制里，靠sp_addextendedproperty、sp_updateextendedproperty、sp_dropextendedproperty三个存储过程分别完成添加、修改、删除。这篇就把这套机制完整讲透，从底层原理到直接可复制的SQL，再带上执行演示和踩坑总结，适合正在补数据字典、做系统交接、或者被领导要求“把所有字段说明补上”的同学。

1.1 字段注释的本质：扩展属性，一个独立的元数据层

很多从MySQL转过来的人，第一反应是在ALTER TABLE里写COMMENT = '说明'，结果发现SQL Server压根不认。原因很简单：SQL Server从2000版本开始就设计了扩展属性机制，数据库里几乎所有对象——数据库本身、架构、表、列、索引、约束、存储过程参数——都可以挂上自定义属性。字段注释，本质上就是给某个字段挂了一条名为MS_Description的扩展属性，值是你的注释文字。

打个比方，MySQL是把说明印在快递盒上，而SQL Server是给快递盒额外贴了一张标签。快递盒（表结构）本身没变，标签（扩展属性）贴在盒子外面。所以你会看到一个奇怪现象：用SELECT * FROM 表查不到注释，用sp_help看字段信息也不显示，但SSMS设计表界面的“说明”栏里却有文字。如果不了解这套机制，你会以为注释根本不存在。

扩展属性底层存在sys.extended_properties系统视图里，添加一条属性本质是往这个视图对应的系统表插一条记录。属性值类型是sql_variant，可以存字符串、数字、日期，但在字段注释场景下基本都存字符串。属性名理论上可以随便起，只是SSMS和数据字典工具都约定俗成用MS_Description，中文版SSMS里的“说明”栏就是它。

1.2 四级定位：数据库、架构、表、字段

要操作扩展属性，必须先能准确“定位”到目标对象。SQL Server扩展属性支持四个层级，从粗到细是：数据库级别（level0）、架构级别（level1）、对象级别（level2），再往下还有对象内的成员级别（level3）。但在表字段注释场景里，我们实际用到的是三个层级：SCHEMA（架构）、TABLE（表）、COLUMN（列）。

所以每次执行添加注释的SQL，都要重复写一遍从架构到表的完整路径。举个例子：给dbo.Users表的Id字段加注释，在存储过程里需要写@level0type = N'SCHEMA', @level0name = N'dbo'、@level1type = N'TABLE', @level1name = N'Users'、@level2type = N'COLUMN', @level2name = N'Id'。一个都不能省，因为只有把这几个定位参数组合起来，才能精确锁定“哪个架构下、哪张表、哪个字段”。

这套四级定位也是后来批量生成注释脚本的基础。理解了它，你看到一大串参数就不会晕，无非是从粗到细告诉数据库你要找谁。

1.3 和MySQL、Oracle的直观对比

为了让你对这套机制印象更深，我列个简单对比。MySQL的字段注释在information_schema.columns的COLUMN_COMMENT字段里，写在列定义中，迁移时跟着建表语句走；Oracle的字段注释用COMMENT ON COLUMN 表.字段 IS '说明'，是独立于表结构之外的对象；SQL Server则用扩展属性体系。

三者思路完全不同，没有谁对谁错，但SQL Server的扩展属性显然更灵活——你能自定义属性名。比如除了MS_Description，我还会用Owner属性标记字段负责人、用SourceSystem标记数据来源，这在后面做数据治理时非常实用。只是大部分人只用了它最基础的能力：存注释。

2. 给字段加注释：sp_addextendedproperty用法拆解

先从最常用的添加注释说起。存储过程名字比较长，但参数规律性很强，学会一个就能举一反三。

2.1 完整语法逐参数拆解

EXEC sys.sp_addextendedproperty @name = N'MS_Description', @value = N'用户ID，主键自增', @level0type = N'SCHEMA', @level0name = N'dbo', @level1type = N'TABLE', @level1name = N'Users', @level2type = N'COLUMN', @level2name = N'Id';

各参数含义如下：

注意@level0type和@level1type不是每次都必须写。如果只给数据库本身加注释，后面全不写；给表加注释时写到@level1type为止；给字段加注释时到底，三级全齐。参数顺序必须从粗到细，且每级type和name成对出现，不能跨级跳。

2.2 一次给一张表的所有字段补上注释

实际工作中没人一个字段一个字段手敲，通常是拿到表结构后批量写。我拿一个精简版用户表举例，你直接复制改表名字段名就能用：

-- 假设已经有这张表 CREATE TABLE dbo.Users ( Id INT IDENTITY(1,1) NOT NULL, UserName NVARCHAR(50) NOT NULL, Email NVARCHAR(100) NULL, CreatedAt DATETIME2(3) NOT NULL ); GO -- 给Id字段加注释 EXEC sys.sp_addextendedproperty @name = N'MS_Description', @value = N'用户主键，自增ID', @level0type = N'SCHEMA', @level0name = N'dbo', @level1type = N'TABLE', @level1name = N'Users', @level2type = N'COLUMN', @level2name = N'Id'; -- 给UserName字段加注释 EXEC sys.sp_addextendedproperty @name = N'MS_Description', @value = N'用户名，登录账号', @level0type = N'SCHEMA', @level0name = N'dbo', @level1type = N'TABLE', @level1name = N'Users', @level2type = N'COLUMN', @level2name = N'UserName'; -- 给Email字段加注释 EXEC sys.sp_addextendedproperty @name = N'MS_Description', @value = N'邮箱，可为空', @level0type = N'SCHEMA', @level0name = N'dbo', @level1type = N'TABLE', @level1name = N'Users', @level2type = N'COLUMN', @level2name = N'Email'; -- 给CreatedAt字段加注释 EXEC sys.sp_addextendedproperty @name = N'MS_Description', @value = N'创建时间', @level0type = N'SCHEMA', @level0name = N'dbo', @level1type = N'TABLE', @level1name = N'Users', @level2type = N'COLUMN', @level2name = N'CreatedAt';

写到这里你可能会问：每个字段之间需不需要用GO隔开？我的经验是，在SSMS里一起选中执行没问题，但如果某个语句报错，错误定位会稍微费点眼。习惯上我会在每条EXEC之间加GO，让脚本独立提交，也方便排查问题。

2.3 关于@name和@value，几个容易翻车的细节

第一，@value类型是sql_variant，直接传字符串没问题，但不要传NULL。传NULL确实能把属性建出来，只是值为空，等于注释了个寂寞。如果注释内容含数字，比如@value = 100，会被当成int存进去，显示时可能没有类型问题，但为了统一，我建议一律用N'...'字符串形式，避免类型混用。

第二，@name虽然理论上可自定义，但和SSMS界面联动的只有MS_Description。你起个Remark名字，SSMS设计表里不会显示，数据字典工具也读不到。如果不是做自定义元数据，老老实实用MS_Description。

第三，存储过程名我习惯写sys.sp_addextendedproperty，带上sys.前缀，避免某些数据库里出现同名用户存储过程导致执行错对象。这个习惯救过我一次——有套老系统里真有开发建了个sp_addextendedproperty自定义过程，不带前缀执行直接调错。

第四，也是最容易踩的：同一字段同一属性名重复添加，会直接报错“数据库中已存在名称为'MS_Description'的属性”。SQL Server的扩展属性没有upsert机制，添加就是添加，你要么先删再加，要么用修改的存储过程。

3. 修改与删除注释：两个文档里很少强调的坑

添加注释只是第一步，项目运转半年后，字段含义变了、注释写错了、或者干脆不要注释了，这时候就需要修改和删除。

3.1 修改注释：sp_updateextendedproperty

修改注释的存储过程叫sp_updateextendedproperty，参数和添加几乎一模一样，只是语义从“插入”变成了“更新”。

EXEC sys.sp_updateextendedproperty @name = N'MS_Description', @value = N'用户唯一标识，自增ID，不允许为空', @level0type = N'SCHEMA', @level0name = N'dbo', @level1type = N'TABLE', @level1name = N'Users', @level2type = N'COLUMN', @level2name = N'Id';

这里有个大坑：如果目标字段当前并没有MS_Description属性，执行sp_updateextendedproperty会报错“数据库中没有名为'MS_Description'的属性”。你先得确认这个字段之前有没有加过注释。尤其是当你从别的环境拿来一份脚本跑的时候，源库有注释、目标库没有，一执行就挂。

所以我的习惯是：在更新前先查一下有没有这条属性，有则改，没有则添加。后面第4章会给出完整的判断查询。

3.2 删除注释：sp_dropextendedproperty

删除更简单，注意参数里没有@value：

EXEC sys.sp_dropextendedproperty @name = N'MS_Description', @level0type = N'SCHEMA', @level0name = N'dbo', @level1type = N'TABLE', @level1name = N'Users', @level2type = N'COLUMN', @level2name = N'Id';

同样，如果这个字段没有这条属性，删除也会报错。错误消息大概是“数据库中不存在名称为'MS_Description'的属性”。我在自动化脚本里一般先判断再删除，或者干脆在删除语句外面包一层IF EXISTS。

顺带说一下：删除字段注释不会影响表结构和数据，扩展属性是独立元数据，删了也无需担心数据安全。但要注意，如果是字段本身被删了，扩展属性会自动跟着清理；如果是重建表，原来的扩展属性就没了，得重新添加。

3.3 用一条SQL查出现在到底有没有注释

这个查询我几乎每天都用，直接复制即可：

SELECT s.name AS SchemaName, t.name AS TableName, c.name AS ColumnName, ep.value AS Comment FROM sys.tables t INNER JOIN sys.schemas s ON t.schema_id = s.schema_id INNER JOIN sys.columns c ON t.object_id = c.object_id LEFT JOIN sys.extended_properties ep ON ep.class = 1 AND ep.major_id = t.object_id AND ep.minor_id = c.column_id AND ep.name = N'MS_Description' WHERE s.name = N'dbo' AND t.name = N'Users';

返回结果里Comment为NULL的字段表示没有注释。有了这条SQL，你可以在执行修改和删除前先看一眼，也可以在补注释时快速识别哪些字段是漏网之鱼。class = 1表示对象或列级别的扩展属性，major_id是表对象ID，minor_id是列ID——这段过滤逻辑也是第5章批量脚本的基础。

除了手动查sys.extended_properties，SQL Server还内置了fn_listextendedproperty函数，可以按层级递归返回属性列表：

SELECT * FROM fn_listextendedproperty( N'MS_Description', N'SCHEMA', N'dbo', N'TABLE', N'Users', N'COLUMN', N'Id' );

注意这里要传的层级参数是(name, level0type, level0name, level1type, level1name, level2type, level2name)，顺序和存储过程一致。七个参数都能设NULL，设NULL时表示返回该层级以下所有匹配项。我更习惯用sys.extended_properties，因为写JOIN方便，可定制性强。

3.4 SSMS界面里的说明列，背后就是这套存储过程

如果你不想写SQL，SSMS设计表界面也能操作。右键表名→设计，选中列，下方“列属性”面板里有一栏“说明”。填上内容保存后，SQL Server会后台调用扩展属性相关存储过程写入MS_Description属性。

用过几次你就会发现，SSMS这个界面有个问题：如果列没有属性，你直接填写保存，它会执行添加；如果你清空“说明”保存，它会删掉属性。但当你对几十个字段批量编辑时，SSMS会一个字段一个字段地生成ALTER语句和扩展属性语句，执行效率低，还会产生大量无谓的锁和日志。我的习惯是，还在开发阶段的表，直接用SQL脚本维护注释；交付后的维护阶段，偶尔改一两个字段用界面凑合，批量还是靠脚本。

4. 一次跑通的完整演示：建表→注释→修改→删除→再添加

下面给一套完整可复现的演示脚本，包含从建库到最终清理的全流程，你按顺序执行就能看到每个环节的效果。

4.1 完整脚本

USE master; GO -- 如果存在演示库则删除重建 IF DB_ID('CommentDemo') IS NOT NULL BEGIN ALTER DATABASE CommentDemo SET SINGLE_USER WITH ROLLBACK IMMEDIATE; DROP DATABASE CommentDemo; END GO CREATE DATABASE CommentDemo; GO USE CommentDemo; GO -- 1. 建表 CREATE TABLE dbo.Products ( ProductId INT IDENTITY(1,1) NOT NULL, ProductName NVARCHAR(100) NOT NULL, Price DECIMAL(18,2) NULL, Stock INT NULL ); GO -- 2. 添加字段注释 EXEC sys.sp_addextendedproperty @name = N'MS_Description', @value = N'商品主键', @level0type = N'SCHEMA', @level0name = N'dbo', @level1type = N'TABLE', @level1name = N'Products', @level2type = N'COLUMN', @level2name = N'ProductId'; EXEC sys.sp_addextendedproperty @name = N'MS_Description', @value = N'商品名称', @level0type = N'SCHEMA', @level0name = N'dbo', @level1type = N'TABLE', @level1name = N'Products', @level2type = N'COLUMN', @level2name = N'ProductName'; EXEC sys.sp_addextendedproperty @name = N'MS_Description', @value = N'销售单价', @level0type = N'SCHEMA', @level0name = N'dbo', @level1type = N'TABLE', @level1name = N'Products', @level2type = N'COLUMN', @level2name = N'Price'; EXEC sys.sp_addextendedproperty @name = N'MS_Description', @value = N'库存数量', @level0type = N'SCHEMA', @level0name = N'dbo', @level1type = N'TABLE', @level1name = N'Products', @level2type = N'COLUMN', @level2name = N'Stock'; GO -- 3. 查看当前注释 SELECT t.name AS TableName, c.name AS ColumnName, ep.value AS Comment FROM sys.tables t INNER JOIN sys.columns c ON t.object_id = c.object_id LEFT JOIN sys.extended_properties ep ON ep.class = 1 AND ep.major_id = t.object_id AND ep.minor_id = c.column_id AND ep.name = N'MS_Description' WHERE t.name = N'Products' ORDER BY c.column_id; GO -- 4. 修改注释 EXEC sys.sp_updateextendedproperty @name = N'MS_Description', @value = N'商品唯一标识', @level0type = N'SCHEMA', @level0name = N'dbo', @level1type = N'TABLE', @level1name = N'Products', @level2type = N'COLUMN', @level2name = N'ProductId'; GO -- 5. 删除Stock字段的注释 EXEC sys.sp_dropextendedproperty @name = N'MS_Description', @level0type = N'SCHEMA', @level0name = N'dbo', @level1type = N'TABLE', @level1name = N'Products', @level2type = N'COLUMN', @level2name = N'Stock'; GO -- 6. 再次验证 SELECT t.name AS TableName, c.name AS ColumnName, ISNULL(ep.value, N'<无注释>') AS Comment FROM sys.tables t INNER JOIN sys.columns c ON t.object_id = c.object_id LEFT JOIN sys.extended_properties ep ON ep.class = 1 AND ep.major_id = t.object_id AND ep.minor_id = c.column_id AND ep.name = N'MS_Description' WHERE t.name = N'Products' ORDER BY c.column_id;

4.2 验证结果长什么样

第3步执行后，你会看到四行记录，分别对应四个字段的注释。第4步修改后，ProductId的注释从“商品主键”变成“商品唯一标识”。第5步删除后，第6步查询时Stock字段显示为“<无注释>”，其他三个字段正常。

如果你在sp_updateextendedproperty和sp_dropextendedproperty执行前没有先加过对应的注释，会直接报错。第3步就是用来“探路”的，自动化脚本里建议加判断，说明见3.3节和5.2节。

4.3 三张表带你看清添加、修改、删除的参数差异

为了让你直观记住三个存储过程的异同，我把它们放一起对比：

@value那一列是最大的差异点：添加和修改都要传新值，删除则完全不需要传值。很多新手写删除语句时习惯性带上@value，结果报错“过程 expects parameter '@value'，which was not supplied”的反向——其实是没有@value才对的，带上了反而错。这里多说一句：这三个存储过程的参数都支持命名参数和位置参数两种写法，但我不建议用位置参数，因为参数太多，顺序一旦记错就会把@value当成@name用，报错信息还很隐晦。

5. 实战进阶：整库字段注释的批量管理与数据字典生成

单表操作会了，接下来是真正能帮你省下几天的进阶玩法：把整库的注释导成数据字典，以及给“所有没注释的字段”批量生成添加脚本。这两种场景在项目交接和补文档时出现频率极高。

5.1 一条SQL导出整库字段注释

有了第3章的查询基础，去掉WHERE条件里的表名，再关联上表类型过滤，就能得到整个库的字段注释清单：

SELECT s.name AS SchemaName, t.name AS TableName, c.name AS ColumnName, ty.name AS DataType, c.max_length AS MaxLength, c.is_nullable AS IsNullable, CAST(ep.value AS NVARCHAR(MAX)) AS Comment FROM sys.tables t INNER JOIN sys.schemas s ON t.schema_id = s.schema_id INNER JOIN sys.columns c ON t.object_id = c.object_id INNER JOIN sys.types ty ON c.user_type_id = ty.user_type_id LEFT JOIN sys.extended_properties ep ON ep.class = 1 AND ep.major_id = t.object_id AND ep.minor_id = c.column_id AND ep.name = N'MS_Description' ORDER BY s.name, t.name, c.column_id;

这个结果贴到Excel里就是一份最基础的数据字典，包含表名、字段名、数据类型、长度、是否可空、注释。如果想让注释排到第一列，调整SELECT顺序即可。再往深做，还能把主键、外键、索引信息JOIN进来，生成更完整的数据字典，这是后话。

注意CAST(ep.value AS NVARCHAR(MAX))这个写法——ep.value是sql_variant类型，直接导出到Excel时有时显示为二进制或乱码，CAST成字符串最稳。如果你用的是低版本SQL Server，遇到sql_variant转nvarchar报转换错误，可以用CONVERT(NVARCHAR(MAX), ep.value)代替。

5.2 给所有没注释的字段批量生成添加脚本

有些老库整库都没注释，你不可能一个个手敲。用下面这条SQL，自动生成每个字段的sp_addextendedproperty执行语句，你在SSMS里把结果复制出来跑一遍，所有字段注释就全有了——前提是你得先定义好每个字段的注释来源。

这里给两个思路：如果原系统里有过一张字段说明Excel，你可以把Excel导入一张临时表，关联生成；如果没有现成的说明，先批量生成占位注释如N'待补充'，之后再逐步修改。我更推荐后者，至少能保证每个字段都有属性占位，后续用sp_updateextendedproperty逐个更新比从零添加省事得多。

占位注释生成脚本示例如下（其中中文占位内容实际使用时请替换为你的说明文字）：

SELECT N'EXEC sys.sp_addextendedproperty ' + N'@name = N''MS_Description'', ' + N'@value = N''待补充'', ' + N'@level0type = N''SCHEMA'', @level0name = N''' + s.name + N''', ' + N'@level1type = N''TABLE'', @level1name = N''' + t.name + N''', ' + N'@level2type = N''COLUMN'', @level2name = N''' + c.name + N''';' FROM sys.tables t INNER JOIN sys.schemas s ON t.schema_id = s.schema_id INNER JOIN sys.columns c ON t.object_id = c.object_id LEFT JOIN sys.extended_properties ep ON ep.class = 1 AND ep.major_id = t.object_id AND ep.minor_id = c.column_id AND ep.name = N'MS_Description' WHERE ep.value IS NULL ORDER BY s.name, t.name, c.column_id;

这个脚本里有个细节：字符串拼接时外层用N''包裹单引号，因为SQL字符串里的单引号需要用两个单引号转义，所以你会看到N''MS_Description''这种写法。如果我注释内容里本身带了单引号，比如N''用户ID''没问题，但如果是N''It''s a test''，就需要额外处理，这我在第6章专门讲。

5.3 数据库、表、索引也能加注释，思路完全一致

扩展属性不止能用在字段上。给数据库加注释，去掉@level1type及以后参数：

EXEC sys.sp_addextendedproperty @name = N'MS_Description', @value = N'核心业务库，禁止直接修改表结构';

给表加注释，写到@level1type：

EXEC sys.sp_addextendedproperty @name = N'MS_Description', @value = N'商品基础信息表', @level0type = N'SCHEMA', @level0name = N'dbo', @level1type = N'TABLE', @level1name = N'Products';

给索引加注释，@level2type为INDEX：给约束加注释，@level2type为CONSTRAINT。原理都一样，只是定位层级对应的对象类型不同。你在数据治理时如果想给表打上“核心表”“接口表”的标记，完全可以用不同的属性名存储，比如@name = N'TableCategory'。这比新建一张维护表轻量得多。

6. 我踩过的那些关于注释的坑，一次说清楚

功能讲完，把我在真实环境里踩过的坑集中说一说。这些坑不在官方文档里，但几乎每个做数据字典的人都会遇到。

6.1 注释内容里的单引号，必须加倍处理

假设你要写这么一个注释：It's a test。直接拼进SQL里会报语法错误，因为字符串里的单引号把整个字符串截断了。正确写法是把单引号翻倍：

EXEC sys.sp_addextendedproperty @name = N'MS_Description', @value = N'It''s a test', @level0type = N'SCHEMA', @level0name = N'dbo', @level1type = N'TABLE', @level1name = N'Products', @level2type = N'COLUMN', @level2name = N'ProductName';

字符串里的''会被SQL解释成一个单引号。在5.2节的批量生成脚本里，我做法是利用REPLACE函数先把原注释里的单引号替换成两个单引号，再拼进动态SQL，否则生成出来的语句根本没法执行。这个细节在手工维护注释时很容易忽略，尤其是英文注释或者带中英文混合标点的注释。

还有个编码相关的坑：SQL脚本文件如果不是用UTF-8带BOM格式保存，SSMS打开时中文可能直接显示成乱码，执行进数据库后注释也是乱的。我现在的习惯是：所有含中文注释的脚本，一律用UTF-8 with BOM或GBK编码保存，且字符串前统一加N前缀。N表示Unicode字符串，能避免中文在不同数据库排序规则下出现乱码。

6.2 重建表、导入导出、生成脚本时，注释为什么总丢

这是我在一次数据库重构中付出过代价的教训。当时我用SSMS的“生成脚本”功能把整库结构导出来，在另一台服务器上执行建表，跑完发现所有字段注释全部丢失。原因有两个：一是生成脚本向导的“高级选项”里，有一个“编写扩展属性脚本”开关，默认在一些版本里不是全选状态，需要手动勾上“True”；二是如果脚本是从旧库生成后拿到新库执行，库名、架构名对不上，扩展属性定位失败也会静默丢失。

更隐蔽的是SSMS的导入导出向导（Import Data / Export Data），它默认只搬运数据，不搬运扩展属性。你从一个库导数据到另一个库，字段注释不会跟着走。很多人以为表结构一样注释就会在，实际操作完一看，注释全没了。

所以做库迁移时，我的标准流程是：先对比两边表结构，再检查扩展属性，最后迁移数据。结构层对比用sys.columns和sys.extended_properties两个视图联合检查，注释差异用5.1节的查询导出来做Diff。数据迁移完，注释该补的补、该改的改，别指望工具自动帮你搬。

6.3 修改列名或删列后，扩展属性会怎样

这个坑比较绕：如果你用sp_rename修改列名，扩展属性还在，但因为sys.extended_properties里的minor_id关联的是列的内部ID而不是列名，所以新列名仍能看到旧注释。听起来是好事？但反过来，如果注释文本里提到了旧列名，就会产生语义偏差。

比如原来有个字段Remark注释是“备注信息”，你用sp_rename 'Remark', 'Comments'改了列名，注释不会自动变成“Comments信息”。这种“张冠李戴”的情况在维护老库时很常见，数据库不会报错，但数据字典看起来就很尴尬。我遇到过不止一次：字段改名后，注释里还是旧名词，后来做数据治理时不得不全面排查一遍。

如果你删除了某个字段，它的扩展属性会跟着自动清理，这个不用担心。但如果你是“先删列再加同名列”，新列是一个全新的内部ID，旧的注释不会回来，需要重新添加。所以“删列重建”这种操作一旦涉及有注释的字段，务必先把注释脚本留存一份。

6.4 扩展属性还可以做更多事

最后说点扩展性的思考。既然扩展属性是一套通用元数据机制，完全可以不局限于MS_Description。我现在维护的一个系统里，字段上同时挂着三类属性：MS_Description放业务含义，DataOwner放负责岗位，SecurityLevel放敏感级别。查询所有敏感字段时，一条SQL就能把标记了SecurityLevel='L3'的字段全捞出来，配合脱敏工具做自动化处理。

这个能力在做数据标准化、数据血缘、合规审查时都非常好用。你不需要额外建表，不需要写复杂的维护界面，只要在现有表结构上不断添加不同@name的扩展属性就行。当然，前提是团队约定好属性名规范，否则每个人各起各的名字，第二天就乱套。我在项目里会专门维护一份“扩展属性命名规范”文档，比口头约定靠谱得多。

根据我个人这几年的经验，SQL Server字段注释这套机制，真正用顺手之后是越用越离不开的。它不像MySQL那样“天然自带注释”，需要你多了解一层扩展属性，但换来的是远高于M.###（此处删除重复内容）的灵活度。下次再被问“这个字段什么意思”，你可以理直气壮地说：“查一下MS_Description，注释里写得清清楚楚。”