企业官网建设流程全解析

很多人建表的时候，习惯把字段一把梭成varchar(50)、int、datetime，觉得够用就行。这种表在小项目里跑得动，一旦数据量上来、业务复杂起来，问题会像连珠炮一样往外冒：明明存的是数字却没法排序，同样的值看起来一样却查不出来，导入一条 CSV 数据直接被约束拦死。我做了十几年 SQL Server 的运维和开发，可以负责任地说一句：数据类型和数据约束不是建表时“顺便选一下”的附属品，而是整个数据库能不能长治久安的地基。

这篇内容不是教科书式的字段清单，而是把我日常建表、改表、排查数据问题时沉淀下来的经验做一个彻底梳理。我会把常用数据类型的选型逻辑、六类约束的落地写法、以及改表/导入数据过程中踩过的坑一次讲清楚。适合刚入门的开发、转岗的数据岗位同学，也适合写了好几年 SQL 但一直凭感觉选类型的“老手”对照自查。

1. 先想明白一件事：数据类型和约束到底在管什么

1.1 数据类型是存储契约，不是随便选的

许多开发把数据类型当成“展示格式”，以为int和varchar(10)的区别只是显示上带不带引号。这种理解害死人。

本质上，数据类型是数据库和存储引擎之间的一份契约。它规定了三件事：这个字段在磁盘上占多少字节、怎么解析这些字节、能对它做什么运算。为什么int字段能直接SUM()，而varchar字段存了一堆“12345”却算不了？因为存储引擎看到int就知道按整型二进制来解释，看到varchar就知道按字符编码来解释，两者的内存表示、比较规则完全不同。

选错类型的代价是多维度的。你为了存订单号把字段设成varchar(100)，一个亿的表光这个字段就多占 40GB+ 空间，索引体积翻倍，查询扫描的 IO 也翻倍。你为了怕“不够存”把所有数字都设成decimal(38,2)，精度是保住了，但运算性能比int慢一个档次，因为在 CPU 层面 4 字节的整型运算和 17 字节的定点小数运算根本不是一个量级。

还有更隐蔽的影响：类型决定排序和比较。

varchar存数字，排序会得到 “1, 10, 2, 200”，因为字符排序一位一位比较；int存数字，排序才是 1, 2, 10, 200。这就是很多报表“明明数字却排乱序”的根源。

所以建表的第一步不是急着写 CREATE TABLE，而是坐下来想清楚：这个字段的真实业务含义是什么？它是一个业务编号、一个可计算的值、还是一段描述性文本？phone这种看似“数字”的字段，要不要用int存？答案是不用，因为电话号码不做加减乘除，而且int存不下 11 位数的预期扩展，用varchar(20)才是合理解。把“能计算”的字段和“只是长得像数字”的字段区分开，你已经避开了 70% 的类型坑。

1.2 约束是业务规则的数据库化

约束的作用很多人都知道，但很少有团队真正把它用好。

我见过不少系统，业务规则的校验全部写在应用层：前端判断邮箱格式，后端再判断一次，数据库层完全裸奔。这种做法的问题在于：应用层永远不是数据的唯一入口。运维跑脚本修数据、数据迁移工具灌数、DBA 直接在 SSMS 里 UPDATE，任何一个旁路入口都可能绕过应用校验，把脏数据写进表里。

数据库约束就是最后一道防线。它把“邮箱不能为空”、“状态只能是 0 或 1”、“子表必须挂在合法父表下”这些规则固化在数据库内部，无论数据从哪个入口进来，都必须遵守。前端的校验可以升级、可以绕过、可以发版出 bug，但你在数据库层定义的NOT NULL、CHECK、FK，只要不手动删，它们 24 小时无休地守在那里。

另一种极端是过度约束。我见过有人为了“严谨”给几乎每个字段都加CHECK，结果业务规则一变，DBA 要连夜删约束、改范围、再重建约束。所以约束也要讲究分层：核心业务不变的部分（主键、非空、外键）要用数据库约束死死守住；规则经常变的部分（枚举值的范围、状态机的流转）尽量收敛在应用层，或者用数据字典表管理，而不是把具体数值硬编码进 CHECK 约束。这个度怎么拿捏，后面第 4 章我会给一套可参考的做法。

2. 常用数据类型选型与核心细节

2.1 数值类型怎么选，别再靠猜

SQL Server 的数值类型看着多，实际场景里用的就那几种。先把它们的内存占用和取值范围摆清楚：

最常见的困惑是int和bigint。

我的经验是：自增主键默认用int，但如果你有“这张表三年内可能过亿”的判断，直接上bigint。不要觉得 21 亿很大够用了——一旦哪天业务增长超过预期，把int主键改成bigint是一场灾难：你要先删掉所有子表的外键、改主表列类型、再重建索引和约束，期间服务几乎必然停摆。改一个字段 5 分钟，改一环扣一环的主键可能是 5 小时起步。

金额字段优先用decimal(18,2)或更高精度。float是近似值，底层是二进制浮点，算 0.1 + 0.2 都可能出现视觉上不精确的尾巴，拿来记钱等于埋雷。这里我要专门回应一个高频问题：Oracle 的 NUMBER 类型对应 SQL Server 的什么？Oracle 的NUMBER不带参数时是“任意精度”的变长数值，最接近的替代是decimal(38, 6)或者decimal(38, 待定)。如果原来是NUMBER(10,2)，直接翻译成decimal(10,2)即可，没那么多玄学。

做类型转换时，CAST和CONVERT是基本功。CONVERT多了个样式参数，日期格式化时更顺手，比如CONVERT(varchar, GETDATE(), 112)能直接转成YYYYMMDD。但要注意：隐式类型转换是性能杀手。当你把varchar字段和int参数比较时，SQL Server 会在该字段上套一个隐性的转换函数，这个函数直接废掉你建立在字段上的索引。典型例子：电话号码存成varchar，查询时写WHERE phone = 13800138000（不带引号），SQL Server 为了比较会把整列 phone 逐行转成数值，走不了索引，大表必慢。规则很简单：字段是什么类型，参数就写什么类型，宁可多打一对引号。

2.2 字符串类型：char、varchar、nvarchar 的取舍

字符串是 SQL Server 里用得最多、也最容易被选错的类型。你的表里可能一半字段都是字符串，选错的后果会被放大得非常明显。

直接记结论：

• varchar(n)：变长、非 Unicode，n 表示字节。纯 ASCII 场景首选，存英文、数字编码、日志文本都合适。但要注意，中文字符在 varchar 里会按代码页占用额外字节，一个varchar(50)未必能存下 50 个汉字。
• nvarchar(n)：变长、Unicode，n 表示字符数。n 最大 4000，每个字符固定占 2 字节。只要你的系统有“将来可能存多语言”的苗头，就用nvarchar。代价是存储空间翻倍，索引体积也会大一圈。
• char(n)/nchar(n)：定长。适用于长度绝对不会变的场景，比如身份证号、MD5 摘要。它比 varchar 好在不会有行移动和碎片。
• text/ntext：历史遗留类型，千万不要在新表里用。老系统迁移时看到这两个类型，建议直接转成varchar(max)/nvarchar(max)。

varchar(max)是一个容易让人误解的类型。它看起来解决一切，但max类型的字段不能建普通索引，且不受varchar(8000)的限制，大对象默认存储在行外，读取时会有额外开销。能用有限长度表达的内容，永远用有限长度，不要图省事全上 max。

关于“中文到底选 varchar 还是 nvarchar”，我的实操建议分三步判断：

1. 系统是否未来可能做国际化 / 多语言？是，用nvarchar。
2. 字段是否主要存用户输入的姓名、地址？中国人名里有生僻字，统一用nvarchar最省心。
3. 字段是内部编码 / 日志 / 英文内容？用varchar没问题，省一半空间。

另外，排序规则（Collation）不止影响大小写，还影响中文按拼音还是按笔画排序、是否区分全角半角。你要是建库时选错了排序规则，后面比较字符串经常出现“看着一样但查不出来”的灵异事件。排查技巧：用

SELECT SERVERPROPERTY('Collation'); SELECT DATABASEPROPERTYEX('你的库名', 'Collation');

确认大小写是否敏感。如果库是Chinese_PRC_CI_AS（CI = Case Insensitive），那么WHERE Name = 'abc'和WHERE Name = 'ABC'结果一样；如果你业务上要求区分，就得在查询里强制COLLATE Latin1_General_CS_AS，但这样通常会让索引失效，不如建表时就决定好。

2.3 日期时间类型与“别用字符串存日期”的教训

日期时间在 SQL Server 里也有好几个版本：

很多老系统之所以还用datetime，是因为当年只有它可选。新系统建议直接上datetime2，因为它精度更高、范围更大，而且在比较和算术运算上表现一致。datetimeoffset则适合做全球部署的时间字段，它能把“2024-01-01 08:00:00 +08:00”这种时区信息直接存下来。

数据导入时最常见的坑是字符串转日期。比如 CSV 里给的是2024/1/5这种格式，直接CONVERT(datetime, '2024/1/5')在当前语言设置下能成功，换一台服务器的语言设置就报错。稳妥做法是用带样式的 CONVERT：

SELECT CONVERT(datetime, '20240105', 112); -- 2012 之前风格 SELECT TRY_CONVERT(datetime, '2024-01-05', 120); -- 推荐，转换失败返回 NULL

用TRY_CONVERT是 2012+ 才有的，它不会抛出错误，而是给 NULL，配合ISNULL可以优雅处理脏数据。

我在生产库排查时经常遇到一个现象：有人把日期存成varchar(10)。理由五花八门——“就是展示用”“导入数据时懒得多一步”“Excel 里就是文本”。后果是什么？日期没法直接按范围索引、没法用DATEADD、排序全是文本序、查询只能靠CONVERT硬转。这种表一旦数据量上来，几乎等于报废。任何时候不要用字符串存日期，哪怕它“看起来”像日期。你只需要在建表时花一分钟选对类型，后面省的是长期维护的心力。

2.4 冷门但关键的 bit、uniqueidentifier、rowversion

bit字段看着简单，但有个冷知识：一张表里如果有多个 bit 列，存储引擎会把它们合并打包到同一个字节里。也就是说，8 个 bit 列只占 1 字节，不是 8 字节。这在设计大量布尔字段（比如一堆“标志位”）时能省空间，但要注意bit列上建索引意义不大，因为它区分度太低。

uniqueidentifier是网卡时代的克星。很多应用用 C# 的Guid.NewGuid()做主键，图的是全局唯一、不需要数据库回来自增。但uniqueidentifier类型的值完全随机，作为聚集索引主键时会导致页拆分率居高不下，插入性能明显比int自增差。折中方案是用SequentialGuid生成有序 GUID，或者干脆主键用int/bigint 自增，GUID 单独做业务关联键。这一点在单表上亿的场景里，性能差异会被放大到肉眼可见的程度。

rowversion（旧称timestamp）是个容易被忽视却非常好用的类型。它每行自动维护一个递增的版本号，只要行有 UPDATE，版本号就会变。用乐观并发控制时，UPDATE 语句带一个WHERE rowversion = @旧版本号，就能避免“我改的时候别人也改了”的问题。它不需要你手工维护，SQL Server 自己管，放心用。

3. 数据约束全面拆解：从建表到日常维护

3.1 六类约束一次讲清

SQL Server 的约束可以分成六类：NOT NULL、PRIMARY KEY、UNIQUE、FOREIGN KEY、CHECK、DEFAULT。前五类都叫约束，DEFAULT严格意义上是“默认值定义”，但实际使用中大家都当约束管理。

用一个比喻帮助理解：如果把表比作宿舍楼的门禁系统，那么：

• NOT NULL就是“每个房间必须有床垫”——字段不能缺失。
• PRIMARY KEY是“每个房间有唯一门牌号”——全表不重复且不为空。
• UNIQUE是“楼里不能有两把相同的钥匙”——值可以唯一，但允许特殊空位。
• FOREIGN KEY是“你手里的钥匙必须能打开楼内某扇门”——引用必须有效。
• CHECK是“房间里温度必须 0~40 度”——取值范围人工校验。
• DEFAULT是“没人住的时候，门锁自动落锁”——录入时如果不给值，就自动填一个默认值。

约束和索引关系密切：主键约束默认创建一个聚集索引（或已有的聚集索引被复用），唯一约束默认创建一个非聚集唯一索引。这意味着“约束”同时承担了“完整性保证”和“查询加速”两个责任，所以约束设计直接决定索引设计，二者不能分开看。

3.2 主键、唯一、外键的落地写法

主键在建表时最直观：

CREATE TABLE dbo.Customer ( CustomerId INT NOT NULL, CustomerNo VARCHAR(32) NOT NULL, Name NVARCHAR(50) NOT NULL, CONSTRAINT PK_Customer PRIMARY KEY (CustomerId) );

主键字段强烈建议命名为表名 + Id，而不是含义不清的ID或GUID。为什么？因为所有子表外键都要引用它，名字起得规范，生出来的外键约束名也自然规范。

主键默认走聚集索引。聚集索引的叶子节点就是数据行本身，所以主键选择直接决定一张表的物理存储顺序。

自增int做主键省空间、性能好，但缺点是“可预测”，不适合需要防止遍历抓数据的公开接口场景。GUID 做主键全局唯一，但随机乱序会让聚集索引频繁页分裂。综合取舍：内部业务表用int identity，外部系统对接的关联标识用额外uniqueidentifier字段，两边好处都要。

唯一约束的坑在于 NULL。SQL Server 里唯一约束允许列上有多个 NULL，因为 NULL 被视为“未知”，未知和未知不相等。所以如果你以为加了唯一约束就能保证“不能重复”，它其实只保证“非空值不重复”。业务含义上要“手机号不能重复”时，字段本身应该NOT NULL，否则逻辑上会出现漏网之鱼。

外键约束的建法：

CREATE TABLE dbo.Orders ( OrderId INT NOT NULL, CustomerId INT NOT NULL, ... CONSTRAINT PK_Orders PRIMARY KEY (OrderId), CONSTRAINT FK_Orders_Customer FOREIGN KEY (CustomerId) REFERENCES dbo.Customer (CustomerId) ON DELETE CASCADE );

这里有个大坑：外键约束默认不会为子表的外键列创建索引。假如父表 Customer 被删一行，数据库要把所有子表扫描一遍看有没有引用该行的订单，子表数据量大时这操作就是全表扫描，直接拖垮系统。新建外键时，务必手动在子表外键列上补一个普通索引。我见过不止一次生产事故：往表上加了外键约束，第二天业务高峰期锁等待爆炸，查了半天发现就是缺这个索引。

外键的级联操作有四种：NO ACTION（默认）、CASCADE、SET NULL、SET DEFAULT。CASCADE 虽然省事，但要注意“级联链路”：A 表删行触发 B 表级联删除，B 表又触发 C 表，链条越长风险越大，而且中间任何一环被锁都会放大阻塞。我的建议是：内部关联表可以 CASCADE，跨业务域的表一律 NO ACTION，由应用层编排删除顺序。

3.3 检查约束和默认约束的实战细节

CHECK约束最适合的场面是“这个字段只允许几个固定值”。比如性别、状态码、年龄上限：

ALTER TABLE dbo.Customer ADD CONSTRAINT CK_Customer_AgeRange CHECK (Age BETWEEN 0 AND 120); ALTER TABLE dbo.Customer ADD CONSTRAINT CK_Customer_Status CHECK (Status IN (0, 1, 2));

用CHECK约束要非常小心“规则变化”。业务上新加一个状态 3，直接ALTER TABLE ... DROP CONSTRAINT CK_Customer_Status，然后重建含 3 的约束。这是常规操作，但要注意：在 ALTER 表加 CHECK 约束时，默认会验证表中的现有数据是否满足条件。如果表里有 1000 万行历史数据不满足新规则，操作会锁表很久甚至失败。这时候可以用WITH NOCHECK来跳过验证，但我给你一句忠告：NOCHECK 加约束本质上是在数据库里埋了一个定时炸弹。它虽然能把约束“加上”，但已有脏数据不会接受检查，后续更新时该行也可能一直带着脏状态。生产中如果实在要加，建议加完立刻写一个数据清洗脚本，把不满足条件的数据修掉。

那有没有替代 CHECK 的更灵活方案？如果状态值理论上会频繁扩展，就别写死在 CHECK 里，换成数据字典表 + 外键：状态存一个StatusCode，再建一个StatusDict表，外键关联过去。以后加状态只要往字典表插数据，不用动任何表结构。这是“枚举值会变”这个问题的最优解，代价是多一次关联查询，但在现代硬件条件下这点关联开销完全可以接受。

默认约束主要解决的是“不填时自动处理”。比如：

ALTER TABLE dbo.Orders ADD CONSTRAINT DF_Orders_CreateTime DEFAULT (GETDATE()) FOR CreateTime;

用户不传 CreateTime，数据库自动写入当前时间。值得注意的细节：GETDATE() 返回当前的 datetime；如果你用 datetime2 字段，建议用SYSUTCDATETIME()（UTC 时间）或SYSDATETIME()（本机高精度时间），避免类型隐式转换。默认值脚本如果以后要改，不要直接删除重建，直接 ALTER 也可以，但严谨团队都保留约束名，保证每次部署脚本幂等性。

3.4 约束命名与规范化管理

约束如果没有显式命名，SQL Server 会自动生成一串晦涩名字，比如PK__Customer__A4AE64B8、DF__Orders__Create__0D7E1E1C。这种名字在运维时是噩梦：你想删一个约束，得先查询系统视图才发现它的真名。

我的惯例是给所有约束起有意义的名字，格式统一：

• 主键：PK_表名或PK_表名_列名
• 唯一：UQ_表名_列名
• 外键：FK_从表名_主表名
• 检查：CK_表名_列名
• 默认：DF_表名_列名

命名不直接影响功能，但它直接关系到维护效率。当一个外键报警时，你看到FK_Orders_Customer就知道是订单表关联客户表的外键出了问题，而不是去翻一阵乱码。

查询当前库所有约束的常用脚本：

SELECT t.name AS TableName, con.name AS ConstraintName, con.type_desc AS ConstraintType FROM sys.tables t INNER JOIN sys.objects con ON t.object_id = con.parent_object_id WHERE con.type_desc IN ('PRIMARY_KEY_CONSTRAINT','UNIQUE_CONSTRAINT','FOREIGN_KEY_CONSTRAINT','CHECK_CONSTRAINT') ORDER BY t.name, con.name;

这个脚本我几乎每个项目都用，确认哪些表有约束、约束名是什么，然后决定脚本顺序。

4. 类型与约束结合的最佳实践：表设计、导入导出与性能

4.1 一张业务表该有的类型和约束

讲完理论和拆解，我直接给一张“标准订单表”的建表示例，把你应该采纳的取舍都标出来：

CREATE TABLE dbo.Orders ( OrderId BIGINT NOT NULL CONSTRAINT PK_Orders PRIMARY KEY, OrderNo VARCHAR(32) NOT NULL CONSTRAINT UQ_Orders_OrderNo UNIQUE, CustomerId INT NOT NULL, TotalAmount DECIMAL(18,2) NOT NULL CONSTRAINT CK_Orders_TotalAmount CHECK (TotalAmount >= 0), Status TINYINT NOT NULL CONSTRAINT DF_Orders_Status DEFAULT (0), CreateTime DATETIME2(3) NOT NULL CONSTRAINT DF_Orders_CreateTime DEFAULT (SYSUTCDATETIME()), UpdateTime DATETIME2(3) NOT NULL CONSTRAINT DF_Orders_UpdateTime DEFAULT (SYSUTCDATETIME()) ); CREATE INDEX IX_Orders_CustomerId ON dbo.Orders(CustomerId); ALTER TABLE dbo.Orders ADD CONSTRAINT FK_Orders_Customer FOREIGN KEY (CustomerId) REFERENCES dbo.Customer(CustomerId);

每个字段的选择都有理由：OrderId 用 bigint 是因为订单表最容易破亿；OrderNo 加唯一约束防止补单重复；金额用 decimal 且带非负检查；Status 用 tinyint 加默认值；CreateTime/UpdateTime 用 datetime2 且由数据库自动维护。外键单独建索引。这套建表模板可以直接抄到大多数交易类系统里。

还有三个容易被忽略的细节：

1. 每张表最好有 UpdateTime 字段，排障时一眼看出哪条数据最近被改过。
2. 不要用保留字做字段名，Order、Status、Desc这些要加方括号才能用，跨工具移植时全是坑。
3. 字段统一风格，全大写还是全小写并不重要，但要统一。否则索引/约束名的自动生成结果会乱得没法看。

4.2 修改表结构时约束怎么处理

改表结构是 DBA 日常最容易引发事故的操作，尤其是 alter column。SQL Server 对类型的修改比较苛刻：把int改成bigint一般能直接 ALTER，但把varchar(50)改成varchar(100)、或把字段从nvarchar改成varchar，如果字段上有索引或约束，很大概率会被 SQL Server 拒绝，提示“该对象依赖于”。

解决方案只有一条路：先删依赖，再改列，最后复活依赖。以给一个带默认约束的字段扩容为例：

-- 第 1 步：删除默认约束 ALTER TABLE dbo.Orders DROP CONSTRAINT DF_Orders_OrderNo; -- 第 2 步：改字段类型/长度 ALTER TABLE dbo.Orders ALTER COLUMN OrderNo VARCHAR(64) NOT NULL; -- 第 3 步：重新添加约束 ALTER TABLE dbo.Orders ADD CONSTRAINT DF_Orders_OrderNo DEFAULT ('') FOR OrderNo;

要注意的是，ALTER TABLE ... ALTER COLUMN在执行时会锁表，数据量大时耗时很长。

你应该先明确离线窗口再操作，而不是白天上班时间直接跑。

另外，修改主键/外键要格外谨慎，尤其是生产环境。我建议步骤为：禁用或删除所有相关外键 → 修改主键列 → 重建主键约束 → 重建外键和索引 → 检查统计信息。整个过程最好封装成事务，一旦失败可以 ROLLBACK，但注意 DDL 支持回滚，重建索引等部分操作不可回滚，务必分步做。

还有一个实用技巧：用 SSMS 图形界面修改表结构时，它背后是“临时建表 + 复制数据 + 删旧表 + 改名”的流程。这种操作在大表上极其危险，动辄锁几个小时。记住一句红线：大表结构变更，永远手写脚本，分步执行，绝对不要依赖 SSMS 的“设计模式”。

4.3 数据导入导出时约束冲突的应对

从 Excel、CSV、老系统导数据到 SQL Server，最常报的错就是“无法导入数据，数据无效”。这句话其实是个笼统的外壳，本质几乎都是类型不匹配或约束冲突。

类型不匹配最常见：

• Excel 里的身份证号被识别成科学计数法，导进来变成 1.23456E+17。
• CSV 里日期有多重格式：2024/1/5、01-05-2024、44567（Excel 序列号），直接导入日期字段必然报错。
• 空字符串和 NULL 的语义差异，导入INT字段时空字符串无法转换。

约束冲突更直白：

• 主键/唯一约束：导入的数据有重复。
• 外键约束：子表引用了不存在的父表 ID。
• CHECK 约束：导入了年龄 500 岁的“人类”。
• NOT NULL：某行关键字段是空。

我的导入前检查清单通常长这样：

1. 先备份目标表。无论多自信，导入前先SELECT ... INTO 备份表。
2. 关闭约束前，先确认能关闭。临时禁用约束可以这么做：

ALTER TABLE dbo.Orders NOCHECK CONSTRAINT ALL; -- 导入数据... ALTER TABLE dbo.Orders WITH CHECK CHECK CONSTRAINT ALL;

注意第一条是不验证现有数据，第二条是“验证并启用”。如果数据依然脏，第二条会报错，说明你已经把脏数据带进来了，还得回头清洗。

3. 用工具做“数据体检”。导入前写几条查询，找出唯一键冲突、外键失效、CHECK 违规的行，比如：

-- 找出目标表中会与外键冲突的行 SELECT o.* FROM 导入的临时表 o LEFT JOIN dbo.Customer c ON o.CustomerId = c.CustomerId WHERE c.CustomerId IS NULL;

批量导入性能最高的是bcp和BULK INSERT。BCP 适合从文件导入，能指定字段分隔符、编码和批量大小；BULK INSERT 直接在 T-SQL 里操作。但这两兄弟都不做复杂校验，所以我常用的套路是：先导进一张结构和目标一样但“没有约束”的临时表，清洗完再合并到正式表。这个方案看似多一步，实际上能把导入时间缩短一半以上，因为不需要逐行触发约束检查。

4.4 类型与约束对性能的影响

聊完导入，再说一个从热词里看出大家很关心的点：单表上亿、存储空间太大。这种问题有一个值得先排查的方向：是不是数据类型选得“太肥”。

常见例子：

• 状态码只有 0~3，用了int（4 字节）；换成tinyint（1 字节），1 亿行省 300MB 以上。
• 时间字段不需要毫秒，用了datetime2(7)（8 字节），换成datetime2(0)或date也能省。
• 唯一标识不用 GUID，却为了“未来可能”用了uniqueidentifier（16 字节），1 亿行比bigint多 800MB。
• 字符串全部nvarchar(500)，实际平均只有 20 个字符，那行尾空间的浪费在变长字段里不会太大，但索引键如果包含它，排序和查找的成本仍在。

空间问题不能只盯着SELECT SUM(total_pages) * 8 / 1024看，还要考虑压缩。SQL Server 的表压缩和页压缩在数据量大、重复度高的场景下有奇效。页压缩先把列的前缀和字典编码去掉，再配合行压缩，1 亿行订单表压一半完全正常。但压缩对 CPU 有要求，OLTP 高频写入场景不一定划算，OLAP / 历史归档场景闭眼用。

约束对性能的影响同样是双刃剑。索引不用说，外键约束如果缺少配套索引会拖垮删除和更新；CHECK 约束在插入时要多一次表达式求值，但通常可忽略；主键自增搭配聚集索引是最高效的写入模式。还有一个很少人注意的地方：约束名过长、约束过多会拖慢元数据读取。SQL Server 的系统视图要遍历 sys.objects、sys.schemas 等元数据，约束数量上千后，个别操作元数据的语句会变慢。别过度建约束，尤其是 CHECK，能少则少。

5. 常见问题与排查技巧实录

5.1 字符串转数字：ISNUMERIC 的坑与正确写法

“SQLServer 字符串转数字”这个热搜词背后，是一批被隐式转换折磨过的同学。

最直接的转换写法是：

SELECT CAST('123' AS INT); -- 123 SELECT CONVERT(DECIMAL(18,2), '123.45'); -- 123.45

但真正到生产环境，麻烦的是“字符串里混着脏字符”。很多人查出来用ISNUMERIC判断：

SELECT column_value, ISNUMERIC(column_value) AS IsNum FROM 待清洗表;

然后就觉得ISNUMERIC = 1一定能转 INT。这个判断是错的。ISNUMERIC的判定标准非常宽，'1e2'、'.'、'$12'它都返回 1，但直接CAST成INT全会失败。这是个祖师爷级的老坑了，20 年前就有，至今还有资料在误导。

从 SQL Server 2012 起，推荐用TRY_CAST/TRY_CONVERT。它们转换失败时不给报错而是返回 NULL，才能做安全过滤：

SELECT column_value, TRY_CAST(column_value AS INT) AS NumValue FROM 待清洗表 WHERE TRY_CAST(column_value AS INT) IS NOT NULL;

如果你要过滤出“纯数字”字符串，还可以用 LIKE。下面的写法能排除掉非纯数字行：

SELECT * FROM 待清洗表 WHERE column_value NOT LIKE '%[^0-9]%' AND column_value <> '';

注意点：LIKE '%[^0-9]%'是“包含非数字字符”，所以前面取反。这个方案在 SELECT 层可以做，但不能指望它利用索引，因为要用函数转化。清洗海量数据时，建议先把可转的行先落进新表，再修改原始字段类型。

5.2 STRING_SPLIT 报 invalid object name 的兼容级别问题

热搜词里有个很具体的问题：invalid object name 'string_split'。出现这个报错，十有八九不是因为你写错了函数名，而是数据库的兼容级别低于 130。

STRING_SPLIT是 SQL Server 2016 引入的，而且要求数据库兼容级别至少是 130。如果你的库是兼容级别 100（SQL Server 2008 级别）或更老，就算实例版本是 SQL Server 2017、2019，也会报“对象名无效”。

排查方法：

SELECT name, compatibility_level FROM sys.databases WHERE name = '你的库名';

如果结果小于 130，修改级别：

ALTER DATABASE 你的库名 SET COMPATIBILITY_LEVEL = 130;

这里要提示一下：修改兼容级别属于实例级影响，可能改变部分查询计划行为。上线前建议在测试环境验证所有关键查询，哪怕只是从 120 升到 130，也不排除有统计信息相关优化器行为的变化。

升级后，STRING_SPLIT用法可以配合CROSS APPLY做“按分隔符拆行”：

SELECT value FROM dbo.Orders CROSS APPLY STRING_SPLIT(OrderNo, '-');

拆完行再和目标表做 JOIN，就可以做“一个字段里多个编号关联到主表”的清理任务。

5.3 外键、数据无效与导入导出

再系统回答一遍“sqlserver 无法导入数据 数据无效”这个热词到底怎么排查。

遇到导入失败时不要上来就责怪工具，按下面的顺序走一遍，90% 能定位到问题：

1. 先导进一个临时表，所有列都用 nvarchar(max)。这一步把“类型不匹配”的问题绕过去，先看数据本身长什么样。
2. 查空值、查重复、查明显异常。重点核对目标表主键列、唯一列、外键列、NOT NULL 列。
3. 用 TRY_CONVERT 验证每列类型。比如目标表 TotalAmount 是 DECIMAL(18,2)，临时表里总账字段是字符串，就用TRY_CONVERT(DECIMAL(18,2), 字符串列)找出无法转换的行。
4. 清干净后再正式导入。

记住一个核心心法：导入不是把文件灌进库里的动作，而是一个“清洗 → 校验 → 装载”的过程。把大部分脏数据挡在临时表阶段，比进入正式表后整天修数据要省心一百倍。

5.4 安装配置管理的杂项问题

热词里还有一堆关于“SQLServer 安装教程”“sqlserver 配置管理器”“句柄无效”“卸载 sqlserver”的问题。这些内容不是这篇文章的主线，但我简单提一句：如果你在安装、配置管理器中反复踩坑，基本都能回溯到 Windows 账户权限和服务启动类型的问题。SQL Server 的服务账号最好是专门的服务账户，而不要用普通用户账号登录后再跑；配置管理器里如果出现“远程过程调用失败”或者“句柄无效”，多半是 WMI 组件损坏或权限异常，重启服务、重建 WMI 仓库一般能解决。

至于版本选择，SQL Server 2022 的问题是网上密钥满天飞但真假难辨，我的建议是：正式环境买标准版或开发版授权，个人学习和测试用 Developer 版即可。2022 相比 2016/2019 增加了不少性能特性，但你的业务代码如果还在用旧语法，优先确认兼容级别，不要盲目升级。

6. 一点长期沉淀下来的实操心得

关于数据类型的最终建议：选类型时要把五年后的数据量放进去一起思考。不是让你每个字段都上bigint、nvarchar(max)，而是让你区分“稳定且存量大的核心字段”和“临时性辅助字段”。核心表的主键、交易金额、状态码这类字段，宁可在初期定大一点，也不要在已经上亿的数据表里反复改列。因为 ALTER COLUMN 跑的每一分钟，都是业务在等待。

关于约束的最终建议：约束的强度要和团队成熟度匹配。团队里都是老手，约束可以适当收紧；团队新人多、业务迭代快，约束就要“保底但不锁死”。核心主外键、非空、唯一，必须由数据库保证；频繁变化的枚举值、状态机，放在应用层用配置管理。这个度没有标准答案，但我见过太多过度约束导致每天删了建、建了删的表结构，那种维护成本比不加约束还高。

最后分享一个我实际排查问题时的习惯：每次遇到“数据看起来是对的，但系统行为不对”的诡异 bug，第一件事不是看代码，而是先检查这个字段的类型和约束定义。一张表如果有上百个问题单据，你顺着字段看一遍 CREATE TABLE 和约束名，往往比翻业务代码更快找到真相。数据库是最后一道防线，类型是这道防线的砖，约束是水泥。砖不牢，墙会塌；水泥乱抹，墙会歪。希望这篇梳理能帮你把墙砌得又直又稳。