1. 项目概述为什么我们需要关注SQL Server的注释信息在数据库开发和维护的日常工作中我们经常面对成百上千张表和字段。时间一长当初设计表时清晰的思路可能就变成了一堆难以理解的缩写和代号。比如你看到一张表叫CUST_ACCT里面有个字段叫LST_UPD_TMSTP你能立刻反应过来这是“客户账户表”和“最后更新时间戳”吗如果不能那么查询和理解这些表和字段的注释就成了高效工作的关键第一步。SQL Server 本身提供了存储这些“元数据”的系统视图允许我们为表、列等对象添加描述性的注释。这些注释就像是贴在数据库对象上的便利贴记录了它的业务含义、特殊规则或维护历史。然而SQL Server 并没有像某些数据库如MySQL的SHOW CREATE TABLE那样提供一个直观的命令来直接展示所有注释。我们需要通过查询特定的系统目录视图来获取这些信息。掌握查询表注释和字段注释的方法不仅仅是写几条SQL语句那么简单。它直接关系到团队协作的效率、新人的上手速度、以及系统文档的完整性。尤其是在进行数据血缘分析、生成数据字典、或者排查一些因字段含义模糊导致的业务逻辑错误时能快速、准确地查询到注释信息往往能节省大量沟通和猜测的时间。接下来我将拆解几种最常用、最稳定的查询方法并分享一些在实际项目中积累的实操技巧和避坑指南。2. 核心系统视图解析sys.extended_properties在 SQL Server 中注释、描述等扩展属性并非存储在普通的用户表中而是通过一个名为sys.extended_properties的系统视图进行统一管理。理解这个视图的结构是我们精准查询注释的基础。2.1sys.extended_properties视图结构详解这个视图可以看作是 SQL Server 内部的一个“属性登记簿”。每一条记录都代表附加在某个数据库对象上的一个名值对Name-Value Pair。它的几个关键字段决定了我们如何定位想要的注释class: 对象的大类。对于我们关心的注释最常见的是1表示对象是表或视图和2表示对象是表的列。其他值还有用于数据库本身、架构、约束等。class_desc: 对class的文字描述如‘OBJECT_OR_COLUMN’。major_id: 这是对象的主体标识符。当class1对象或列时major_id对应的是sys.objects视图中的object_id。也就是说它指向的是表或视图本身的ID。minor_id: 次要标识符。当class1且对象是表时如果属性是表级别的minor_id为0如果属性是列级别的那么minor_id对应的是sys.columns视图中的column_id。这是区分表注释和字段注释的关键。name: 扩展属性的名称。SQL Server 有一个预定义的属性名叫做‘MS_Description’这正是我们通过 SQL Server Management Studio (SSMS) 的图形界面添加表或列描述时系统默认使用的名称。当然你也可以创建自定义名称的属性。value: 扩展属性的值也就是我们存储的注释文本本身是sql_variant类型通常我们将其转换为nvarchar。理解major_id和minor_id的配合是核心。简单来说通过major_id找到表再通过minor_id是否为0来判断这个属性是挂在表上还是挂在表的某个具体列上。2.2 添加注释的标准方法在深入查询之前我们也需要知道注释是如何被正确添加进去的因为错误的方法会导致查询不到。标准方法是通过系统存储过程sp_addextendedproperty。为表添加注释EXEC sp_addextendedproperty name N‘MS_Description’, value N‘这是一张存储客户基本信息的表’, level0type N‘SCHEMA‘ level0name N‘dbo’, level1type N‘TABLE’ level1name N‘Customer’;这里的level0type和level0name指定了架构SCHEMAlevel1type和level1name指定了表TABLE。注意如果表不在默认的dbo架构下必须正确指定架构名否则会报错找不到对象。为字段添加注释EXEC sp_addextendedproperty name N‘MS_Description’, value N‘客户的唯一标识符由系统自动生成’, level0type N‘SCHEMA‘ level0name N‘dbo’, level1type N‘TABLE’ level1name N‘Customer’, level2type N‘COLUMN’ level2name N‘CustomerID’;为字段添加注释需要多指定一个层级level2type和level2name用于定位到具体的列。注意很多开发者喜欢直接在 SSMS 的图形界面中在表设计视图的“属性”窗口里填写“说明”。这本质上就是调用了sp_addextendedproperty存储过程将值存入了sys.extended_properties且name‘MS_Description’。因此两种方式是等价的。3. 实战查询获取特定表的所有注释信息了解了底层原理我们来实战。最常见的场景是我想看看Customer这张表本身以及它所有字段的注释。这需要我们将sys.extended_properties、sys.objects或sys.tables以及sys.columns这几个视图关联起来。3.1 关联查询脚本详解下面这个查询脚本是经过多年实践验证的“标准答案”它清晰地将表注释和字段注释合并在一张结果集里并且包含了对象名和字段名非常直观。SELECT SCHEMA_NAME(t.schema_id) AS [SchemaName], t.name AS [TableName], c.name AS [ColumnName], CASE WHEN ep.minor_id 0 THEN ‘TABLE‘ ELSE ‘COLUMN‘ END AS [PropertyType], ep.name AS [PropertyName], CAST(ep.value AS NVARCHAR(500)) AS [Description] FROM sys.tables t LEFT JOIN sys.extended_properties ep ON ep.major_id t.object_id AND ep.class 1 -- OBJECT_OR_COLUMN AND ep.name ‘MS_Description‘ -- 我们只关心描述属性 LEFT JOIN sys.columns c ON ep.major_id c.object_id AND ep.minor_id c.column_id WHERE t.name ‘Customer‘ -- 指定表名也可以去掉此条件查询所有表 AND SCHEMA_NAME(t.schema_id) ‘dbo‘ -- 指定架构名避免同名表冲突 ORDER BY t.name, CASE WHEN ep.minor_id 0 THEN 0 ELSE 1 END, -- 让表注释排在第一行 c.column_id; -- 按字段原始顺序排列脚本逻辑拆解主表我们从sys.tables开始获取所有用户表或通过WHERE条件过滤出目标表。关联注释第一次LEFT JOIN sys.extended_properties关联条件是ep.major_id t.object_id并且限制ep.class1和ep.name‘MS_Description’。这样我们就拿到了与Customer表相关的所有描述属性。关联字段名第二次LEFT JOIN sys.columns关联条件更精细ep.major_id c.object_id AND ep.minor_id c.column_id。这个条件非常关键对于表注释ep.minor_id 0这个条件无法匹配到sys.columns中的任何记录因此c.name为NULLPropertyType我们标记为 ‘TABLE‘。对于字段注释ep.minor_id 0这个条件能精确匹配到该表下对应的列从而获取到字段名c.namePropertyType标记为 ‘COLUMN‘。结果呈现通过CASE语句区分类型并将ep.value转换为可读的NVARCHAR。执行这个查询你会得到类似下面的结果SchemaNameTableNameColumnNamePropertyTypePropertyNameDescriptiondboCustomerNULLTABLEMS_Description这是一张存储客户基本信息的表dboCustomerCustomerIDCOLUMNMS_Description客户的唯一标识符由系统自动生成dboCustomerCustomerNameCOLUMNMS_Description客户的注册名称………………3.2 查询所有表的注释信息如果我们需要为整个数据库生成数据字典只需简单移除上述脚本中的WHERE条件即可。但这里有一个非常重要的实操心得对于大型数据库表数量超过1000张直接全库关联查询可能会对系统视图造成一定压力在繁忙的生产环境需谨慎。建议在业务低峰期执行或者先查询特定的架构WHERE t.schema_id SCHEMA_ID(‘Sales’)。另外你可以调整查询将结果以更友好的方式呈现例如一行表注释下面跟着它的所有字段注释这通常需要在报表工具或应用程序层进行格式化处理。4. 进阶技巧与常见问题排查掌握了基础查询后在实际项目中我们还会遇到一些更复杂的情况和棘手的坑。下面分享几个进阶技巧和问题排查实录。4.1 查询视图View的注释视图的注释查询方法与表完全一致因为视图也作为一种“对象”存储在sys.objects中其type‘V’。你只需要将上面脚本中的FROM sys.tables t替换为FROM sys.views v或者更通用地使用FROM sys.objects o WHERE o.type IN (‘U‘ ‘V‘)来同时查询表和视图。关联逻辑完全不变。这引出了一个与网络热词相关的问题“视图可以加快查询速度吗”视图本身并不直接加快查询速度它是一个存储的查询定义。查询视图时数据库还是会去执行其底层的基础查询。它的主要价值在于简化复杂查询、提供逻辑抽象层和权限控制。而为视图及其列添加清晰的注释对于理解这个逻辑抽象层至关重要。4.2 处理 NULL 值与缺失注释在查询结果中你可能会看到很多Description为NULL的行。这有两种情况该表或字段确实没有添加MS_Description属性。该属性存在但value被显式地设置为了NULL。我们的查询使用了LEFT JOIN所以即使没有注释表和字段的基本信息也会被列出。这对于生成一个完整的、标注了哪些对象缺少文档的数据字典非常有用。你可以修改查询使用WHERE ep.value IS NOT NULL来只筛选出有注释的对象。4.3 权限问题与执行错误当你执行查询或sp_addextendedproperty时可能会遇到权限错误。记住查询系统视图通常需要一定的权限。对于sys.extended_properties用户至少需要对对象具有VIEW DEFINITION权限。而修改添加/更新/删除扩展属性则需要是对象的所有者或者具有ALTER权限。一个常见的错误是“对象 ‘dbo.Customer‘ 不存在或您没有所需的权限。” 这通常发生在执行sp_addextendedproperty时指定的架构名或对象名不正确或者当前用户确实没有在该对象上的ALTER权限。务必仔细检查level0name架构名和level1name对象名的拼写和大小写如果数据库是大小写敏感的。4.4 性能优化与脚本封装对于需要频繁查询注释的场景例如集成到CI/CD流程中自动生成文档可以考虑将查询脚本封装成视图或存储过程。创建一个视图vTableColumnDescription可以简化后续的查询。但要注意在超大型数据库上对系统视图的复杂查询也可能成为性能瓶颈。虽然系统视图通常有索引但在极端情况下直接查询sys.extended_properties全表可能不如预期快。如果遇到性能问题可以尝试为查询添加更精确的过滤条件如按架构、按表名前缀。在非高峰时段执行。将结果缓存到临时表或物理表中供应用程序使用。5. 扩展应用构建数据字典与元数据管理查询注释不仅仅是解决眼前“这个字段什么意思”的问题更是进行有效元数据管理的基础。我们可以基于此构建更强大的工具。5.1 自动生成数据字典文档你可以将第3节的查询脚本进行扩展连接更多的系统视图如sys.types获取字段数据类型sys.indexes获取索引信息生成一个包含表名、字段名、数据类型、是否为空、默认值、主键/外键信息和描述注释的完整数据字典。这个结果集可以直接导出为Excel、CSV或者用PowerBI、Python脚本渲染成HTML网页形成一份活的、可随时同步的数据库文档。这对于新员工入职、业务人员理解数据模型、以及系统间数据交互的对接价值巨大。我曾经在一个遗留系统重构项目中就是通过这种方式快速梳理出了核心的200多张表的结构和业务含义为后续设计提供了坚实基础。5.2 集成到开发流程中将注释检查集成到开发流程中是提升代码此处是库结构质量的好方法。例如可以在Git的pre-commit钩子中或者CI/CD流水线里加入一个检查脚本。这个脚本检查新增或修改的表、字段是否包含了MS_Description属性。如果没有则发出警告甚至阻止合并请求。这能强制培养团队编写注释的良好习惯。5.3 对比与同步脚本在多环境开发、测试、生产部署时有时表结构的注释可能不同步。你可以编写一个对比脚本分别连接两个数据库比较同一张表的注释差异。甚至可以编写一个自动同步脚本将开发环境中完善的注释更新到测试或生产环境中去。但切记对生产环境的任何修改都必须经过严格的审批和备份流程。最后关于网络热词中提到的“慢查询日志”虽然与本文主题不直接相关但我想提一句清晰的表名和字段名注释对于DBA或开发者分析慢查询日志、理解复杂SQL的执行计划同样有间接帮助。当你看到执行计划中一个陌生的表或索引时如果能快速查到它的业务含义对优化方向的判断会更有把握。查询SQL Server的表和字段注释是一项看似简单却极其重要的基本功。它连接了冰冷的数据库结构与温热的业务逻辑。花点时间为你负责的数据库对象添加上有意义的注释并在团队中推广这一实践长远来看这笔“时间投资”的回报率会非常高。毕竟最好的文档就是那些与代码结构共存亡的注释。
1. 项目概述为什么我们需要关注SQL Server的注释信息在数据库开发和维护的日常工作中我们经常面对成百上千张表和字段。时间一长当初设计表时清晰的思路可能就变成了一堆难以理解的缩写和代号。比如你看到一张表叫CUST_ACCT里面有个字段叫LST_UPD_TMSTP你能立刻反应过来这是“客户账户表”和“最后更新时间戳”吗如果不能那么查询和理解这些表和字段的注释就成了高效工作的关键第一步。SQL Server 本身提供了存储这些“元数据”的系统视图允许我们为表、列等对象添加描述性的注释。这些注释就像是贴在数据库对象上的便利贴记录了它的业务含义、特殊规则或维护历史。然而SQL Server 并没有像某些数据库如MySQL的SHOW CREATE TABLE那样提供一个直观的命令来直接展示所有注释。我们需要通过查询特定的系统目录视图来获取这些信息。掌握查询表注释和字段注释的方法不仅仅是写几条SQL语句那么简单。它直接关系到团队协作的效率、新人的上手速度、以及系统文档的完整性。尤其是在进行数据血缘分析、生成数据字典、或者排查一些因字段含义模糊导致的业务逻辑错误时能快速、准确地查询到注释信息往往能节省大量沟通和猜测的时间。接下来我将拆解几种最常用、最稳定的查询方法并分享一些在实际项目中积累的实操技巧和避坑指南。2. 核心系统视图解析sys.extended_properties在 SQL Server 中注释、描述等扩展属性并非存储在普通的用户表中而是通过一个名为sys.extended_properties的系统视图进行统一管理。理解这个视图的结构是我们精准查询注释的基础。2.1sys.extended_properties视图结构详解这个视图可以看作是 SQL Server 内部的一个“属性登记簿”。每一条记录都代表附加在某个数据库对象上的一个名值对Name-Value Pair。它的几个关键字段决定了我们如何定位想要的注释class: 对象的大类。对于我们关心的注释最常见的是1表示对象是表或视图和2表示对象是表的列。其他值还有用于数据库本身、架构、约束等。class_desc: 对class的文字描述如‘OBJECT_OR_COLUMN’。major_id: 这是对象的主体标识符。当class1对象或列时major_id对应的是sys.objects视图中的object_id。也就是说它指向的是表或视图本身的ID。minor_id: 次要标识符。当class1且对象是表时如果属性是表级别的minor_id为0如果属性是列级别的那么minor_id对应的是sys.columns视图中的column_id。这是区分表注释和字段注释的关键。name: 扩展属性的名称。SQL Server 有一个预定义的属性名叫做‘MS_Description’这正是我们通过 SQL Server Management Studio (SSMS) 的图形界面添加表或列描述时系统默认使用的名称。当然你也可以创建自定义名称的属性。value: 扩展属性的值也就是我们存储的注释文本本身是sql_variant类型通常我们将其转换为nvarchar。理解major_id和minor_id的配合是核心。简单来说通过major_id找到表再通过minor_id是否为0来判断这个属性是挂在表上还是挂在表的某个具体列上。2.2 添加注释的标准方法在深入查询之前我们也需要知道注释是如何被正确添加进去的因为错误的方法会导致查询不到。标准方法是通过系统存储过程sp_addextendedproperty。为表添加注释EXEC sp_addextendedproperty name N‘MS_Description’, value N‘这是一张存储客户基本信息的表’, level0type N‘SCHEMA‘ level0name N‘dbo’, level1type N‘TABLE’ level1name N‘Customer’;这里的level0type和level0name指定了架构SCHEMAlevel1type和level1name指定了表TABLE。注意如果表不在默认的dbo架构下必须正确指定架构名否则会报错找不到对象。为字段添加注释EXEC sp_addextendedproperty name N‘MS_Description’, value N‘客户的唯一标识符由系统自动生成’, level0type N‘SCHEMA‘ level0name N‘dbo’, level1type N‘TABLE’ level1name N‘Customer’, level2type N‘COLUMN’ level2name N‘CustomerID’;为字段添加注释需要多指定一个层级level2type和level2name用于定位到具体的列。注意很多开发者喜欢直接在 SSMS 的图形界面中在表设计视图的“属性”窗口里填写“说明”。这本质上就是调用了sp_addextendedproperty存储过程将值存入了sys.extended_properties且name‘MS_Description’。因此两种方式是等价的。3. 实战查询获取特定表的所有注释信息了解了底层原理我们来实战。最常见的场景是我想看看Customer这张表本身以及它所有字段的注释。这需要我们将sys.extended_properties、sys.objects或sys.tables以及sys.columns这几个视图关联起来。3.1 关联查询脚本详解下面这个查询脚本是经过多年实践验证的“标准答案”它清晰地将表注释和字段注释合并在一张结果集里并且包含了对象名和字段名非常直观。SELECT SCHEMA_NAME(t.schema_id) AS [SchemaName], t.name AS [TableName], c.name AS [ColumnName], CASE WHEN ep.minor_id 0 THEN ‘TABLE‘ ELSE ‘COLUMN‘ END AS [PropertyType], ep.name AS [PropertyName], CAST(ep.value AS NVARCHAR(500)) AS [Description] FROM sys.tables t LEFT JOIN sys.extended_properties ep ON ep.major_id t.object_id AND ep.class 1 -- OBJECT_OR_COLUMN AND ep.name ‘MS_Description‘ -- 我们只关心描述属性 LEFT JOIN sys.columns c ON ep.major_id c.object_id AND ep.minor_id c.column_id WHERE t.name ‘Customer‘ -- 指定表名也可以去掉此条件查询所有表 AND SCHEMA_NAME(t.schema_id) ‘dbo‘ -- 指定架构名避免同名表冲突 ORDER BY t.name, CASE WHEN ep.minor_id 0 THEN 0 ELSE 1 END, -- 让表注释排在第一行 c.column_id; -- 按字段原始顺序排列脚本逻辑拆解主表我们从sys.tables开始获取所有用户表或通过WHERE条件过滤出目标表。关联注释第一次LEFT JOIN sys.extended_properties关联条件是ep.major_id t.object_id并且限制ep.class1和ep.name‘MS_Description’。这样我们就拿到了与Customer表相关的所有描述属性。关联字段名第二次LEFT JOIN sys.columns关联条件更精细ep.major_id c.object_id AND ep.minor_id c.column_id。这个条件非常关键对于表注释ep.minor_id 0这个条件无法匹配到sys.columns中的任何记录因此c.name为NULLPropertyType我们标记为 ‘TABLE‘。对于字段注释ep.minor_id 0这个条件能精确匹配到该表下对应的列从而获取到字段名c.namePropertyType标记为 ‘COLUMN‘。结果呈现通过CASE语句区分类型并将ep.value转换为可读的NVARCHAR。执行这个查询你会得到类似下面的结果SchemaNameTableNameColumnNamePropertyTypePropertyNameDescriptiondboCustomerNULLTABLEMS_Description这是一张存储客户基本信息的表dboCustomerCustomerIDCOLUMNMS_Description客户的唯一标识符由系统自动生成dboCustomerCustomerNameCOLUMNMS_Description客户的注册名称………………3.2 查询所有表的注释信息如果我们需要为整个数据库生成数据字典只需简单移除上述脚本中的WHERE条件即可。但这里有一个非常重要的实操心得对于大型数据库表数量超过1000张直接全库关联查询可能会对系统视图造成一定压力在繁忙的生产环境需谨慎。建议在业务低峰期执行或者先查询特定的架构WHERE t.schema_id SCHEMA_ID(‘Sales’)。另外你可以调整查询将结果以更友好的方式呈现例如一行表注释下面跟着它的所有字段注释这通常需要在报表工具或应用程序层进行格式化处理。4. 进阶技巧与常见问题排查掌握了基础查询后在实际项目中我们还会遇到一些更复杂的情况和棘手的坑。下面分享几个进阶技巧和问题排查实录。4.1 查询视图View的注释视图的注释查询方法与表完全一致因为视图也作为一种“对象”存储在sys.objects中其type‘V’。你只需要将上面脚本中的FROM sys.tables t替换为FROM sys.views v或者更通用地使用FROM sys.objects o WHERE o.type IN (‘U‘ ‘V‘)来同时查询表和视图。关联逻辑完全不变。这引出了一个与网络热词相关的问题“视图可以加快查询速度吗”视图本身并不直接加快查询速度它是一个存储的查询定义。查询视图时数据库还是会去执行其底层的基础查询。它的主要价值在于简化复杂查询、提供逻辑抽象层和权限控制。而为视图及其列添加清晰的注释对于理解这个逻辑抽象层至关重要。4.2 处理 NULL 值与缺失注释在查询结果中你可能会看到很多Description为NULL的行。这有两种情况该表或字段确实没有添加MS_Description属性。该属性存在但value被显式地设置为了NULL。我们的查询使用了LEFT JOIN所以即使没有注释表和字段的基本信息也会被列出。这对于生成一个完整的、标注了哪些对象缺少文档的数据字典非常有用。你可以修改查询使用WHERE ep.value IS NOT NULL来只筛选出有注释的对象。4.3 权限问题与执行错误当你执行查询或sp_addextendedproperty时可能会遇到权限错误。记住查询系统视图通常需要一定的权限。对于sys.extended_properties用户至少需要对对象具有VIEW DEFINITION权限。而修改添加/更新/删除扩展属性则需要是对象的所有者或者具有ALTER权限。一个常见的错误是“对象 ‘dbo.Customer‘ 不存在或您没有所需的权限。” 这通常发生在执行sp_addextendedproperty时指定的架构名或对象名不正确或者当前用户确实没有在该对象上的ALTER权限。务必仔细检查level0name架构名和level1name对象名的拼写和大小写如果数据库是大小写敏感的。4.4 性能优化与脚本封装对于需要频繁查询注释的场景例如集成到CI/CD流程中自动生成文档可以考虑将查询脚本封装成视图或存储过程。创建一个视图vTableColumnDescription可以简化后续的查询。但要注意在超大型数据库上对系统视图的复杂查询也可能成为性能瓶颈。虽然系统视图通常有索引但在极端情况下直接查询sys.extended_properties全表可能不如预期快。如果遇到性能问题可以尝试为查询添加更精确的过滤条件如按架构、按表名前缀。在非高峰时段执行。将结果缓存到临时表或物理表中供应用程序使用。5. 扩展应用构建数据字典与元数据管理查询注释不仅仅是解决眼前“这个字段什么意思”的问题更是进行有效元数据管理的基础。我们可以基于此构建更强大的工具。5.1 自动生成数据字典文档你可以将第3节的查询脚本进行扩展连接更多的系统视图如sys.types获取字段数据类型sys.indexes获取索引信息生成一个包含表名、字段名、数据类型、是否为空、默认值、主键/外键信息和描述注释的完整数据字典。这个结果集可以直接导出为Excel、CSV或者用PowerBI、Python脚本渲染成HTML网页形成一份活的、可随时同步的数据库文档。这对于新员工入职、业务人员理解数据模型、以及系统间数据交互的对接价值巨大。我曾经在一个遗留系统重构项目中就是通过这种方式快速梳理出了核心的200多张表的结构和业务含义为后续设计提供了坚实基础。5.2 集成到开发流程中将注释检查集成到开发流程中是提升代码此处是库结构质量的好方法。例如可以在Git的pre-commit钩子中或者CI/CD流水线里加入一个检查脚本。这个脚本检查新增或修改的表、字段是否包含了MS_Description属性。如果没有则发出警告甚至阻止合并请求。这能强制培养团队编写注释的良好习惯。5.3 对比与同步脚本在多环境开发、测试、生产部署时有时表结构的注释可能不同步。你可以编写一个对比脚本分别连接两个数据库比较同一张表的注释差异。甚至可以编写一个自动同步脚本将开发环境中完善的注释更新到测试或生产环境中去。但切记对生产环境的任何修改都必须经过严格的审批和备份流程。最后关于网络热词中提到的“慢查询日志”虽然与本文主题不直接相关但我想提一句清晰的表名和字段名注释对于DBA或开发者分析慢查询日志、理解复杂SQL的执行计划同样有间接帮助。当你看到执行计划中一个陌生的表或索引时如果能快速查到它的业务含义对优化方向的判断会更有把握。查询SQL Server的表和字段注释是一项看似简单却极其重要的基本功。它连接了冰冷的数据库结构与温热的业务逻辑。花点时间为你负责的数据库对象添加上有意义的注释并在团队中推广这一实践长远来看这笔“时间投资”的回报率会非常高。毕竟最好的文档就是那些与代码结构共存亡的注释。
