用sqlserver来搞数据库应用部署那些事儿，实际操作和技术分享

说到用SQL Server来搞数据库应用部署，这事儿说白了就是怎么把你开发好的数据库（比如那些表、视图、存储过程、数据什么的）安安稳稳地放到服务器上，让应用程序能连上用，这事儿听起来简单，但里面有不少细节和坑，咱们就捞干的说,讲讲实际操作中会遇到的事儿。

（来源：基于常见的数据库部署实践）

最“土”但最常用的方法：备份还原

对于很多小项目或者初期阶段，最直接的办法就是备份还原，你在你自己的开发电脑上把数据库弄好了，数据也灌进去一些测试的，然后直接在SQL Server Management Studio（就是那个管理数据库的图形化工具，我们都叫它SSMS）里，右键数据库 -> 任务 -> 备份，生成一个.bak文件。

然后你把这个.bak文件拷贝到服务器上，在服务器的SSMS里，右键“数据库” -> 还原数据库，选择那个.bak文件，大概率就能还原成功了，这种方法的好处是简单粗暴，几乎不用动脑子，特别适合数据库结构不太变动,或者整个库搬迁的情况。

但它的毛病也很明显，你得保证服务器上SQL Server的版本不能比你的开发机版本低，不然可能还原不了，如果只是更新了一两个表或者几个存储过程，你也得整个库还原，不够灵活，最重要的是，如果生产环境的数据库已经有数据了，你直接还原就会把别人的数据全覆盖掉，这可是要出大事故的,所以这招一般只在部署全新的环境时用。

（来源：SQL Server官方文档及常见运维操作）

稍微高级点：用SQL脚本“增量”更新

为了避免覆盖现有数据，更常用的方法是准备一系列的SQL脚本，你这个版本要增加一个新表UserProfile，修改一下老表Orders的结构，再加一个存储过程sp_GetRecentOrders。

那你就在项目里维护好几个.sql文件：

• 01_CreateTable_UserProfile.sql
• 02_AlterTable_Orders_AddColumn.sql
• 03_CreateStoredProcedure_sp_GetRecentOrders.sql

部署的时候，你就按顺序在服务器的数据库上执行这些脚本，这样做的好处是精准，只更新需要改动的地方，不会动到现有数据，很多团队都会用一个专门的工具（比如Flyway, DbUp之类的）来帮忙管理和自动执行这些脚本，还能记录下哪些脚本已经执行过了,避免重复执行。

但这个方法要求你非常细心，脚本的顺序不能错，比如你不可能在表还没创建的时候就去修改它，写修改表的脚本时，要考虑到已有的数据怎么办，你给Orders表加一个不允许为NULL的新列Status，那你必须得同时指定一个默认值，不然脚本一执行就会报错，因为已有的订单记录这个新列是空的，违反了“不允许为NULL”的规定。

（来源：数据库版本控制最佳实践）

更“工程化”的方法：用DACPAC部署

SQL Server自己带了一个叫“数据层应用程序”（DAC）的东西，它能把整个数据库的结构（不包括数据）打包成一个叫.dacpac的文件，这个可以看作是数据库的“编译”结果。

在Visual Studio里有一个“SQL Server数据库项目”，你可以在里面像管理代码一样管理你的数据库结构：建表、写视图、写存储过程，然后右键项目，选择“发布”，它会帮你生成一个.dacpac文件和一个发布脚本，你可以直接用SSMS的“部署数据层应用程序”向导来部署这个.dacpac文件。

它的强大之处在于，它会自动比较目标数据库和你这个dacpac文件之间的差异，然后智能地生成一个升级脚本，比如你只是删除了一个列，它会生成ALTER TABLE ... DROP COLUMN ...的语句，而不是把表删了重建，这对于大型数据库的升级非常友好,因为重建表意味着数据丢失和长时间停机。

但这个东西也不是万能的，遇到一些复杂的变更，比如要修改一个列的数据类型，而这个列又被其他外键引用着，它自动生成的脚本可能会非常复杂甚至失败，在正式部署到生产环境之前，百分之百必须先在一个和生产环境一样的测试环境上试一遍，看看它生成的脚本到底干了啥,有没有风险。

（来源：Microsoft Learn - SQL Server Data Tools (SSDT)）

部署中最头疼的事儿：处理数据

上面说的基本都是改结构（Schema），但部署中最容易出问题的往往是数据（Data），你需要给所有老用户初始化一个积分，或者需要把一个枚举类型的数字代码（1，2，3）转换成更易懂的字符串（'Active', 'Inactive'）。

这些改动也需要写SQL脚本，通常叫“数据迁移脚本”或“种子数据脚本”，这些脚本必须和结构变更脚本配合好，你先增加了Status列（结构变更），然后紧接着要运行一个脚本，把已有的订单的Status都更新为‘Completed’（数据迁移）。

这块儿最容易遗漏，也最需要测试，万一你的数据迁移脚本写错了，把不该改的数据改了，恢复起来非常麻烦,一定要在测试环境用和生产环境类似的数据量进行充分测试。

最后的安全网：备份和回滚计划

不管你用哪种方法，在按下“确定”部署之前，一定要做一件事：备份生产环境的数据库，这是最后的救命稻草，万一部署过程中出了什么幺蛾子，导致数据库乱套了或者应用程序挂掉，你能最快速度还原回去,保证业务先跑起来。

最好能提前准备一个“回滚脚本”，比如你这个版本是增加一个列，那回滚脚本就是删除这个列，虽然有时候回滚不像前进那么简单（比如你删了数据就很难找回来），但有一个清晰的回滚思路和方案,能让你在出问题时心里不慌。

用SQL Server部署数据库应用，从手动备份还原到脚本化再到工程化的DACPAC，是一个越来越规范的过程，核心思想就一个：安全、可控地把改动应用到生产环境，没有最好的方法，只有最适合你现在项目阶段和团队能力的方法，关键是流程要规范，测试要充分,备份要牢记。