SQL Server 服务启动几秒后自动停止，如何从 ERRORLOG、服务账户、master 和 tempdb 定位原因？
SQL Server 启动后停止应先读取 ERRORLOG 和 Windows 事件，再检查服务账户、启动参数、系统数据库、磁盘与补丁。
先控制风险，再实施变更建议先在测试环境或单一对象上验证，保存配置、日志和可恢复备份。涉及生产切换、批量策略、数据库修复或存储重建时，应设置维护窗口和明确回退条件。
1. 结论与适用范围
服务控制器只会显示启动失败，真正原因通常记录在 SQL Server ERRORLOG。不要反复启动或重装覆盖证据，应先定位日志文件和最后一个错误，再判断是权限、路径、系统数据库、端口、资源还是补丁问题。
该问题涉及 SQL Server、ERP、数据库恢复或版本迁移。任何高风险操作前都应保留可验证备份。
2. 需要优先关注的风险信号
- 服务显示“启动后停止”，事件 17058、17113、17204 或 945 等。
- 近期修改服务账号、磁盘盘符、数据库路径、杀毒策略或补丁后发生。
3. 迁移或处理前的检查清单
- 从 SQL Server Configuration Manager 确认实例、服务账号和启动参数。
- 读取当前 ERRORLOG 与应用程序事件，找到第一个致命错误而非最后的停止提示。
- 检查 master、model、msdb、tempdb 路径、目录权限、磁盘空间和文件损坏。
- 检查端口占用、证书、TLS、服务账号密码和“作为服务登录”权限。
只读检查与验证示例
sc query MSSQLSERVER
Get-WinEvent -FilterHashtable @{LogName="Application"; ProviderName="MSSQLSERVER"} -MaxEvents 30
netstat -ano | findstr :1433corp.example、192.0.2.0/24 与 203.0.113.0/24 均为文档示例。只有在确认实际环境参数后，才能替换为真实值。
4. 推荐实施步骤
- 修复明确的路径或权限后再启动，每次只改变一个条件。
- tempdb 路径无效时恢复到可用目录；系统数据库损坏时按备份和重建方案处理。
- 服务账号变更必须通过 Configuration Manager，不直接在 services.msc 随意修改。
- 保留 ERRORLOG、事件和操作记录，必要时先复制数据库文件再进行高风险修复。
远程还是现场处理？日志、配置和少量对象通常可先远程评估；涉及物理服务器、存储、机房供电、批量切换或恢复演练时，应安排受控现场窗口。浙江、上海、江苏可根据项目情况上门，其他地区可远程协助。
5. 验证、回退与常见误区
- 服务稳定运行并通过多次重启。
- 所有数据库在线，SQL Agent、备份、应用连接和监听端口正常。
- 事件日志没有持续 I/O、权限、恢复或断言错误。
常见错误做法
- 删除 master 或日志文件。
- 看到磁盘有空间就排除所有存储问题。
- 未经分析反复重装 SQL Server。
常见问题
服务启动后停止是否一定是数据库损坏？
不是，账号、权限、路径、端口、证书和补丁都可能导致。
能否直接删除 tempdb 文件？
应先确认启动参数和路径，按受控方式处理，不能在未知状态下随意删除。