sqlserver加字段语句

ALTER TABLE 是字段 SQL Server 里加字段的唯一正路。语法就一行：`ALTER TABLE 表名 ADD 列名 数据类型 [约束]`。语句但这一行背后，字段坑比你想的语句多。 上个月我帮客户修一个库存表，字段业务方要求加个 `remark` 字段，语句类型 `NVARCHAR(200)`。字段我直接执行： ```sql ALTER TABLE dbo.Inventory ADD remark NVARCHAR(200) NULL; ``` 顺手加了 `NULL`，语句因为业务方说“有的字段记录没备注”。结果第二天，语句报表组的字段人跑过来说查询变慢了。我一看执行计划，语句全表扫描——因为新增的字段可空字段让每行数据都多了一个可变长度的存储开销，页拆分导致碎片率飙升到 40%。语句这就是字段典型的“加字段一时爽，性能火葬场”。 所以加字段前先问自己三个问题：这个字段能允许 `NULL` 吗？能设默认值吗？会影响现有索引吗？如果允许 `NULL` 且不加默认值，SQL Server 在 2012 之前版本会做全表更新（把每行都标记为 NULL），表越大锁越久。我见过有人给 2 亿行的日志表加字段，直接锁了 40 分钟，业务全挂。后来改用两步走： ```sql -- 先加允许 NULL 的列 ALTER TABLE dbo.LogTable ADD new_col INT NULL; -- 再补充默认值约束（仅元数据操作，不碰数据） ALTER TABLE dbo.LogTable ADD CONSTRAINT DF_LogTable_new_col DEFAULT (0) FOR new_col; ``` 2012+ 版本里，加可空列且无默认值是纯元数据操作，秒回。但如果你加了 `NOT NULL` 且没默认值，那必然要扫全表填值，没得商量。 还有个细节，字段顺序。SQL Server 不允许你指定新列位置，永远加在最后。但如果你用 `SELECT *` 查询（这本身就是坏习惯），新列出现在末尾会影响程序里按索引取值的逻辑。我见过一个老系统，程序里写死 `row[5]` 取值，结果 DBA 在中间加了个字段，直接让所有报表错位。所以加字段后，必须检查所有 `SELECT *` 的消费端。 再说数据类型。能用 `INT` 别用 `BIGINT`，能用 `VARCHAR(50)` 别用 `NVARCHAR(MAX)`。`NVARCHAR` 比 `VARCHAR` 多一倍存储，索引空间也翻倍。有个真实案例，某 ERP 给订单表加了 `customer_note`，定义成 `NVARCHAR(MAX)`，结果每次查询都要把整个字段读入内存，IO 飙高。后来改成 `NVARCHAR(500)`，因为业务上根本不会超过 500 字——你猜怎么着？查询快了三倍。 加字段时别忘了 `WITH VALUES` 这个选项——它是给 `ALTER TABLE ... ADD` 配合默认值用的。比如： ```sql ALTER TABLE dbo.Customer ADD is_active BIT NOT NULL CONSTRAINT DF_Customer_is_active DEFAULT (1) WITH VALUES; ``` `WITH VALUES` 会让现有行直接写入默认值 1，而不是只约束新插入的行。但如果你不加 `WITH VALUES`，默认约束只对新行生效，旧行全是 NULL（尽管列是 `NOT NULL`，但 SQL Server 会允许这种不一致状态存在——别问为什么，这是设计如此）。 最后说个反直觉的操作：删除字段。SQL Server 2016+ 支持 `DROP COLUMN` 带 `WITH (ONLINE = ON)`，但加字段没有在线选项。所以生产环境加字段，务必选在低峰期，并且先跑个 `ALTER TABLE ... WITH (CHECK)` 检查现有数据是否满足约束条件。我习惯先开个事务，加完字段立刻查系统视图确认： ```sql BEGIN TRAN; ALTER TABLE dbo.Orders ADD discount DECIMAL(5,2) NULL; SELECT name, is_nullable, max_length FROM sys.columns WHERE object_id = OBJECT_ID('dbo.Orders') AND name = 'discount'; COMMIT; ``` 确认无误再提交，有问题直接回滚。加字段是小事，但做错决策就是大事故——你永远不知道哪个下游查询会因为一个新列而改变执行计划。