说实话我之所以认真研究用 docker-compose 跑 sqlserver完全是被本地安装折腾怕了。最早装 SQL Server 2012 的时候光下载安装包就花了大半天中间还蹦出个“句柄无效”的报错卸载重装了两次才过。后来换了电脑又得从头折腾一遍安装包下载、环境变量、防火墙、配置管理器一套流程走下来小半天就没了。直到我改成 docker-compose 启动 sql-server这个体验才彻底翻转过来一份配置文件一条启动命令干干净净的容器实例就跑起来了用完还能一键销毁完全不污染宿主机。这篇内容不是什么高深教程就是我把 sqlserver 容器化之后沉淀下来的完整实操记录。适合在本地做开发调试、跟着课程学数据库、搭 CI 验证脚本、或者临时给团队起一套测试环境的人参考。如果你也有过被 SQL Server 安装向导折磨的经历这篇文章能让你少走很多弯路。1. 为什么我最终选了 docker-compose本地安装的坑与方案对比很多人觉得 SQL Server 嘛到官网下个安装包一路 Next 不就行了真上手过的人都知道这套流程远没那么顺滑。尤其当你的主力开发机是 macOS 或者 Linux想在本地跑一套 SQL Server传统安装方式基本是死路一条。即使是 Windows 环境多版本共存、卸载残留、服务配置这些坑也够喝一壶的。1.1 本地装 SQL Server 的三大痛点第一个痛点是安装包体积和下载速度。SQL Server 的安装镜像动辄几个 G在网速不理想的时候光是下载就足够劝退。更别提安装过程中还经常出现各种奇怪的报错热搜词里那个“句柄无效 HRESULT”的异常我当年也撞到过最后只能靠卸载重装解决折腾到怀疑人生。第二个痛点是环境残留和版本冲突。同一台机器上装过 2012 再装 2019或者装过默认实例再装命名实例服务列表、注册表、配置管理器里的条目会非常混乱。卸载时你以为卸干净了下次装新版照样可能因为旧组件残留导致失败。你甚至能找到专门用于清理 SQL Server 残留的第三方工具光这一点就说明问题有多普遍。第三个痛点是跨平台支持太差。虽然微软后来出了 SQL Server on Linux 版本但安装步骤依然不轻松依赖库、权限、配置步骤一大堆。如果你用的是 Apple Silicon 芯片的 Mac本地安装这条路更是基本走不通只能退而求其次连远程服务器。我见过不少新同事入职第一天光装开发环境就耗掉一整天最后卡在 SQL Server 上求助。1.2 同类方案横向对比纯 docker run 与 docker-compose 的取舍有人可能会说既然要用容器直接docker run一条命令不就行了为什么还要多此一举引入 docker-compose我最初也是这么干的但用了几次就发现问题了。docker run那条命令本身就长得离谱镜像名、环境变量、端口映射、数据卷、内存限制全堆在一块复制到终端里换行逻辑混乱想改一个参数还得在长串命令里找半天。更麻烦的是这种命令不容易共享给同事也不方便沉淀到项目仓库里。docker-compose 的核心价值在于把“环境配置”变成一份可以提交到 Git 的声明式文件。你只需要维护一个docker-compose.yml里面写了什么镜像、什么端口、什么数据卷、什么环境变量团队里的任何人拉下来执行一句docker compose up -d就能得到一套完全一致的 SQL Server。这比发一段复杂命令让同事自己去复制粘贴要可靠得多也比写一篇长篇安装文档更省心。从运维角度看docker-compose 对容器生命周期的管理也更友好。docker compose down可以整体停掉并删除docker compose restart可以重启服务配合卷挂载还能保证删容器不删数据。这种体验接近“用完即焚需要再来”非常契合开发测试环境的诉求。1.3 这套方案适合谁又不适合谁先说明一点这套容器化方案也有边界不是所有场景都适合。它最适合的是三类人第一类是开发人员本地需要一台随时可用的 SQL Server 实例做调试第二类是测试和 CI 环境维护者需要在流水线里快速拉起、销毁数据库实例第三类是学习数据库的新手想快速体验 SQL Server 而不想被安装过程劝退。如果你追求的是生产环境的高可用、极限性能或者复杂的 Windows 集成功能比如 SQL Server Agent 任务、SSIS、Reporting Services、AlwaysOn 可用性组等那容器化方案还达不到直接顶上线的程度。生产环境仍然建议使用云数据库或者专门的数据库服务器容器用于开发和测试更稳妥。认清边界才能用对工具。2. 动手前准备镜像选型、环境检查和工具搭配写配置文件之前有几件事需要先定下来。最核心的是选哪个版本的 SQL Server 镜像其次要确认宿主机环境满足容器运行条件最后是准备一套顺手的连接工具。这几步看着不起眼但选错了镜像版本或者忽略了环境限制后面启动时大概率会翻车。2.1 镜像版本怎么选2022 还是 2019Developer 还是 Express微软官方维护的 SQL Server 容器镜像托管在mcr.microsoft.com/mssql/server仓库下目前最常用的两个大版本是 2019 和 2022。我个人建议新项目直接用 2022毕竟功能更新、支持周期更长如果你的生产库还停留在 2019为了本地与线上版本保持一致也可以用 2019 镜像。两者在容器化部署方式上完全一样差别只在 SQL Server 版本功能。另一个关键选项是MSSQL_PID环境变量也就是产品版本。开发测试建议用Developer这个版本拥有企业版级别的全部功能而且免费没有 180 天过期的坑。Express版本功能受限数据库单库上限是 10GB除非你刻意模拟 Express 的限制否则没有理由选它。Standard和Enterprise需要许可证一般只在测试商业版特性时才需要指定。这里有个容易踩的坑某些第三方教程会让你拉取mcr.microsoft.com/mssql/server:latest这个标签。latest的指向有时并不直观建议直接用明确的版本标签比如2022-latest。这样拉了哪个版本自己心里有数排障时也容易定位。2.2 宿主机环境检查内存、引擎与端口占用在动手之前先用一条命令确认 Docker 环境本身是健康的。打开终端执行docker version确认 Docker Engine 版本比较新。然后执行docker compose version确认识别到了 compose 插件。这里顺便说一句新版 Docker 已经内置了docker compose子命令如果你还在用需要单独下载的旧版docker-compose建议尽早迁移命令格式基本不变但性能和兼容性更好。内存是启动 SQL Server 容器最关键的硬指标。SQL Server 进程要求至少 2GB 可用内存否则容器启动后会立刻退出日志里会明确提示“This program requires a machine with at least 2 gigabytes of RAM”。如果你的开发机只有 8GB 内存还同时在跑 IDE、浏览器和一堆容器务必给 SQL Server 预留足够的额度或者在 compose 里显式限制容器内存。端口方面要检查 1433 是否被占用。宿主机上如果已经装了 SQL Server 或者别的服务占了这个端口容器启动时会报bind: address already in use。解决方案很简单把宿主端口改成一个不冲突的数值比如14330:1433连接时连 14330 即可。2.3 连接工具的搭配推荐容器本身只是数据库服务真正干活还得靠客户端工具。我经常被问到用什么连 SQL Server 比较好这里列一张简单的对比表供不同需求的人参考。工具平台支持特点适用场景SSMSWindows功能最全数据库管理运维能力强DBA、Windows 用户深度管理Azure Data StudioWin/macOS/Linux轻量、跨平台、适合写查询和脚本开发调试、Mac/Linux 用户首选DBeaverWin/macOS/Linux通用型客户端支持多种数据库需要同时管理多种数据库的人sqlcmd容器内/命令行轻量命令行工具适合脚本和自动化容器内快速查询、CI 流水线如果你在网上搜过“sqlserver 图形化工具”这个词大概率会看到上面几个名字。我的组合是日常写查询用 Azure Data Studio需要精细管理实例配置时换 SSMS自动化脚本里用 sqlcmd。三个工具身份认证方式都能直接用sa账号连接容器启动后填入账号密码就能干活。3. docker-compose.yml 逐行拆解环境变量、端口与数据卷到底该怎么写那份关键的docker-compose.yml这一节我会把配置文件里的每一行都拆开讲清楚保证你拿回去能直接改、直接跑。同时还会解释为什么这些配置要这么写避免照抄之后不知道在调什么。3.1 一份可以直接抄的配置文件先给出一份完整的、经过我实测的配置文件然后再逐段解释。直接用这份文件能省掉很多摸索时间但对每一行的含义还是要了解清楚。services: sqlserver: image: mcr.microsoft.com/mssql/server:2022-latest container_name: mssql-dev environment: ACCEPT_EULA: Y MSSQL_SA_PASSWORD: YourStrong!Passw0rd MSSQL_PID: Developer TZ: Asia/Shanghai ports: - 1433:1433 volumes: - mssql-data:/var/opt/mssql - ./backup:/backup mem_limit: 4g cpus: 2 restart: unless-stopped volumes: mssql-data:这里我没有写version字段因为新版 docker compose 已经把它标记为 obsolete写上也只是为了兼容旧工具会额外弹提示所以不写更干净。三个环境变量是启动 SQL Server 容器必须提供的一个是ACCEPT_EULA一个是MSSQL_SA_PASSWORD另外建议显式指定MSSQL_PID。下面逐个说。3.2 三个关键环境变量的含义与密码策略ACCEPT_EULA用来接受微软的最终用户许可协议必须设置为Y否则容器会拒绝启动。这个变量没什么技术含量但它提醒你一件事SQL Server 虽然被容器化但许可规则没有变开发和测试用 Developer 版本也要遵守协议条款。MSSQL_SA_PASSWORD是超级管理员sa的初始密码。这个密码必须满足 SQL Server 的强密码策略至少 8 位同时包含大写字母、小写字母、数字和符号四种字符中的三种。不满足要求的话容器第一次初始化时就会失败日志里能看到密码策略检查不通过的错误。我见过很多人踩这个坑明明镜像和端口都没问题就是密码不够复杂导致容器反复重启。这里有个安全层面的补充建议密码不要硬编码在docker-compose.yml里。虽然开发环境问题不大但文件一旦提交到 Git密码就等于公开了。更稳的做法是使用环境变量插值把密码放在项目根目录的.env文件中然后配置里写成MSSQL_SA_PASSWORD: ${SA_PASSWORD}.env文件加进.gitignore。这样既能保证配置可共享又不会泄露敏感信息。MSSQL_PID用来指定产品版本上面已经提过开发测试直接用Developer。如果不设置这个变量默认值正好就是 Developer但显式写出来更清晰团队其他人看到配置时能立刻理解当前实例的版本定位。3.3 卷设计具名卷、绑定挂载与备份目录规划卷设计是整个配置里最值得花心思的部分因为数据库容器最怕“数据跟着容器走”。如果容器被删里面的数据库文件也跟着没了那损失是灾难性的。/var/opt/mssql是 SQL Server 在容器内保存数据文件和日志文件的默认目录。我在配置里把它挂载为一个具名卷mssql-data。具名卷由 Docker 管理存放在 Docker 的数据目录下数据不会因为容器删除而消失。相比绑定挂载具名卷在 Windows 和 macOS 环境下的性能更好也避开了文件权限的一系列坑。下次重新docker compose up新容器会自动复用这个卷之前建的库都还在。备份目录我用的是绑定挂载把宿主机当前目录下的./backup直接映射到容器内的/backup。这么做的原因是备份文件需要能被宿主机直接访问方便随后拷贝、上传或者拿去做还原测试。如果也塞进具名卷你想把备份文件拷出来还得额外绕一层docker cp非常不方便。还有一个细节如果使用绑定挂载到宿主机目录SQL Server 容器进程对目录需要有写权限。Linux 下如果遇到权限拒绝可以在宿主机上执行chmod -R 755或者干脆用chown调整目录归属。Windows 和 macOS 下 Docker Desktop 的文件共享机制一般能自动处理问题不大。4. 实操全流程从创建目录到连接查询配置理解到位之后实际操作就很快了。从创建项目目录到成功连上数据库正常情况五分钟就能搞定。这一节带你完整走一遍流程包括启动、验证、连接三个环节。4.1 目录结构与启动命令先创建一个工作目录比如~/docker/mssql-dev然后在这个目录下添加两个子目录backup用于放备份文件另外把上面的docker-compose.yml放进来。结构大概是这样mssql-dev/ ├── docker-compose.yml ├── backup/ └── .env如果你决定用.env管理密码就在目录下创建.env文件内容类似SA_PASSWORDYourStrong!Passw0rd然后 compose 文件里的密码字段改成${SA_PASSWORD}。改完之后在项目目录下执行启动命令docker compose up -d第一次执行会从微软镜像仓库拉取镜像这一步的耗时取决于网络状况。镜像大概 1.5GB 左右如果拉取速度感人可以检查 Docker 是否配置了镜像加速器。拉取完成后compose 会创建并启动容器。整个过程里不需要手动去创建数据卷具名卷会自动创建不需要手工指定网络compose 会为项目创建一个默认网络。4.2 容器状态检查与启动日志解读容器启动之后别急着连SQL Server 初始化需要一点时间。执行docker compose ps查看状态正常情况下STATUS列应该是Up。然后查看日志确认初始化完成docker compose logs -f sqlserver日志中出现类似这样的一行说明实例已经准备好接受连接了SQL Server is now ready for client connections. This is an informational message; no user action is required.这段日志非常重要。很多人看到容器状态是 Up 就立刻去连结果提示连接被拒绝其实就是因为实例还在启动中还没监听 1433 端口。多等十几秒再看日志基本就解决了。启动过程里还有个容易忽视的信号如果你在日志里看到不致命的警告比如SQL Server is attempting to register a Service Principal Name不用紧张那是容器环境下常见的正常消息不会影响使用。4.3 三种方式连接验证命令行、图形工具与 JDBC连接验证我建议先走命令行因为最直接、最少依赖。SQL Server 2022 容器镜像自带 sqlcmd 工具注意新版路径已经变成了/opt/mssql-tools18/bin/sqlcmd老教程里常见的/opt/mssql-tools/bin/sqlcmd在 2022 镜像里已经不存在了。可以从容器外部执行这么一条命令直接进入容器内跑查询docker exec -it mssql-dev /opt/mssql-tools18/bin/sqlcmd \ -S localhost -U sa -P YourStrong!Passw0rd -C \ -Q SELECT VERSION注意-C参数它表示信任服务器证书。sqlcmd 18 及配套的 ODBC Driver 18 默认要求加密连接不加这个参数连接会被 TLS 证书验证拦下来报错信息里会出现 SSL Provider 之类的字样。网上很多老教程没提这个变化导致不少人照着敲命令却连不上。图形化工具连接更简单。打开 Azure Data Studio新建连接服务器填localhost如果改了宿主端口就填localhost,14330用户名为sa密码填设置的密码。连接成功后左侧就能看到系统数据库列表。如果你用的是 IntelliJ IDEA 配 JDBC 连这个实例注意连接串要带着加密参数参考格式如下jdbc:sqlserver://localhost:1433;encrypttrue;trustServerCertificatetrue;databaseNamemasterencrypttrue和trustServerCertificatetrue这两个参数缺一不可。IDEA 里经常会遇到自动下载 Microsoft JDBC 驱动失败的问题实际上 Maven 仓库里这个驱动是可以正常访问的多试几次或者手动把mssql-jdbc的 jar 包放进依赖就行问题多半出在网络而不是驱动本身。5. 数据持久化与备份恢复别让数据跟着容器跑容器用起来爽但数据安全问题始终要摆在第一位。我见过不少同事用了容器以后懒得管备份直到某天不小心执行了docker compose down -v卷一起删掉才发现悲伤的故事已经无法挽回。这一节专门讲备份、还原和数据卷的规划。5.1 备份数据库到宿主机指定目录备份逻辑其实很简单在容器内执行标准的BACKUP DATABASE语句目标路径写成我们映射过的/backup目录即可。由于/backup已经绑定挂载到宿主机备份文件会直接落在宿主机上。先用 sqlcmd 验证一下备份能正常执行假设有一个业务库叫TestDBdocker exec -it mssql-dev /opt/mssql-tools18/bin/sqlcmd \ -S localhost -U sa -P YourStrong!Passw0rd -C \ -Q BACKUP DATABASE [TestDB] TO DISK N/backup/TestDB.bak WITH FORMAT, INIT;执行成功后去宿主机./backup目录下就能看到TestDB.bak文件。FORMAT参数会重新初始化备份介质避免旧备份影响INIT表示覆盖同名文件。如果哪天需要把这个备份文件发给同事直接拿它走即可。更规范一点的做法是结合定时任务做自动备份宿主机上可以写一个简单的 cron 任务定时执行 docker exec 触达备份命令。开发环境能自动做全量备份已经很够用了。5.2 还原数据库的常见报错与修复还原比备份稍微麻烦一点主要是两个经典问题文件路径和名称冲突。先查看备份文件里的逻辑文件名docker exec -it mssql-dev /opt/mssql-tools18/bin/sqlcmd \ -S localhost -U sa -P YourStrong!Passw0rd -C \ -Q RESTORE FILELISTONLY FROM DISK N/backup/TestDB.bak;这一步会列出备份内的逻辑文件名比如TestDB和TestDB_log。还原时要通过MOVE参数把它们重新定位到/var/opt/mssql/data目录下否则会尝试往备份文件原来所在的路径写默认不存在就报错。一个典型的还原语句长这样RESTORE DATABASE [TestDB_Restored] FROM DISK N/backup/TestDB.bak WITH MOVE TestDB TO /var/opt/mssql/data/TestDB_Restored.mdf, MOVE TestDB_log TO /var/opt/mssql/data/TestDB_Restored_log.ldf, REPLACE;REPLACE参数可以覆盖同名数据库省掉先删库的步骤。如果还原时报“数据库正在使用”通常是目标库还连着活跃会话可以先执行ALTER DATABASE [TestDB_Restored] SET SINGLE_USER WITH ROLLBACK IMMEDIATE;再重新还原。5.3 数据卷层面的备份策略与存储空间规划数据库层面的备份之外还有个更粗粒度的思路直接备份整个数据卷目录。对于开发环境这是一种简单的应急手段。找一下具名卷的实际位置Linux 下可以执行docker volume inspect mssql-dev_mssql-data查看挂载点然后把整个目录拷走。但注意这种做法在做物理备份时不一定保证一致性数据库引擎仍在运行直接拷贝 MDF 和 LDF 文件有风险。应急可以常态化还是建议走 SQL Server 自身的备份命令。关于存储空间规划这里想多说几句。搜索热词里有一条“sqlserver 单表上亿存储空间太大”这个话题和容器环境也有关联。SQL Server 数据库文件默认是自动增长的但每次增长的幅度如果设置得不合理上亿行的表会让 MDF 文件频繁扩展既占空间又影响性能。建议在容器里给数据文件提前规划好初始大小并用MAXSIZE限制增长上限。例如ALTER DATABASE [TestDB] MODIFY FILE (NAME TestDB, SIZE 10GB, FILEGROWTH 512MB, MAXSIZE 50GB);然后把/var/opt/mssql挂载到宿主机的高性能磁盘上避免把数据卷放在空间不足的系统分区里。容器帮你省去安装流程但数据库本身的体量管理还是得按数据库的规矩来。6. 资源控制与性能调优让 SQL Server 学会“克制”SQL Server 这个进程在资源使用上相当“贪婪”如果不主动限制它会把宿主机的大部分内存都纳入自己的缓冲池。这在容器环境里是个必须处理的问题否则你开发机上其他程序会被拖到卡顿。docker-compose 提供了简单的资源限制参数用上之后体验会好很多。6.1 内存限制为什么必须设置 mem_limit如果你只给 SQL Server 设置一个参数那一定选mem_limit。如果不限制SQL Server 会动态占用宿主机的绝大部分空闲内存即便你的库只有几十 MB 数据它也会把内存预留给未来的数据页使用。在开发机上跑这套容器同时还要开浏览器、IDE、Docker 里其他容器内存瞬间告急。我通常给 SQL Server 容器分配宿主总内存的一半左右。8GB 内存的开发机给4g16GB 的给8g。注意不要低于 2GB否则 SQL Server 启动时会因为不满足最低内存需求直接退出。services: sqlserver: mem_limit: 4g设了mem_limit之后SQL Server 也会在这个上限内自行管理缓冲池大小不需要再手动配置max server memory。运维上省心很多。6.2 CPU 限制、时区设置与存储考量CPU 限制也一样重要不过通常没那么紧急。cpus: 2表示容器最多使用两个 CPU 核心。开发场景下数据库查询量不大两个核心绰绰有余。如果你的开发机本身核数不多也可以设成cpus: 1代价只是复杂查询会更慢。时区是个经常被忽略的细节。SQL Server 容器默认使用 UTC 时间而我们在东八区查询GETDATE()的时候会看到比本地时间慢 8 小时。解决方案有三种一是配置里加上TZ: Asia/Shanghai环境变量二是把宿主机的/etc/localtime以只读方式挂载到容器三是在连接后手动执行SET TIMEZONE类逻辑。最省事的就是直接配置TZ这也是我在示例配置里写好的做法。最后说一下存储性能的考量。如果你要在容器里跑比较重的查询建议把数据卷放在 SSD 上尤其是日志文件所在的 LDFIO 延迟影响会非常明显。Docker Desktop 在 macOS 和 Windows 上默认使用虚拟磁盘性能比原生 Linux 环境略差但对开发调试来说完全够用。真到了追求性能的阶段就该考虑把数据库部署到专用服务器或云数据库上了。7. 常见问题排查我踩过的坑与速查表容器化部署虽然省心但也不是没有坑。这一节把我在实际使用中踩过、或者身边同事经常碰到的问题整理出来按现象、原因、解决方案的顺序列成速查表方便你遇到问题时直接对照。7.1 起不来内存不足、端口占用与密码不达标容器启动后马上退出或者反复重启最常见的有三个原因。内存不足是最经典的。宿主机内存不够 2GB或 Docker 分配的内存不够SQL Server 会在日志里打印明确的提示。解决方案很直接释放内存、加内存或者在 Docker Desktop 设置里调大分配给虚拟机的内存。端口冲突也很常见。docker compose up -d执行后如果提示bind: address already in use说明宿主机 1433 端口已经被占用。跑一下lsof -i :1433Linux/macOS或者netstat -ano | findstr 1433Windows找到占用进程然后要么停掉它要么把 compose 里端口映射改成14330:1433。还有一个原因就是 SA 密码不满足强密码策略。启动日志里如果出现Password policy check failed直接换一个包含大小写字母、数字和符号的强密码即可。7.2 连不上sqlcmd 加密参数、防火墙与 IPv6 问题容器明明起来了客户端却连不上这是第二大类问题。新版本 sqlcmd 和 ODBC Driver 18 默认加密导致连接时报证书相关的 SSL 错误解决方法是加上-C参数或者连接串里加trustServerCertificatetrue。这个问题我前面已经强调过这里再次单列因为它真的太常见了。另一个容易忽略的是防火墙。如果你在远程服务器上用 Docker 跑 SQL Server即使容器端口映射正常云服务商的安全组或本机防火墙没有放行对应端口连接一样会被拦截。在云服务器上排查问题时先确认安全组入站规则放行了 1433或自定义端口再检查宿主机防火墙。IPv6 相关的坑也值得提一下。某些环境下 DNS 解析或客户端默认尝试 IPv6 回环地址可能导致连接超时。如果客户端连接时指定localhost失败但指定127.0.0.1成功可以尝试在 hosts 里把关 mapping或者直接连接 IP 地址。7.3 数据与时间相关的补充问题数据库时间跟本地差 8 小时的问题前面已经给了解决方案。这里补充一个场景如果你在容器里创建表时发现默认排序规则对中文支持不友好可以在首次启动时通过环境变量MSSQL_COLLATION指定排序规则比如Chinese_PRC_CI_AS。这个参数必须在容器初始化之前设置数据库文件建好之后再改排序规则会非常麻烦所以一开始就定好是关键。另外两个热词也顺带回应一下。一个是“sqlserver 字符串转数字”在 T-SQL 里可以用TRY_CAST或TRY_CONVERT比如SELECT TRY_CAST(123 AS INT)安全转换转换失败会返回 NULL 而不是报错这是我很推荐的方式。另一个是“sqlserver 多行合并成一行”用STRING_AGG函数就能实现例如SELECT STRING_AGG(name, ,) FROM sys.databases;会把所有库名用逗号拼接成一行。这两个技能点配合 docker 容器里的实机练习上手会非常快。关于这个方案我最后的一些体会如果你问我现在给一个从零开始学 SQL Server 或者需要在本地起一套开发库的人推荐什么安装方式我大概率直接把这份 compose 文件甩过去。从实际使用的角度看docker-compose 把安装、启动、销毁、重来这几个动作全部标准化了无论换机器还是换同事环境一致的代价都降到最低。实际跑下来最爽的一个场景是团队新来了一个实习生之前从没装过 SQL Server。我把项目目录给他他执行docker compose up -d然后打开 Azure Data Studio 连上去全程不到三分钟。这就是基础设施代码化的好处不用反复口述安装步骤一份配置文件就把环境描述清楚了。最后分享一个小技巧。如果你需要在本地同时维护多个版本的 SQL Server可以通过多个 compose 文件或者端口映射来区分比如 2019 映射到 143302022 映射到 14331。开发时想切换版本只需要连接不同端口即可不用像过去那样卸载安装再重启大半天。这种做法我用了很久体验非常稳定值得你试试。 用Docker Compose跑SQL Server：告别本地安装折磨的完整实践
说实话我之所以认真研究用 docker-compose 跑 sqlserver完全是被本地安装折腾怕了。最早装 SQL Server 2012 的时候光下载安装包就花了大半天中间还蹦出个“句柄无效”的报错卸载重装了两次才过。后来换了电脑又得从头折腾一遍安装包下载、环境变量、防火墙、配置管理器一套流程走下来小半天就没了。直到我改成 docker-compose 启动 sql-server这个体验才彻底翻转过来一份配置文件一条启动命令干干净净的容器实例就跑起来了用完还能一键销毁完全不污染宿主机。这篇内容不是什么高深教程就是我把 sqlserver 容器化之后沉淀下来的完整实操记录。适合在本地做开发调试、跟着课程学数据库、搭 CI 验证脚本、或者临时给团队起一套测试环境的人参考。如果你也有过被 SQL Server 安装向导折磨的经历这篇文章能让你少走很多弯路。1. 为什么我最终选了 docker-compose本地安装的坑与方案对比很多人觉得 SQL Server 嘛到官网下个安装包一路 Next 不就行了真上手过的人都知道这套流程远没那么顺滑。尤其当你的主力开发机是 macOS 或者 Linux想在本地跑一套 SQL Server传统安装方式基本是死路一条。即使是 Windows 环境多版本共存、卸载残留、服务配置这些坑也够喝一壶的。1.1 本地装 SQL Server 的三大痛点第一个痛点是安装包体积和下载速度。SQL Server 的安装镜像动辄几个 G在网速不理想的时候光是下载就足够劝退。更别提安装过程中还经常出现各种奇怪的报错热搜词里那个“句柄无效 HRESULT”的异常我当年也撞到过最后只能靠卸载重装解决折腾到怀疑人生。第二个痛点是环境残留和版本冲突。同一台机器上装过 2012 再装 2019或者装过默认实例再装命名实例服务列表、注册表、配置管理器里的条目会非常混乱。卸载时你以为卸干净了下次装新版照样可能因为旧组件残留导致失败。你甚至能找到专门用于清理 SQL Server 残留的第三方工具光这一点就说明问题有多普遍。第三个痛点是跨平台支持太差。虽然微软后来出了 SQL Server on Linux 版本但安装步骤依然不轻松依赖库、权限、配置步骤一大堆。如果你用的是 Apple Silicon 芯片的 Mac本地安装这条路更是基本走不通只能退而求其次连远程服务器。我见过不少新同事入职第一天光装开发环境就耗掉一整天最后卡在 SQL Server 上求助。1.2 同类方案横向对比纯 docker run 与 docker-compose 的取舍有人可能会说既然要用容器直接docker run一条命令不就行了为什么还要多此一举引入 docker-compose我最初也是这么干的但用了几次就发现问题了。docker run那条命令本身就长得离谱镜像名、环境变量、端口映射、数据卷、内存限制全堆在一块复制到终端里换行逻辑混乱想改一个参数还得在长串命令里找半天。更麻烦的是这种命令不容易共享给同事也不方便沉淀到项目仓库里。docker-compose 的核心价值在于把“环境配置”变成一份可以提交到 Git 的声明式文件。你只需要维护一个docker-compose.yml里面写了什么镜像、什么端口、什么数据卷、什么环境变量团队里的任何人拉下来执行一句docker compose up -d就能得到一套完全一致的 SQL Server。这比发一段复杂命令让同事自己去复制粘贴要可靠得多也比写一篇长篇安装文档更省心。从运维角度看docker-compose 对容器生命周期的管理也更友好。docker compose down可以整体停掉并删除docker compose restart可以重启服务配合卷挂载还能保证删容器不删数据。这种体验接近“用完即焚需要再来”非常契合开发测试环境的诉求。1.3 这套方案适合谁又不适合谁先说明一点这套容器化方案也有边界不是所有场景都适合。它最适合的是三类人第一类是开发人员本地需要一台随时可用的 SQL Server 实例做调试第二类是测试和 CI 环境维护者需要在流水线里快速拉起、销毁数据库实例第三类是学习数据库的新手想快速体验 SQL Server 而不想被安装过程劝退。如果你追求的是生产环境的高可用、极限性能或者复杂的 Windows 集成功能比如 SQL Server Agent 任务、SSIS、Reporting Services、AlwaysOn 可用性组等那容器化方案还达不到直接顶上线的程度。生产环境仍然建议使用云数据库或者专门的数据库服务器容器用于开发和测试更稳妥。认清边界才能用对工具。2. 动手前准备镜像选型、环境检查和工具搭配写配置文件之前有几件事需要先定下来。最核心的是选哪个版本的 SQL Server 镜像其次要确认宿主机环境满足容器运行条件最后是准备一套顺手的连接工具。这几步看着不起眼但选错了镜像版本或者忽略了环境限制后面启动时大概率会翻车。2.1 镜像版本怎么选2022 还是 2019Developer 还是 Express微软官方维护的 SQL Server 容器镜像托管在mcr.microsoft.com/mssql/server仓库下目前最常用的两个大版本是 2019 和 2022。我个人建议新项目直接用 2022毕竟功能更新、支持周期更长如果你的生产库还停留在 2019为了本地与线上版本保持一致也可以用 2019 镜像。两者在容器化部署方式上完全一样差别只在 SQL Server 版本功能。另一个关键选项是MSSQL_PID环境变量也就是产品版本。开发测试建议用Developer这个版本拥有企业版级别的全部功能而且免费没有 180 天过期的坑。Express版本功能受限数据库单库上限是 10GB除非你刻意模拟 Express 的限制否则没有理由选它。Standard和Enterprise需要许可证一般只在测试商业版特性时才需要指定。这里有个容易踩的坑某些第三方教程会让你拉取mcr.microsoft.com/mssql/server:latest这个标签。latest的指向有时并不直观建议直接用明确的版本标签比如2022-latest。这样拉了哪个版本自己心里有数排障时也容易定位。2.2 宿主机环境检查内存、引擎与端口占用在动手之前先用一条命令确认 Docker 环境本身是健康的。打开终端执行docker version确认 Docker Engine 版本比较新。然后执行docker compose version确认识别到了 compose 插件。这里顺便说一句新版 Docker 已经内置了docker compose子命令如果你还在用需要单独下载的旧版docker-compose建议尽早迁移命令格式基本不变但性能和兼容性更好。内存是启动 SQL Server 容器最关键的硬指标。SQL Server 进程要求至少 2GB 可用内存否则容器启动后会立刻退出日志里会明确提示“This program requires a machine with at least 2 gigabytes of RAM”。如果你的开发机只有 8GB 内存还同时在跑 IDE、浏览器和一堆容器务必给 SQL Server 预留足够的额度或者在 compose 里显式限制容器内存。端口方面要检查 1433 是否被占用。宿主机上如果已经装了 SQL Server 或者别的服务占了这个端口容器启动时会报bind: address already in use。解决方案很简单把宿主端口改成一个不冲突的数值比如14330:1433连接时连 14330 即可。2.3 连接工具的搭配推荐容器本身只是数据库服务真正干活还得靠客户端工具。我经常被问到用什么连 SQL Server 比较好这里列一张简单的对比表供不同需求的人参考。工具平台支持特点适用场景SSMSWindows功能最全数据库管理运维能力强DBA、Windows 用户深度管理Azure Data StudioWin/macOS/Linux轻量、跨平台、适合写查询和脚本开发调试、Mac/Linux 用户首选DBeaverWin/macOS/Linux通用型客户端支持多种数据库需要同时管理多种数据库的人sqlcmd容器内/命令行轻量命令行工具适合脚本和自动化容器内快速查询、CI 流水线如果你在网上搜过“sqlserver 图形化工具”这个词大概率会看到上面几个名字。我的组合是日常写查询用 Azure Data Studio需要精细管理实例配置时换 SSMS自动化脚本里用 sqlcmd。三个工具身份认证方式都能直接用sa账号连接容器启动后填入账号密码就能干活。3. docker-compose.yml 逐行拆解环境变量、端口与数据卷到底该怎么写那份关键的docker-compose.yml这一节我会把配置文件里的每一行都拆开讲清楚保证你拿回去能直接改、直接跑。同时还会解释为什么这些配置要这么写避免照抄之后不知道在调什么。3.1 一份可以直接抄的配置文件先给出一份完整的、经过我实测的配置文件然后再逐段解释。直接用这份文件能省掉很多摸索时间但对每一行的含义还是要了解清楚。services: sqlserver: image: mcr.microsoft.com/mssql/server:2022-latest container_name: mssql-dev environment: ACCEPT_EULA: Y MSSQL_SA_PASSWORD: YourStrong!Passw0rd MSSQL_PID: Developer TZ: Asia/Shanghai ports: - 1433:1433 volumes: - mssql-data:/var/opt/mssql - ./backup:/backup mem_limit: 4g cpus: 2 restart: unless-stopped volumes: mssql-data:这里我没有写version字段因为新版 docker compose 已经把它标记为 obsolete写上也只是为了兼容旧工具会额外弹提示所以不写更干净。三个环境变量是启动 SQL Server 容器必须提供的一个是ACCEPT_EULA一个是MSSQL_SA_PASSWORD另外建议显式指定MSSQL_PID。下面逐个说。3.2 三个关键环境变量的含义与密码策略ACCEPT_EULA用来接受微软的最终用户许可协议必须设置为Y否则容器会拒绝启动。这个变量没什么技术含量但它提醒你一件事SQL Server 虽然被容器化但许可规则没有变开发和测试用 Developer 版本也要遵守协议条款。MSSQL_SA_PASSWORD是超级管理员sa的初始密码。这个密码必须满足 SQL Server 的强密码策略至少 8 位同时包含大写字母、小写字母、数字和符号四种字符中的三种。不满足要求的话容器第一次初始化时就会失败日志里能看到密码策略检查不通过的错误。我见过很多人踩这个坑明明镜像和端口都没问题就是密码不够复杂导致容器反复重启。这里有个安全层面的补充建议密码不要硬编码在docker-compose.yml里。虽然开发环境问题不大但文件一旦提交到 Git密码就等于公开了。更稳的做法是使用环境变量插值把密码放在项目根目录的.env文件中然后配置里写成MSSQL_SA_PASSWORD: ${SA_PASSWORD}.env文件加进.gitignore。这样既能保证配置可共享又不会泄露敏感信息。MSSQL_PID用来指定产品版本上面已经提过开发测试直接用Developer。如果不设置这个变量默认值正好就是 Developer但显式写出来更清晰团队其他人看到配置时能立刻理解当前实例的版本定位。3.3 卷设计具名卷、绑定挂载与备份目录规划卷设计是整个配置里最值得花心思的部分因为数据库容器最怕“数据跟着容器走”。如果容器被删里面的数据库文件也跟着没了那损失是灾难性的。/var/opt/mssql是 SQL Server 在容器内保存数据文件和日志文件的默认目录。我在配置里把它挂载为一个具名卷mssql-data。具名卷由 Docker 管理存放在 Docker 的数据目录下数据不会因为容器删除而消失。相比绑定挂载具名卷在 Windows 和 macOS 环境下的性能更好也避开了文件权限的一系列坑。下次重新docker compose up新容器会自动复用这个卷之前建的库都还在。备份目录我用的是绑定挂载把宿主机当前目录下的./backup直接映射到容器内的/backup。这么做的原因是备份文件需要能被宿主机直接访问方便随后拷贝、上传或者拿去做还原测试。如果也塞进具名卷你想把备份文件拷出来还得额外绕一层docker cp非常不方便。还有一个细节如果使用绑定挂载到宿主机目录SQL Server 容器进程对目录需要有写权限。Linux 下如果遇到权限拒绝可以在宿主机上执行chmod -R 755或者干脆用chown调整目录归属。Windows 和 macOS 下 Docker Desktop 的文件共享机制一般能自动处理问题不大。4. 实操全流程从创建目录到连接查询配置理解到位之后实际操作就很快了。从创建项目目录到成功连上数据库正常情况五分钟就能搞定。这一节带你完整走一遍流程包括启动、验证、连接三个环节。4.1 目录结构与启动命令先创建一个工作目录比如~/docker/mssql-dev然后在这个目录下添加两个子目录backup用于放备份文件另外把上面的docker-compose.yml放进来。结构大概是这样mssql-dev/ ├── docker-compose.yml ├── backup/ └── .env如果你决定用.env管理密码就在目录下创建.env文件内容类似SA_PASSWORDYourStrong!Passw0rd然后 compose 文件里的密码字段改成${SA_PASSWORD}。改完之后在项目目录下执行启动命令docker compose up -d第一次执行会从微软镜像仓库拉取镜像这一步的耗时取决于网络状况。镜像大概 1.5GB 左右如果拉取速度感人可以检查 Docker 是否配置了镜像加速器。拉取完成后compose 会创建并启动容器。整个过程里不需要手动去创建数据卷具名卷会自动创建不需要手工指定网络compose 会为项目创建一个默认网络。4.2 容器状态检查与启动日志解读容器启动之后别急着连SQL Server 初始化需要一点时间。执行docker compose ps查看状态正常情况下STATUS列应该是Up。然后查看日志确认初始化完成docker compose logs -f sqlserver日志中出现类似这样的一行说明实例已经准备好接受连接了SQL Server is now ready for client connections. This is an informational message; no user action is required.这段日志非常重要。很多人看到容器状态是 Up 就立刻去连结果提示连接被拒绝其实就是因为实例还在启动中还没监听 1433 端口。多等十几秒再看日志基本就解决了。启动过程里还有个容易忽视的信号如果你在日志里看到不致命的警告比如SQL Server is attempting to register a Service Principal Name不用紧张那是容器环境下常见的正常消息不会影响使用。4.3 三种方式连接验证命令行、图形工具与 JDBC连接验证我建议先走命令行因为最直接、最少依赖。SQL Server 2022 容器镜像自带 sqlcmd 工具注意新版路径已经变成了/opt/mssql-tools18/bin/sqlcmd老教程里常见的/opt/mssql-tools/bin/sqlcmd在 2022 镜像里已经不存在了。可以从容器外部执行这么一条命令直接进入容器内跑查询docker exec -it mssql-dev /opt/mssql-tools18/bin/sqlcmd \ -S localhost -U sa -P YourStrong!Passw0rd -C \ -Q SELECT VERSION注意-C参数它表示信任服务器证书。sqlcmd 18 及配套的 ODBC Driver 18 默认要求加密连接不加这个参数连接会被 TLS 证书验证拦下来报错信息里会出现 SSL Provider 之类的字样。网上很多老教程没提这个变化导致不少人照着敲命令却连不上。图形化工具连接更简单。打开 Azure Data Studio新建连接服务器填localhost如果改了宿主端口就填localhost,14330用户名为sa密码填设置的密码。连接成功后左侧就能看到系统数据库列表。如果你用的是 IntelliJ IDEA 配 JDBC 连这个实例注意连接串要带着加密参数参考格式如下jdbc:sqlserver://localhost:1433;encrypttrue;trustServerCertificatetrue;databaseNamemasterencrypttrue和trustServerCertificatetrue这两个参数缺一不可。IDEA 里经常会遇到自动下载 Microsoft JDBC 驱动失败的问题实际上 Maven 仓库里这个驱动是可以正常访问的多试几次或者手动把mssql-jdbc的 jar 包放进依赖就行问题多半出在网络而不是驱动本身。5. 数据持久化与备份恢复别让数据跟着容器跑容器用起来爽但数据安全问题始终要摆在第一位。我见过不少同事用了容器以后懒得管备份直到某天不小心执行了docker compose down -v卷一起删掉才发现悲伤的故事已经无法挽回。这一节专门讲备份、还原和数据卷的规划。5.1 备份数据库到宿主机指定目录备份逻辑其实很简单在容器内执行标准的BACKUP DATABASE语句目标路径写成我们映射过的/backup目录即可。由于/backup已经绑定挂载到宿主机备份文件会直接落在宿主机上。先用 sqlcmd 验证一下备份能正常执行假设有一个业务库叫TestDBdocker exec -it mssql-dev /opt/mssql-tools18/bin/sqlcmd \ -S localhost -U sa -P YourStrong!Passw0rd -C \ -Q BACKUP DATABASE [TestDB] TO DISK N/backup/TestDB.bak WITH FORMAT, INIT;执行成功后去宿主机./backup目录下就能看到TestDB.bak文件。FORMAT参数会重新初始化备份介质避免旧备份影响INIT表示覆盖同名文件。如果哪天需要把这个备份文件发给同事直接拿它走即可。更规范一点的做法是结合定时任务做自动备份宿主机上可以写一个简单的 cron 任务定时执行 docker exec 触达备份命令。开发环境能自动做全量备份已经很够用了。5.2 还原数据库的常见报错与修复还原比备份稍微麻烦一点主要是两个经典问题文件路径和名称冲突。先查看备份文件里的逻辑文件名docker exec -it mssql-dev /opt/mssql-tools18/bin/sqlcmd \ -S localhost -U sa -P YourStrong!Passw0rd -C \ -Q RESTORE FILELISTONLY FROM DISK N/backup/TestDB.bak;这一步会列出备份内的逻辑文件名比如TestDB和TestDB_log。还原时要通过MOVE参数把它们重新定位到/var/opt/mssql/data目录下否则会尝试往备份文件原来所在的路径写默认不存在就报错。一个典型的还原语句长这样RESTORE DATABASE [TestDB_Restored] FROM DISK N/backup/TestDB.bak WITH MOVE TestDB TO /var/opt/mssql/data/TestDB_Restored.mdf, MOVE TestDB_log TO /var/opt/mssql/data/TestDB_Restored_log.ldf, REPLACE;REPLACE参数可以覆盖同名数据库省掉先删库的步骤。如果还原时报“数据库正在使用”通常是目标库还连着活跃会话可以先执行ALTER DATABASE [TestDB_Restored] SET SINGLE_USER WITH ROLLBACK IMMEDIATE;再重新还原。5.3 数据卷层面的备份策略与存储空间规划数据库层面的备份之外还有个更粗粒度的思路直接备份整个数据卷目录。对于开发环境这是一种简单的应急手段。找一下具名卷的实际位置Linux 下可以执行docker volume inspect mssql-dev_mssql-data查看挂载点然后把整个目录拷走。但注意这种做法在做物理备份时不一定保证一致性数据库引擎仍在运行直接拷贝 MDF 和 LDF 文件有风险。应急可以常态化还是建议走 SQL Server 自身的备份命令。关于存储空间规划这里想多说几句。搜索热词里有一条“sqlserver 单表上亿存储空间太大”这个话题和容器环境也有关联。SQL Server 数据库文件默认是自动增长的但每次增长的幅度如果设置得不合理上亿行的表会让 MDF 文件频繁扩展既占空间又影响性能。建议在容器里给数据文件提前规划好初始大小并用MAXSIZE限制增长上限。例如ALTER DATABASE [TestDB] MODIFY FILE (NAME TestDB, SIZE 10GB, FILEGROWTH 512MB, MAXSIZE 50GB);然后把/var/opt/mssql挂载到宿主机的高性能磁盘上避免把数据卷放在空间不足的系统分区里。容器帮你省去安装流程但数据库本身的体量管理还是得按数据库的规矩来。6. 资源控制与性能调优让 SQL Server 学会“克制”SQL Server 这个进程在资源使用上相当“贪婪”如果不主动限制它会把宿主机的大部分内存都纳入自己的缓冲池。这在容器环境里是个必须处理的问题否则你开发机上其他程序会被拖到卡顿。docker-compose 提供了简单的资源限制参数用上之后体验会好很多。6.1 内存限制为什么必须设置 mem_limit如果你只给 SQL Server 设置一个参数那一定选mem_limit。如果不限制SQL Server 会动态占用宿主机的绝大部分空闲内存即便你的库只有几十 MB 数据它也会把内存预留给未来的数据页使用。在开发机上跑这套容器同时还要开浏览器、IDE、Docker 里其他容器内存瞬间告急。我通常给 SQL Server 容器分配宿主总内存的一半左右。8GB 内存的开发机给4g16GB 的给8g。注意不要低于 2GB否则 SQL Server 启动时会因为不满足最低内存需求直接退出。services: sqlserver: mem_limit: 4g设了mem_limit之后SQL Server 也会在这个上限内自行管理缓冲池大小不需要再手动配置max server memory。运维上省心很多。6.2 CPU 限制、时区设置与存储考量CPU 限制也一样重要不过通常没那么紧急。cpus: 2表示容器最多使用两个 CPU 核心。开发场景下数据库查询量不大两个核心绰绰有余。如果你的开发机本身核数不多也可以设成cpus: 1代价只是复杂查询会更慢。时区是个经常被忽略的细节。SQL Server 容器默认使用 UTC 时间而我们在东八区查询GETDATE()的时候会看到比本地时间慢 8 小时。解决方案有三种一是配置里加上TZ: Asia/Shanghai环境变量二是把宿主机的/etc/localtime以只读方式挂载到容器三是在连接后手动执行SET TIMEZONE类逻辑。最省事的就是直接配置TZ这也是我在示例配置里写好的做法。最后说一下存储性能的考量。如果你要在容器里跑比较重的查询建议把数据卷放在 SSD 上尤其是日志文件所在的 LDFIO 延迟影响会非常明显。Docker Desktop 在 macOS 和 Windows 上默认使用虚拟磁盘性能比原生 Linux 环境略差但对开发调试来说完全够用。真到了追求性能的阶段就该考虑把数据库部署到专用服务器或云数据库上了。7. 常见问题排查我踩过的坑与速查表容器化部署虽然省心但也不是没有坑。这一节把我在实际使用中踩过、或者身边同事经常碰到的问题整理出来按现象、原因、解决方案的顺序列成速查表方便你遇到问题时直接对照。7.1 起不来内存不足、端口占用与密码不达标容器启动后马上退出或者反复重启最常见的有三个原因。内存不足是最经典的。宿主机内存不够 2GB或 Docker 分配的内存不够SQL Server 会在日志里打印明确的提示。解决方案很直接释放内存、加内存或者在 Docker Desktop 设置里调大分配给虚拟机的内存。端口冲突也很常见。docker compose up -d执行后如果提示bind: address already in use说明宿主机 1433 端口已经被占用。跑一下lsof -i :1433Linux/macOS或者netstat -ano | findstr 1433Windows找到占用进程然后要么停掉它要么把 compose 里端口映射改成14330:1433。还有一个原因就是 SA 密码不满足强密码策略。启动日志里如果出现Password policy check failed直接换一个包含大小写字母、数字和符号的强密码即可。7.2 连不上sqlcmd 加密参数、防火墙与 IPv6 问题容器明明起来了客户端却连不上这是第二大类问题。新版本 sqlcmd 和 ODBC Driver 18 默认加密导致连接时报证书相关的 SSL 错误解决方法是加上-C参数或者连接串里加trustServerCertificatetrue。这个问题我前面已经强调过这里再次单列因为它真的太常见了。另一个容易忽略的是防火墙。如果你在远程服务器上用 Docker 跑 SQL Server即使容器端口映射正常云服务商的安全组或本机防火墙没有放行对应端口连接一样会被拦截。在云服务器上排查问题时先确认安全组入站规则放行了 1433或自定义端口再检查宿主机防火墙。IPv6 相关的坑也值得提一下。某些环境下 DNS 解析或客户端默认尝试 IPv6 回环地址可能导致连接超时。如果客户端连接时指定localhost失败但指定127.0.0.1成功可以尝试在 hosts 里把关 mapping或者直接连接 IP 地址。7.3 数据与时间相关的补充问题数据库时间跟本地差 8 小时的问题前面已经给了解决方案。这里补充一个场景如果你在容器里创建表时发现默认排序规则对中文支持不友好可以在首次启动时通过环境变量MSSQL_COLLATION指定排序规则比如Chinese_PRC_CI_AS。这个参数必须在容器初始化之前设置数据库文件建好之后再改排序规则会非常麻烦所以一开始就定好是关键。另外两个热词也顺带回应一下。一个是“sqlserver 字符串转数字”在 T-SQL 里可以用TRY_CAST或TRY_CONVERT比如SELECT TRY_CAST(123 AS INT)安全转换转换失败会返回 NULL 而不是报错这是我很推荐的方式。另一个是“sqlserver 多行合并成一行”用STRING_AGG函数就能实现例如SELECT STRING_AGG(name, ,) FROM sys.databases;会把所有库名用逗号拼接成一行。这两个技能点配合 docker 容器里的实机练习上手会非常快。关于这个方案我最后的一些体会如果你问我现在给一个从零开始学 SQL Server 或者需要在本地起一套开发库的人推荐什么安装方式我大概率直接把这份 compose 文件甩过去。从实际使用的角度看docker-compose 把安装、启动、销毁、重来这几个动作全部标准化了无论换机器还是换同事环境一致的代价都降到最低。实际跑下来最爽的一个场景是团队新来了一个实习生之前从没装过 SQL Server。我把项目目录给他他执行docker compose up -d然后打开 Azure Data Studio 连上去全程不到三分钟。这就是基础设施代码化的好处不用反复口述安装步骤一份配置文件就把环境描述清楚了。最后分享一个小技巧。如果你需要在本地同时维护多个版本的 SQL Server可以通过多个 compose 文件或者端口映射来区分比如 2019 映射到 143302022 映射到 14331。开发时想切换版本只需要连接不同端口即可不用像过去那样卸载安装再重启大半天。这种做法我用了很久体验非常稳定值得你试试。