上周帮同事排查一个存储过程性能问题，询字型打开SSMS一看，段类有个字段是询字型NVARCHAR(MAX)，但里面存的段类全是订单号，最长不超过20个字符。询字型这就是段类典型的字段类型选错了。SQL Server里查字段类型这件事，询字型看着简单，段类但真正用起来，询字型坑不少。段类

最直接的询字型查询方式，当然是段类走系统视图。我平时最常用的询字型是INFORMATION_SCHEMA.COLUMNS，语法干净，段类跨版本兼容性也好：

SELECT COLUMN_NAME,询字型 DATA_TYPE, CHARACTER_MAXIMUM_LENGTH, IS_NULLABLE FROM INFORMATION_SCHEMA.COLUMNS WHERE TABLE_NAME = 'Orders';

这个视图返回的DATA_TYPE是那种你一眼能看懂的类型名，比如varchar、int、datetime。CHARACTER_MAXIMUM_LENGTH对字符串类型有效，数值类型就是NULL。够用，但信息量偏少——它不告诉你这个字段是不是IDENTITY，也不显示排序规则。

想要更全的信息，得用sys.columns配合sys.types：

SELECT c.name AS column_name, t.name AS data_type, c.max_length, c.precision, c.scale, c.is_nullable, c.is_identity FROM sys.columns c JOIN sys.types t ON c.user_type_id = t.user_type_id WHERE c.object_id = OBJECT_ID('Orders');

这里有个容易踩的坑：max_length对nvarchar返回的是字节数，不是字符数。比如nvarchar(50)，max_length显示100。因为每个nchar/nvarchar字符占2字节。很多人第一次看到这个数字会愣一下，以为字段定义成了100。用INFORMATION_SCHEMA就没这个问题，它直接给字符数。所以看你要什么——要字符长度用前者，要底层存储细节用后者。

还有一种情况：字段用的是用户自定义类型。比如有人定义了dbo.PhoneNumber这种类型，底层是varchar(20)。用INFORMATION_SCHEMA.COLUMNS查，DATA_TYPE会显示varchar，丢失了自定义类型的信息。用sys.columns关联sys.types时，如果看system_type_id和user_type_id的区别，就能发现它其实是个别名类型。我见过一个库，几十个表都用自定义类型，后来要统一改长度，不知道这个细节的人改了半天没改全。

临时表是个麻烦事。局部临时表（#temp）在tempdb里，用INFORMATION_SCHEMA.COLUMNS查不到，得走tempdb.sys.columns：

SELECT c.name, t.name AS data_type, c.max_length FROM tempdb.sys.columns c JOIN tempdb.sys.types t ON c.user_type_id = t.user_type_id WHERE c.object_id = OBJECT_ID('tempdb..#MyTemp');

注意OBJECT_ID里要带tempdb..前缀，不然返回NULL。这个细节坑过我不止一次。

表变量就更隐蔽了。它不存在于任何系统视图里，只能通过sys.dm_exec_cached_plans之类的DMV去翻，或者干脆在定义的时候自己记清楚。我现在的习惯是，表变量超过5个字段就改成临时表，省得后面查类型时抓瞎。

图形界面当然也能看。SSMS里展开表→列，右键属性，或者直接写个SELECT TOP 0 * FROM表，看结果集的元数据。但批量查、对比、生成文档的时候，还是得靠SQL。我写过一个小脚本，遍历库里所有表的所有字段，导出成Excel，每次数据库改版的时候跑一遍，diff一下就知道谁动了什么。

说到底，查字段类型本身不难，难的是知道该查哪个视图、每个字段的含义是什么、以及不同视图之间信息的取舍。INFORMATION_SCHEMA适合快速浏览，sys系列适合深度排查。选哪个，看你当下要解决什么问题。