企业官网建设流程全解析

SQL Server的数据类型，几乎每个接触过数据库的人都绕不开，但真正把它彻底吃透的人并不多。许多看过的项目里，性能问题、数据错乱、存储空间暴涨，追根溯源都是建表时类型选错了。这篇东西就把 SQL Server 的所有内置数据类型从头到尾整理一遍，包括它们之间的区别、各自适合的场景、容易踩的坑，以及选型时的一些实战判断。不管你是刚入门的开发，还是已经带过项目的老手，都可以当一份速查手册来用。

我不打算简单罗列官方文档里的定义和范围，那太没意思了。我会结合实际开发中遇到的典型问题来讲，比如为什么用 float 存金额会算错，为什么明明有 varchar 还要用 nvarchar，为什么 datetime2 比 datetime 更值得推荐。把这些问题搞清楚，数据类型这关才算真正过了。

1. 为什么数据类型这么重要？先把底层逻辑理清楚

1.1 数据类型决定存储和计算行为

数据库本质上就是一张张表格，每列的数据类型决定了这一列能存什么、占多大空间、怎么比较、怎么排序、怎么计算。你可以把 SQL Server 想象成一座精密的仓库，数据类型就是货架规格：有的货架只能放某种尺寸的盒子，有的货架能放任意大小的包裹，有的货架因为设计特殊，放东西不仅占位置，还额外占用过道空间。

存储行为上的差异非常明显。比如int固定占 4 字节，而varchar(100)是按实际字符长度动态占用空间，最多不超过 100 个字符（在 SQL Server 中 varchar 是按字节存储，但 varchar 类型本身存储的实际是字符，具体字节数还跟排序规则和字符编码有关）。计算行为上的差异更微妙：整数之间做除法会截断小数，decimal运算则根据精度和标度保留小数位，float则会引入二进制浮点的精度误差。这些差异直接影响业务结果，尤其是涉及金额、数量、比例计算的场景。

1.2 数据类型选错的典型后果

选错类型的后果往往不是立刻暴露的，而是以一种非常难受的方式出现。

最常见的一个：金额字段用float存。前期数据量小，看不出问题，等累计到几十万条时，一条订单金额是 0.1，另一个是 0.2，加起来却是 0.30000000000000004。客户看到的对账单上写着一长串小数，领导和业务部门同时炸锅。这不是偶然，是二进制浮点数表示十进制的天然缺陷，改一下字段类型就能解决。

第二个常见问题：字符串排序规则冲突。一个数据库里既有char字段又是中文排序规则，做多表关联时两张表的排序规则不一致，直接报错“无法解决排序规则冲突”。这个问题在新老系统迁移、跨库查询时特别多，本质上就是设计表时没有统一类型配套规则。

第三个问题：日期精度不够。datetime的精度是 3.33 毫秒，而且只能表示 1753 年 1 月 1 日以后的日期。有些业务系统需要记录毫秒级精确时间，或者处理更早的历史数据，就必须改用datetime2。很多人接手老系统时看到一整排datetime，规则已经定死，改起来要动一堆存储过程，异常痛苦。

所以，建表时多花几分钟想清楚每个字段的类型，后面就能节省几周的返工时间。下面逐类过一遍。

2. 数值类型全解析：从bit到decimal，一张表说清楚

2.1 整数类型怎么选：tinyint/smallint/int/bigint

SQL Server 提供了四种整数类型，它们之间的差别主要是取值范围和存储字节数。

选择原则很直观：够用就好，但尽量留一点余量。状态码用tinyint完全没问题，因为业务状态就那几个。订单表的主键用int通常就够了，但如果你预估单表数据量会超过 21 亿行，那就得直接上bigint。别觉得 21 亿很远，日志表、流水表、物联网数据表很容易达到。

需要留意的是，程序语言和数据库类型不是一一对应的。比如 C# 的byte对应tinyint，short对应smallint，int对应int，long对应bigint。如果类型不对齐，EF Core 或者 ADO.NET 在映射时会出现异常或转换开销，这也是为什么好多团队坚持用int撑起所有整数列，省的出幺蛾子。

2.2 精确数值decimal与money的坑

decimal(p,s)（在 SQL Server 里也可以写成numeric(p,s)）是真正的精确十进制类型。p是精度，表示总共能存多少位数字；s是标度，表示小数点后保留几位。比如decimal(10,2)最多表示 10 位有效数字，其中小数点后 2 位，所以整数部分最多 8 位，范围是 -99999999.99 到 99999999.99。

计算存储大小时有个经验公式：存储字节数大约是(p + s) / 2 + 1左右，但具体值可以查官方文档。实际开发中不需要算那么细，只需要明白p越大越占空间。

decimal特别适合金额、税率、折扣等需要精确计算的字段。我在订单系统里几乎全部用decimal(18,2)，18 位有效数字对绝大多数企业级应用来说绰绰有余，2 位小数对应“分”。如果你要处理加密货币那种 8 位小数，可以设成decimal(28,8)。

说完 decimal，就必须提money和smallmoney。money占 8 字节，范围约 -922337203685477.5808 到 922337203685477.5807，精度是小数点后 4 位。它确实是个数值类型，但做除法或跨币种换算时会出现四舍五入的诡异行为，而且money被微软标记为“传统类型”，并不推荐在新系统中使用。更关键的是，ORM 对money的映射有时会跟decimal不一致，很容易在报表里看到奇怪的精度尾巴。我的建议是：新项目一律用decimal，老项目如果遇到money就别轻易动它，但新代码不要再写money了。

2.3 浮点类型float/real：慎用的经典原因

real占 4 字节，约等于 C# 的float；float在 SQL Server 中默认占 8 字节，约等于 C# 的double。它们适合科学计算、物理模拟、统计指标这类对精度要求不苛刻、但对取值范围和计算性能有要求的场景。

但千万注意：浮点类型不能用于需要精确表示的金额、数量、比率。背后的原因很简单，计算机用二进制表示小数时，很多十进制小数是无限循环的。比如 0.1 在二进制里是一个无限循环小数，存储时只能截断一部分，所以 0.1 + 0.2 不等于 0.3。这就是很多财务系统被坑的原因。

如果必须用浮点数做范围比较，一定要加一个容差，比如ABS(a - b) < 0.0001，否则查询结果会让你怀疑人生。另外，对float列做索引、分组、排序也会因为精度问题导致意外的重复和缺失。能避开就避开。

3. 字符串类型：varchar与nvarchar的世纪难题

3.1 定长、变长与max：char/varchar/text

这三种字符类型的使用场景、存储方式和性能表现差异很大。

char(n)是定长字符串，无论你存储多少字符，它都会占满 n 个字符的空间（具体字节数还要乘以编码字节数）。它的优势是存取速度快，适合长度基本固定的数据，比如 MD5、身份证号（如果只考虑数字和X）、国家代码。问题是如果存的数据长度波动很大，比如char(100)存一个“OK”，后面 98 个字符全是空格，不仅浪费存储，还会在查询时产生意外的空格比较问题。

varchar(n)是变长字符串，只存实际需要的内容加少量额外开销。varchar(50)存“OK”就只占几个字节，远小于定长的 100 字节。它适合绝大多数文本字段，比如用户名、邮箱、订单号。注意varchar(n)的n表示最多能存多少字符，不是字节数。如果是英文字母和数字，一个字符占 1 字节；如果是中文，在varchar里一个汉字可能占 2 字节（取决于排序规则的代码页，比如简体中文 GBK 编码下是 2 字节）。因此varchar(20)不一定能存 20 个汉字，这点新人特别容易踩坑。

text是一个老古董，用于存储长文本，但现在已经被废弃了。微软官方明确建议用varchar(max)替代。varchar(max)最多可以存 2GB 的字符数据，适合文章正文、描述、JSON 等。但要提醒一点：varchar(max)的大字段会直接影响查询性能，不要把大文本放在频繁查询的表里，否则会把整个行的数据页撑大，增加 IO 开销。更合理的做法是单独建一张“内容表”，把大字段独立出去。

3.2 Unicode与N前缀：nvarchar和nchar存在的意义

nvarchar(n)和nchar(n)对应的是 Unicode 字符集，用N前缀标识。它们能存储所有语言的字符，包括中文、日文、韩文、阿拉伯文、emoji 等，无论什么排序规则，nvarchar下的每个字符都按 Unicode 编码存储。SQL Server 2019 及以后版本引入了 UTF-8 支持的排序规则，varchar也能存中文了，但为了稳妥，我仍然推荐存字符串默认用nvarchar。

存储上的代价是nvarchar每个字符通常占 2 字节（UTF-16），空间占用比非 Unicode 的varchar更大。但现代服务器存储和内存都不贵，换来的是绝对稳定的字符兼容性，避免乱码问题。尤其是做国际化系统、用户生成内容、跨平台数据交换，用nvarchar省心得多。

一个经典错误是：很多人省事，建表时所有字符串都用nvarchar(max)。这种做法虽然避免了长度不够的问题，但会让索引变得非常笨重。SQL Server 的索引键最大支持 900 字节（普通非聚集索引），nvarchar(max)根本没法直接建索引，你必须用nvarchar(450)以下的长度或者在列上计算哈希列。所以，不要无脑用 max，按实际业务最长值再加一点余量去定长度，是最稳妥的。

3.3 排序规则（Collation）对字符串存储和比较的影响

排序规则决定了字符串的比较规则、排序顺序、大小写敏感度和重音敏感度。比如Chinese_PRC_CI_AS表示中文简体、不区分大小写、区分重音。排序规则还会影响字符串存储编码，同一个varchar列在不同排序规则下存储同一个汉字，占用的字节可能不同。

最常见的问题是跨库关联时排序规则冲突。比如一个库的排序规则是SQL_Latin1_General_CP1_CI_AS，另一个是Chinese_PRC_CI_AS，两个表的varchar列做JOIN，SQL Server 直接报错。解决办法是在查询里用COLLATE DATABASE_DEFAULT统一规则，但这对性能有影响。更推荐的做法是建库时统一规划排序规则，新库直接用Chinese_PRC_CI_AS或Latin1_General_CI_AS，尽量避免混合环境。

另外，如果你需要精确匹配用户密码哈希或敏感编码值，要特别注意大小写敏感排序规则。默认的_CI_AS是不区分大小写的，如果业务里需要区分大小写（比如优惠码），要么用_CS_AS排序规则，要么在比较时加COLLATE Latin1_General_CS_AS。这也是一个容易忽视的小坑。

4. 日期时间类型：别再全部用datetime了

4.1 七种日期时间类型的参数对比

SQL Server 里日期时间相关的内置类型一共有七种，很多新人只知道datetime，但实际上它们之间的差异非常关键。

smalldatetime在旧系统中常见，但它的精度只能到分钟，存2024-01-01 12:34:56会被四舍五入成12:35:00，做考勤、订单时间计算时会出错。新项目完全没必要用它。

4.2 datetime2为什么是更好的默认选择

datetime2比datetime的优势有三个：精度更高、范围更广、存储空间有时更小。datetime2(3)存储毫秒级数据只需要 6 字节（而datetime是 8 字节）；datetime2(7)精度到 100 纳秒，存储 8 字节，和datetime一样大，但精度高了无数倍。

在日常开发中，我基本上把datetime2(3)作为默认选择，既能满足毫秒级精度，又能节省存储空间。如果业务场景不需要毫秒，datetime2(0)也可以，它甚至能直接表示0001-01-01，有些历史系统需要记录公元前日期（比如考古、天文数据）时，datetime是无能为力的，只能用datetime2。

不过要注意，ORM 对datetime2的支持略有差异。EF Core 中默认会把DateTime映射为datetime2，这没问题。但如果你的老项目里已经有大量的datetime存储过程参数，改成datetime2后可能因为参数类型不匹配导致隐式转换，执行计划就不走索引了。所以，老库不要盲目全局替换datetime；新库默认datetime2，是最合理的策略。

4.3 时区问题与datetimeoffset

全球化业务一定会遇到时区问题。如果只存datetime2，那你存储的是本地时间还是 UTC 时间？靠程序约定，靠注释，靠 DBA 经验，但这都不够可靠。datetimeoffset类型自带时区偏移量，可以同时存储“本地时间 + 与 UTC 的偏移”。比如东京是2024-06-01 10:00:00 +09:00，伦敦是2024-06-01 02:00:00 +01:00，它们表示的是同一个瞬间，但存储值不同。

如果你要在多个时区的数据库之间同步数据，或者用户遍布全球，datetimeoffset是最不容易产生歧义的选择。SQL Server 还提供了SWITCHOFFSET、TODATETIMEOFFSET等内置函数，可以很方便地把时间在不同时区之间换算。

但也要注意，很多老版本 ORM 对datetimeoffset的支持不完善，比如一些版本的 EF Core 会把DateTimeOffset映射成datetime2并丢失偏移量。这就要看你使用的框架版本。总的来说，如果系统只在单一地区运行，前后端都明确使用 UTC 传输，那么datetime2配合严格的 UTC 约定也够用；一旦涉及跨时区协作，datetimeoffset才更稳。

5. 二进制、GUID与特殊类型：容易被忽略但关键时刻能救命

5.1 binary/varbinary/image：字节流存储场景

binary(n)和varbinary(n)用于存储字节数组，适合存加密后的数据、哈希值、文件碎片、序列化对象等。binary是定长，varbinary是变长，varbinary(max)对应.NET的byte[]，也用于替代废弃的image类型。

实际项目中，我经常看到有人把图片、PDF 文件直接塞进varbinary(max)字段。从技术上完全可行，性能也不算差，但真要存大量大文件时，我建议把文件放到对象存储或者独立文件表，数据库里只存文件路径或哈希值。为什么？因为varbinary(max)会把大对象塞进 SQL Server 的数据文件，备份恢复、扩容、迁移时都是一个巨大的压力，而且不方便 CDN 加速。对于小文件（比如几百 KB 的头像），存库内反而更方便，事务一致性好，各有利弊。

另外，存密码哈希时，很多人用varchar存十六进制字符串，比如"0x5F4DCC3B5AA765D61D8327DEB882CF99"，这种字符串会占用双倍空间。更规范的方式是用binary(16)存 MD5 结果、binary(32)存 SHA-256 结果，这样占用更小、比较更快。不过使用二进制哈希列时，一定要在应用层处理大小写，因为二进制比较是区分大小写和原始字节的。

5.2 rowversion与uniqueidentifier：并发控制与分布式主键

rowversion（旧称timestamp）是一个自动生成的二进制值，每次对行做更新时，SQL Server 会自动把它改成一个新的值。它不表示日期时间，只是单调递增的版本号。它的主要用途是乐观并发控制：读取一行，记录rowversion，更新时在WHERE条件里带上这个值，如果别人已经更新过，rowversion变了，你的更新条件不成立，这样就能避免丢失更新。

我之前在多个团队里推过这个做法，用rowversion做并发控制比“用更新时间戳判断”可靠得多，因为它完全由数据库保证唯一性和变化性，不受应用层时钟和精度影响。不过要注意，如果一个表有多个用户同时频繁更新，rowversion会在每个事务里自动变化，所以在批量更新场景下可能造成预期的行不匹配。

uniqueidentifier就是 GUID，16 字节，几乎可以保证全球唯一。它常用于分布式系统、多库合并场景中的主键，因为不同机器生成的 GUID 在主键合并时不会冲突。缺点是随机性导致索引碎片严重，插入性能不如自增bigint。如果要用 GUID 做主键，最好配上NEWSEQUENTIALID()生成顺序 GUID，减少页拆分。另外，GUID 作为主键时占用的存储空间更大，外键也会跟着变大，对大型系统来说是一个需要权衡的问题。分库分表时有时也用bigint+ 号段方案，不一定非要 GUID。

5.3 XML与sql_variant：半结构化数据的两种思路

xml类型可以直接存储 XML 文档或片段，并支持 XQuery 查询、修改、索引。它适合存储配置文件、报表模板、消息协议这类本身是 XML 格式的数据。SQL Server 里还可以对xml列建立主 XML 索引和辅助 XML 索引，让针对 XML 内部节点的查询变快。

但我觉得，如果目标只是存一段 XML，没有在数据库里面查询节点内容的需求，那直接用nvarchar(max)存原始文本就够了，做 XML 解析放到应用层，数据库的压力会小很多；反之，如果你要频繁根据 XML 内部元素做筛选，就要认真建 XML 索引，否则全表扫描会把数据库拖垮。

sql_variant是一种可以存储多种数据类型值的特殊类型。同一列里，第一行是整数、第二行是字符串、第三行是小数，都可以。它适合那种结构不确定、无法用普通列建模的场景，比如通用配置表、扩展属性表。但它不能作为主键或外键，不支持全文索引，也不能参与ORDER BY直接比较（要先转换）。实际开发里大多数场景可以用json、nvarchar(max)或者多个可空列来替代，sql_variant属于“万不得已才用”的类型。

5.4 空间数据、hierarchyid与CLR类型：只在特定领域用

SQL Server 提供了geometry和geography两种空间数据类型。geometry处理平面坐标系，geography处理椭球体地球坐标。它们支持空间索引、距离计算、交集判断等操作，常用于地图、GIS、物流路径规划。如果项目跟地理位置相关，用空间索引去算“附近的人”会比自己在应用层用经纬度公式算快很多。

hierarchyid用于表示树形结构，比如组织架构、分类树。它把每个节点编码成一条路径字符串，能直接通过GetAncestor、GetDescendant等方法操作。比传统的parent_id递归表要简洁，但复杂的树操作有时候还是递归查询更直观，看团队熟悉度。

还有 CLR 自定义类型，可以基于 .NET 开发自定义数据类型，但微软对这类支持已经慢慢降低热度，除非有极强的定制需求，否则不建议新项目尝试。这些特殊类型属于“用对场景是利器，用错场景是灾难”，普通业务系统里并不常见。

6. 实战选型原则与常见问题排查

6.1 一劳永逸的数据类型选型清单

基于我日常建表的经验，整理了下面一套默认规则，可以帮你快速决策：

• 整数主键，用bigint还是int？看数据量预期，普通系统int够用，但如果你不敢打包票，直接用bigint，前期多花 4 字节，后期省一次大迁移。
• 布尔标识，用bit。不要用char(1)存'Y'/'N'，更不要用int存 0/1。
• 金额、单价、折扣，用decimal(18,2)或decimal(28,8)，根据币种和精度要求调整。
• 百分比、比例，可以用decimal，保留 4 位小数足够，比如0.1234。
• 一般字符串，用户可输入内容，用nvarchar；程序生成的有限字符集（如手机号、订单号），用varchar也许省空间，但为兼容中文和特殊符号，新项目还是建议nvarchar。
• 日期时间，默认datetime2(3)；全球分布系统，考虑datetimeoffset。
• 大文本/长 JSON，用nvarchar(max)，但注意独立表存储或分表。
• 文件内容，尽量不存数据库；一定要存，用varbinary(max)。
• 并发控制版本号，用rowversion，别手动生成。

这套规则不一定适合所有场景，但可以让 90% 的建表需求稳稳妥妥地落地。

6.2 隐式转换为什么会杀性能

类型不匹配时，SQL Server 会在后台自动做隐式转换。隐式转换本身不可怕，可怕的是它出现在查询条件列上，导致索引失效。

举个例子：表里OrderTime是datetime2，但存储过程参数是varchar，查询写WHERE OrderTime = @param。如果字符串转换成datetime2，参数转换没问题；但如果优化器选择先转换列值，那么这一列上的索引就无法使用了。如果表很大，一次查询就是全表扫描。

另一个典型：varchar列和nvarchar参数比较。因为varchar隐式转换成nvarchar的优先级更高，所以实际上列值会逐行转换成nvarchar再比较，索引照样失效。所以一定要保持应用传入参数的类型与列类型一致。我在排查慢查询时，第一步就是看执行计划里有没有 CONVERT_IMPLICIT 警告，十次有八次能在这里发现问题。

6.3 常见报错与解决：从转换失败到排序规则冲突

数据类型相关的报错五花八门，这里列几个出现频率最高的：

“将 varchar 转换为数据类型 int 时失败。”这种通常是把数字字符串列和数字列做了比较，或者程序传入的参数是字符串但列是 int。解决方法是审查查询条件和传入参数类型，不要在 SQL 里写WHERE VARCHAR_COL = 123，而是让应用传字符串，或者反过来把列转成数字。但后者通常意味着索引失效。

“String or binary data would be truncated.”这个报错是因为插入的数据超过了字段长度限制。老版本 SQL Server 会直接报错，2016 以后引入了截断警告。解决办法是检查字段长度与实际数据。我通常建议建表时给长度留 20% 余量，比如用户名最长 30 个字符，不要咔咔定varchar(20)，直接给nvarchar(50)。

“Cannot resolve collation conflict.”多表关联时排序规则不一致。解决办法是给比较或连接列统一COLLATE DATABASE_DEFAULT，或直接改表字段排序规则。最彻底的做法是建库时统一排序规则。

“Arithmetic overflow error converting numeric to data type numeric.”这个是因为数字超出decimal定义的精度和标度。比如decimal(5,2)最多存 999.99，你非要存 1000。反过来，如果你的应用层计算结果是12.345，而字段是decimal(18,2)，SQL Server 在隐式转换时会四舍五入到 12.35，而不是报错，这也会造成数据偏差。

“The conversion of a varchar data type to a datetime data type resulted in an out-of-range value.”日期字符串格式不对，或者数据库的日期语言设置跟传入格式不匹配。比如SET LANGUAGE English之后'01/02/2024'表示 1 月 2 日还是 2 月 1 日，取决于排序规则和语言设置。稳妥做法是应用层统一使用 ISO 8601 格式'2024-01-02T10:00:00'，或者参数化查询。

还有一类和登录密码策略相关的报错，比如“密码已过期，无法登录”，其实就是 SQL Server 登录名的密码策略到期了，这类不是数据类型问题，但经常被误以为是数据库类型兼容问题。如果是自己本地测试库，可以用ALTER LOGIN ... CHECK_POLICY OFF临时解除限制，但在生产环境一定要遵循公司的密码安全策略，别乱来。

7. 写在最后：我的一点经验

数据类型看着是建表时几秒钟的选择，但它决定了一个系统未来几年的稳定性和性能。我在实际项目中见过因为一个nvarchar(max)用错导致索引失效、慢查询堆满监控面板的；也见过一个decimal精度配错导致财务报表小数点对不上的。这些问题说大不大，但排查起来非常花时间。

个人建议，每个团队最好沉淀一份自己的“建表规范”，把常见的字段类型路由表定下来。比如主键统一bigint、金额统一decimal(18,4)、时间统一datetime2(3)、用户输入统一nvarchar(n)。新人照着写，老手检查起来也轻松。

最后分享一个小技巧：如果你不确定某个类型的具体表现，直接在 SQL Server Management Studio 里用SELECT CAST(... AS 类型)或CONVERT(类型, 值)快速验证。比如SELECT CAST(10.0 / 3 AS DECIMAL(18,2))，看看结果是不是你预期的 3.33。多做这类小实验，比死记硬背文档有用得多。