sql server系统视图是映射内部元数据的只读视图，比information_schema更底层完整；查表用sys.tables，查列详情优先sys.columns，查数据库列表必须用sys.databases。
SQL系统视图是数据库内置的只读视图，直接映射内部元数据结构，不是用户创建的普通表。它们是查询数据库“自身信息”的最权威、最实时的入口，比INFORMATION_SCHEMA更底层、更完整，也更依赖具体数据库实现。
SQL Server里怎么查当前数据库有哪些表
用sys.tables最直接可靠，它只返回用户定义的基表（不含视图、系统表）：
-
SELECT name, create_date, is_ms_shipped FROM sys.tables——is_ms_shipped = 0表示非系统表 - 如果要带架构名，必须联查
sys.schemas：SELECT SCHEMA_NAME(t.schema_id) AS schema_name, t.name FROM sys.tables AS t - 注意：不加
WHERE会返回所有表，包括你没权限看到的（但实际执行时无权访问的行会被自动过滤） - 别用
sysobjects——这是兼容性视图，SQL Server 2005起已不推荐，字段命名模糊、缺失关键属性（如max_length）
查某张表的列详情时，sys.columns和INFORMATION_SCHEMA.COLUMNS的区别在哪
核心差异在精度和可扩展性：sys.columns能拿到SQL Server原生类型细节，INFORMATION_SCHEMA.COLUMNS只提供ANSI标准抽象层。
-
sys.columns返回max_length、precision、scale、is_identity、is_computed等真实属性；而INFORMATION_SCHEMA.COLUMNS的CHARACTER_MAXIMUM_LENGTH对int这类类型返回NULL，且没有标识列标记 - 查字段注释？
INFORMATION_SCHEMA.COLUMNS不包含COLUMN_COMMENT，得靠sys.extended_properties关联查 - 跨库迁移脚本时，优先用
INFORMATION_SCHEMA；写SQL Server专用运维脚本时，sys.columns才是主力 - 示例：查
Orders表中是否含计算列：SELECT name, is_computed FROM sys.columns WHERE object_id = OBJECT_ID('Orders')
为什么查数据库列表要用sys.databases而不是INFORMATION_SCHEMA.SCHEMATA
因为INFORMATION_SCHEMA.SCHEMATA只反映“当前数据库可见的schema”，不是服务器级概念；而sys.databases才是SQL Server真正管理数据库实例的元数据源头。
-
SELECT name, state_desc, recovery_model_desc FROM sys.databases能看到数据库是否OFFLINE、RESTORING或SUSPECT——这些状态INFORMATION_SCHEMA根本不暴露 -
sys.databases还提供collation_name、user_access_desc、is_read_only等DBA级配置项 - 若数据库处于
AUTO_CLOSE = ON且未被访问，collation_name可能为NULL——这是真实限制，不是bug - 想确认某个库是否存在且可用？别只查名字，加
WHERE state = 0（ONLINE状态码）再判断
系统视图不是“另一个查询方式”，而是SQL Server元数据的唯一真相源。哪怕只是写个自动化建表检查脚本，漏掉sys.types联查或忽略object_id有效性校验，都可能导致类型误判——比如把tinyint当成bit处理。
