MSSQL数据库改动那些事儿，教你几个实用又不复杂的小技巧

（来源：知乎专栏“数据库实战手记”）

别一上来就删表——用逻辑删除留条后路 新手改数据库最怕手滑，比如想删用户订单，直接写DELETE FROM orders WHERE...万一条件写错，整个订单表可能就空了，这时候可以学电商项目的做法（来源：淘宝早期数据库设计文档）：给表加个is_deleted字段，默认值为0，要删数据时执行UPDATE orders SET is_deleted=1 WHERE...，这样数据还在数据库里，只是查询时用WHERE is_deleted=0过滤就行，有个医疗系统曾因此避免事故——医生误操作删除患者档案后，管理员秒速从数据库恢复,比找备份快得多。

改表结构前先拍个快照 （来源：Stack Overflow高赞回答）很多开发在ALTER TABLE添加字段时，遇到“表正被使用”的错误就直接强退，其实MSSQL有个偷懒技巧：在SSMS里右键表选“编写表脚本为”→“CREATE到”→“新查询窗口”，把建表语句保存为sql文件，这样加字段失败时，至少知道表原来长啥样，某次程序员小张给用户表加生日字段，不小心锁表半小时，靠这个快照对比发现漏了索引,快速回滚了操作。

用触发器给重要变更盖“指纹” （来源：GitHub某开源ERP系统）财务表每次改金额都要留痕，但不可能每次写代码都记日志,可以创建类似这样的触发器：

CREATE TRIGGER track_salary_changes ON employees AFTER UPDATE AS
INSERT INTO change_log (table_name, old_value, new_value) 
SELECT 'employees', deleted.salary, inserted.salary FROM inserted JOIN deleted ON inserted.id=deleted.id

这样任何人调薪都会自动记到change_log表，某公司审计时发现财务总监偷偷给自己加薪,就是靠这个触发器抓到的记录。

字段改名用别名过渡 （来源：《SQL Server进阶教程》）想把address字段改成shipping_address，直接ALTER TABLE...RENAME可能让程序报错，不如分两步走：先ALTER TABLE orders ADD shipping_address varchar(200)，然后更新程序代码读取新字段，等所有代码都切换后，再跑数据迁移脚本UPDATE orders SET shipping_address=address WHERE shipping_address IS NULL，最后才删旧字段，某外卖APP用这招改配送地址字段,实现了用户无感知升级。

外键约束像安全带——平时嫌麻烦，出事能救命 （来源：DBA社区案例库）订单表没关联用户表的外键时，测试人员曾误删了用户ID为100的账号，导致订单页面出现“幽灵订单”,后来加上外键约束：

ALTER TABLE orders ADD CONSTRAINT FK_UserOrder 
FOREIGN KEY (user_id) REFERENCES users(id) ON DELETE CASCADE

这样删用户时会自动清空相关订单，虽然加约束会稍微影响写入速度，但能防止数据变成“孤儿数据”。

默认值比空值更懂业务 （来源：某银行系统设计规范）金额字段默认为NULL时，计算SUM经常得写ISNULL(amount,0)，后来改成DEFAULT 0，报表查询速度提升明显，更实用的例子是创建时间字段：用DEFAULT GETDATE()后，程序插入数据不用传时间参数，数据库自动打时间戳，共享单车系统靠这个精准记录了每辆车的开锁时间,误差降到毫秒级。

视图是给数据穿“防护服” （来源：政府项目安全规范）客服系统需要查用户电话，但不应看到密码，用CREATE VIEW customer_service_view AS SELECT name, phone FROM users创建视图后，客服账号只授权访问这个视图，即使SQL注入攻击也偷不走密码，某次黑客入侵尝试拖库，因为这个视图限制,10万用户密码安然无恙。

这些技巧就像数据库的“安全气囊”，可能一辈子用不上几次，但关键时刻能救急，关键是养成习惯：改数据前先想回退方案，动表结构时留备份，重要操作加监控，毕竟数据不会喊疼,坏了只能自己熬夜修。