1. 为什么SQL Server数据类型这么容易踩坑？

我刚入行那会儿，最常被前辈骂的就是"你这字段类型怎么选的？"。SQL Server的数据类型看似简单，但实际用起来处处是雷。先说几个真实案例：

去年我们团队有个报表系统突然崩溃，排查发现是有人用varchar(50)存了身份证号。看起来没问题对吧？直到某天业务部门要求支持港澳台身份证，那些18位的号码直接截断，系统直接崩了。更惨的是，等我们发现时已经有上千条数据被损坏。

另一个经典案例是财务系统的金额字段。新人用float存金额，结果季度报表对不上账，差了几毛钱。财务总监直接冲到技术部拍桌子——你猜最后怎么着？是因为float的精度问题导致0.1+0.2≠0.3这种基础问题。

这些坑我都亲自踩过，所以今天要跟你聊的不是教科书式的数据类型列表，而是实战中那些容易忽略的细节。我会重点讲5个最要命的陷阱，以及对应的避坑方案。

2. 字符串类型：你以为的varchar并不是你以为的

2.1 varchar vs nvarchar：字符编码的生死抉择

先说结论：在中文环境下，99%的情况你应该用nvarchar。为什么？来看这个实验：

CREATE TABLE TestChars ( regular_col VARCHAR(100), unicode_col NVARCHAR(100) ); INSERT INTO TestChars VALUES ('你好世界', N'你好世界');

执行后你会发现，varchar列存储的中文变成了乱码。这是因为varchar按字节存储，每个中文字符占2-3字节，而nvarchar按字符存储，每个字符固定2字节。

关键经验：只要涉及多语言或特殊字符，无脑用nvarchar。虽然会占用更多空间，但比起数据损坏的代价，这点存储成本微不足道。

2.2 长度陷阱：为什么你的字段总是不够用

我见过太多这样的设计：

CREATE TABLE Users ( username VARCHAR(20), email VARCHAR(50) );

看起来合理？等业务说要支持企业邮箱时，那些超长的公司邮箱地址直接GG。我的经验法则是：

1. 用户名/昵称：最少nvarchar(64)
2. 邮箱：最少nvarchar(256)
3. 地址：最少nvarchar(512)
4. 备注/描述：直接nvarchar(MAX)

记住：现代存储很便宜，但数据截断的修复成本极高。特别要注意的是，SQL Server的varchar(MAX)和nvarchar(MAX)其实性能并不差，不要被"MAX"吓到。

3. 数字类型：精度问题能让你加班到天亮

3.1 永远不要用float/real存金额

这是我见过最贵的错误之一。来看这个惊悚的例子：

DECLARE @a FLOAT = 0.1, @b FLOAT = 0.2; IF @a + @b = 0.3 PRINT '相等' ELSE PRINT '不相等'; -- 这里会输出"不相等"！

解决方案很简单：

• 金额：用decimal(19,4) —— 足够存万亿级别的金额，精确到分
• 百分比：用decimal(5,2) —— 范围0-999.99%
• 数量：根据业务需求选int或bigint

3.2 自增ID的坑：int真的够用吗？

很多表这样设计：

CREATE TABLE Orders ( OrderID INT IDENTITY(1,1), -- 其他字段 );

等业务跑几年后，OrderID突破21亿时，整个系统直接崩掉。我的建议是：

• 高频增长的表：直接用bigint
• 数据量小的表：可以用int，但要定期监控ID增长情况

4. 日期时间类型：时区问题能让你怀疑人生

4.1 datetime vs datetime2：精度与范围的权衡

老系统常用datetime，但它有几个致命缺陷：

1. 精度只有3.33毫秒
2. 范围只有1753-9999年（没错，1753年之前的日期存不了）
3. 存储要8字节

而datetime2：

1. 精度可达100纳秒
2. 范围0001-9999年
3. 存储6-8字节（根据精度调整）

所以现代开发应该优先用datetime2。示例：

CREATE TABLE Events ( EventTime DATETIME2(7) -- 7表示纳秒精度 );

4.2 时区陷阱：你的时间不是我的时间

最坑的是跨时区系统。假设你在北京时间2023-08-01 08:00:00存了条数据，美国用户查出来显示什么？取决于你用的是什么类型：

• datetime：不带时区信息，直接按服务器时区显示
• datetimeoffset：包含时区信息，会自动转换

解决方案：

CREATE TABLE GlobalEvents ( EventTime DATETIMEOFFSET -- 会存储时区信息 );

插入时：

INSERT INTO GlobalEvents VALUES ('2023-08-01T08:00:00+08:00');

这样查询时会自动按客户端时区转换显示。

5. 二进制与特殊类型：这些坑你可能还没遇到

5.1 文件存储：varbinary(MAX)的替代方案

很多人喜欢把文件直接存数据库：

CREATE TABLE Documents ( Content VARBINARY(MAX) );

这会导致数据库膨胀。更好的方案是：

1. 小文件（<256KB）：可以存varbinary
2. 大文件：存文件路径，文件放专用存储

5.2 XML和JSON：现代SQL Server的新选择

SQL Server 2016+原生支持JSON：

CREATE TABLE Products ( Attributes NVARCHAR(MAX) CHECK (ISJSON(Attributes)=1) -- 确保是合法JSON );

查询时可以用JSON函数：

SELECT ProductID, JSON_VALUE(Attributes, '$.color') AS Color FROM Products

比以前用字符串自己拼JSON方便多了。

6. 数据类型选择速查表

最后送大家一张我整理的决策表：

这张表是我用五年时间、踩过无数坑总结出来的。贴在你工位上，下次设计表时先看一眼，至少能避开80%的坑。