我比较认同... Debian向来以“稳如老狗”闻名，而SQL Server则是微软的“重量级选手”。把两者强行捆绑在一起，有时候会出现让人抓狂的异常。别慌， 这篇文章用最接地气的方式，把从“服务不启动”到“性能瓶颈”全套流程拆解出来让你在面对突发状况时不至于手足无措。

一、 先确认服务到底跑没跑——基本检查

很多新手在装完包后直接去写业务代码，却忘了先检查服务状态。 请大家务必... 下面这几条命令是必备的“开门神器”。

systemctl status mssql-server          # 查看当前运行状态
sudo systemctl start mssql-server       # 启动服务
sudo systemctl enable mssql-server      # 设置开机自启
journalctl -u mssql-server -f          # 实时追踪日志输出

如果status显示inactive 或者failed那就意味着有更深层的问题需要进一步挖掘。

常见错误码速查表

错误码	可能原因	推荐处理方式
0x80131904	配置文件语法错误	检查 /etc/opt/mssql/mssql.conf 并使用 mssql-conf reconfigure 修正
0xC0000135	缺失依赖库（如 libunwind)	apt-get install libunwind8 libssl1.1 等缺失包
0xC0000142	权限不足或 SELinux/AppArmor 拦截	确认 mssql 用户对 /var/opt/mssql 有读写权限；关闭 AppArmor 或添加例外规则
-2146232060	认证模式不匹配或 SA 密码错误	使用 sqlcmd -S localhost -U SA -P '新密码' 测试登录；必要时重置密码：/opt/mssql/bin/mssql-conf set-sa-password --password=NewPass123!

二、 日志是最好的老师——深入查看错误信息

我跪了。 系统日志与SQL Server专属日志往往交叉出现，需要分别抓取：

• /var/log/syslog：记录内核、系统服务以及平安审计信息。
• /var/opt/mssql/log/errorlog：MSSQL 自己的运行时错误、启动信息以及警告。
• /var/opt/mssql/log/sqlservr.out：MSSQL 标准输出流。

操作一波... 举个例子， 当你看到类似下面的片段时就该动真格了：

 Could not locate file '/var/opt/mssql/data/master.mdf'.
 The operating system returned error code 5 when attempting to open file.
 Fatal error: 18456, Severity: 14, State: 38.
Login failed for user 'sa'. Reason: Password mismatch.

内卷。 这时候先确认磁盘挂载是否正常）。如果磁盘已满，赶紧清理旧备份或扩容。

三、 资源监控——找出性能瓶颈的根源

层次低了。 SQ L Server 在 Linux 上对 CPU、内存和磁盘 I/O 的要求不低。一旦资源被其他进程抢占，就会出现查询卡顿甚至超时。以下工具可以帮助你“一眼看穿”。

• top / htop：实时观察 CPU 与内存占用情况。
• I/O：iostat -xz 1：SATA/NVMe 的吞吐量与延迟，一秒钟刷新一次。
• dstat：CPI、网络流量与磁盘写入速率一起呈现。
• PROMETHEUS + GRAFANA：If you have a monitoring stack, add MSSQL exporter for long‑term趋势分析。

小贴士：如果发现 CPU 利用率长期高于 80%， 先说说检查是否有大量并发查询；如果磁盘 I/O 延迟超过 10ms，则考虑开启 SSD 缓存或迁移数据文件至更快的卷，走捷径。。

四、网络连通性——别让防火墙把你拦住

MSSQL 默认监听 TCP 1433。如果你的应用服务器与 Debian 主机之间跨子网，请务必验证端口是否通畅。

# 检查本机监听端口
ss -tlnp | grep 1433
# 从远端机器测试连通性
nc -zv 192.168.10.20 1433
telnet 192.168.10.20 1433   # 若提示连接成功， 即可继续
# 查看防火墙规则
ufw status | grep 1433
# 如未放行，则施行：
ufw allow 1433/tcp
ufw reload

千万别忘了在 /etc/hosts.allow & hosts.deny 中也要对应放行，否则即使防火墙开放仍会被本地访问控制阻断，换个思路。。

五、 依赖与兼容性——Debian 特有的小坑

太刺激了。 MSSQL 对底层库有严格要求，而 Debian 的默认仓库可能提供的是旧版。最常见的两大坑是：

当冤大头了。 C++ Runtime 不兼容：MSSQL 官方文档建议安装 aarch64-linux-gnu-libstdc++6=8.* 或更高版本。 SASL/GSSAPI 缺失：AAD 集成或 Kerberos 身份验证时会报 “Unable to locate GSSAPI library”。此时施行： # apt-get install libsasl2-modules-gssapi-mit krb5-user

\end{ol}

往白了说... 如果你使用的是 Debian Bookworm， 而官方仅提供 Bullseye 包，可尝试使用 , 再手动调低版本号进行兼容安装。

六、 性能调优小技巧 —— 把慢查询变快

调优方向	实战操作要点
PAGELATCH_WAIT_XXX 锁等待过高?	- 检查 tempdb 文件数是否足够 - 使用 ALTER DATABASE tempdb MODIFY FILE 增加大小 - 确认是否有大事务占用 Page Latch，可通过 sys.dm_os_wait_stats 查看细节。
CXPACKET 等待时间长?- 检查网络延迟及 MTU 设置 - 在 sqlservr.conf 中适当调大 packet size，但不要超过客户端上限 - 确认没有防火墙做深度包检测导致额外延迟。
LCK_M_X 行锁冲突频繁?	- 分析热点表索引，考虑加入覆盖索引或分区 - 使用 READ COMMITTED SNAPSHOT 减少锁竞争 - 定期施行 DBCC CHECKDB 检查碎片化程度并重建索引。
TempDB I/O 高?	- 将 TempDB 放到独立 SSD - 增加文件数量至至少等于逻辑CPU数 - 开启混合缓冲池。
统计信息过期导致优化器选错计划?	- 启用 AUTO_UPDATE_STATISTICS - 对关键表手动施行 UPDATE STATISTICS WITH FULLSCAN - 使用 sp_autostats 来监控统计信息更新时间间隔。

很多 DBA 常说：“慢查询不是怪 SQL，而是环境不给力。”以上几个维度往往能在几分钟内把原本需要十几秒才能返回的数据压缩到毫秒级别。记得每次调优后 用 bcp out … –q –c –t , –r –b10000 ` 或者 `sqlcmd` 施行相同查询做对比，以免误判回滚带来的副作用。

七、 重启与更新——平安升级不踩坑

来日方长。 MSSQL 在 Linux 上支持热更新，但某些补丁仍需要重启服务才能生效。下面是一套平安升级流程：

我满足了。 # apt update && apt upgrade -y mssql-server: 确保获取最新平安补丁；若提示需要重新配置， 请运行 /opt/mssql/bin/mssql-conf setup. # systemctl restart mssql-server: 重启前最好先把业务切换到只读模式或暂停写入，以免事务丢失。 # sudo journalctl -u mssql-server --since "5 minutes ago":  确认启动日志中没有 WARN 或 ERROR 项目；若出现 “Failed to start …”，马上回滚到上一个快照或备份恢复点。 用  校验版本号已经更新至预期值。 \end{ol}

温馨提醒：在生产环境中做任何升级前，请务必提前做好完整备份！特别是 master 与 msdb 数据库， 结果你猜怎么着？ 一旦损坏恢复成本极高。

八、 —— 把排错变成日常仪式感

看完这篇长文，你已经拥有了从“服务挂掉”到“性能飙升”的完整武器库。真正的大师不是记住每一个命令， 而是在遇到异常时保持冷静，用系统日志和监控数据拼凑出完整的因果链，然后一步步剥开谜团。下次当同事惊呼 “SQL Server 又崩了”， 你可以淡定地回一句：“先看一下 service 状态吧”，接着轻松完成定位与修复，让团队对你的技术信任度瞬间提升三倍，啊这...！

---

©2026 技术分享社区 | 本文基于个人实战经验撰写，仅供参考。如需商业支持，请联系官方渠道。

​

​​

​​​

‍‍‍‍‍‍‍‍‍ ‍ ‍ ‍ ‍ ‍

---