information_schema.columns足以满足绝大多数基础字段查询需求，但需严格指定table_schema以防跨架构误查；其不包含备注信息，字段备注必须通过left join sys.extended_properties（class=0）获取，且需注意权限与数据库上下文。
直接查 INFORMATION_SCHEMA.COLUMNS 就够用
绝大多数场景下，不需要动 sys 视图或写复杂 JOIN —— INFORMATION_SCHEMA.COLUMNS 是 SQL 标准定义的视图，字段语义清晰、兼容性好、权限要求低，查列名、类型、长度、是否可空这些基础信息，一条语句就能搞定。
常见错误是只写 TABLE_NAME = 'YourTable'，结果跨 schema 查到同名表（比如 sales.Users 和 dbo.Users 都存在），返回混乱数据。务必加上 TABLE_SCHEMA 条件。
- 正确写法：
WHERE TABLE_SCHEMA = 'dbo' AND TABLE_NAME = 'Users' -
CHARACTER_MAXIMUM_LENGTH对int、datetime这类非字符类型返回NULL，别误以为字段没长度定义 -
COLUMN_DEFAULT返回的是默认约束的原始定义字符串，比如(getdate())或('')，不是计算后的值 - 排序必须用
ORDINAL_POSITION，别依赖 <code>COLUMN_NAME字母序——它不反映物理顺序
查不到字段备注？得连 sys.extended_properties
INFORMATION_SCHEMA.COLUMNS 不包含“说明”或“备注”，那是用户通过 SSMS 或 sp_addextendedproperty 手动加的扩展属性，存在 sys.extended_properties 里。想把列名和备注一起查出来，必须 LEFT JOIN。
容易踩的坑是直接 JOIN 后发现大部分列的备注为空——因为 class = 1 表示对象级属性（如表名备注），而字段备注的 class = 0，且 minor_id 必须对应列的 column_id。
- JOIN 条件关键三段：
ep.major_id = c.object_id（表 ID）、ep.minor_id = c.column_id（列 ID）、ep.class = 0（字段级） - 备注内容在
ep.value，但它是sql_variant类型，需显式转成varchar，否则某些客户端显示为乱码或 NULL - 如果某列没设备注，
LEFT JOIN后ep.value是 NULL，别误判为查询失败
sp_help 适合快速人工排查，不适合脚本化
执行 EXEC sp_help 'Users' 确实能一次性看到列、索引、约束、主键、外键全量信息，格式也直观。但它返回多个结果集（不止一列一表），没法直接 SELECT 或 INSERT INTO，也不支持 WHERE 过滤或 ORDER BY。
这意味着：你在 SSMS 里点几下就能看全貌，但写自动化脚本、生成数据字典、对接下游系统时，它基本没法用。
- 返回结果集结构不稳定：SQL Server 版本升级后，
sp_help的输出列名或顺序可能微调 - 无法嵌套在子查询中，也不能作为 CTE 的源
- 如果只想查“哪些列有默认值”，
sp_help会把所有信息混在一起，还得手动筛
别忽略权限和上下文问题
即使语句语法完全正确，也可能查不到数据——根本原因常是权限或数据库上下文不对。
INFORMATION_SCHEMA.COLUMNS 只返回当前用户有 SELECT 权限的表；sys.extended_properties 还要额外有 VIEW DEFINITION 权限。更隐蔽的是：如果你在 master 或 tempdb 里执行，却忘了 USE YourDB，那 INFORMATION_SCHEMA 查的就不是目标库的表。
- 执行前先确认当前数据库：
SELECT DB_NAME() - 检查权限：
HAS_PERMS_BY_NAME('YourTable', 'OBJECT', 'SELECT')返回 1 才能查到该表 - 字段备注若由别人添加，而你没被授予
VIEW DEFINITION，即使表可见，sys.extended_properties也为空
INFORMATION_SCHEMA 提供的是“能查到什么”，不是“应该有什么”。实际用的时候，得先接受这个前提。
