作为长期和 SQL Server 打交道的人我可以负责任地说18456这个错误码几乎算得上是数据库运维生涯里最“亲切”的一张熟脸了。无论是刚装好的开发库还是跑了好几年的生产环境只要哪天你突然连不上了SSMS 弹窗里十有八九躺着这句用户 sa 登录失败。更让人头疼的是这提示太简略就一个错误码加一个用户名具体是哪一环出了问题根本不告诉你。这篇文章就是要把这条让人抓狂的报错彻底拆开。我会完整梳理从“检查服务是否启动”到“查看错误日志状态码”再到“修改服务器身份验证模式”的整套排查链路重点针对sa账号登录被拒的场景把背后的原理、每一步操作的逻辑以及我在实战里踩过的坑都讲透。这套方法不仅适合刚入门的 DBA 新手对要经常处理开发环境连接问题的后端同事同样适用。1. 初识 18456先搞懂 SQL Server 到底在拒绝什么1.1 一条报错背后的三级判断机制从 SQL Server 的角度来看一次登录尝试要经过三道关卡连接请求是否到达数据库引擎网络层是否通畅。提供的凭据是否能通过身份验证是 Windows 身份还是 SQL 身份。通过验证后该登录名有没有权限连入实例登录名是否被启用、是否被拒绝访问。客户端收到18456时往往第一反应是“用户名或密码错了吧”但真实情况远不止这一种可能。实际上SQL Server 会把更精确的失败原因写在自身的错误日志里。这也是整个排查过程中最重要的一条原则不要只看客户端弹窗一定要去翻 SQL Server 错误日志找那条带有状态码State的 18456 记录。在错误日志中18456会附带一个 State 值常见的包括State含义1用户信息无效或未提供必要的身份验证信息2用户 ID 无效登录名不存在5使用 SQL 身份验证但该登录名被禁用6尝试使用 Windows 登录名如域名\用户但使用了 SQL 身份验证模式7登录名已禁用或密码不正确8密码不正确9参数无效11连接有效但登录失败通常是服务器配置层面的问题12凭据有效但登录名被锁定了SQL Server 2008 新增18更改密码时出现问题38因密码过期无法登录若勾选“用户必须在下次登录时更改密码”也会触发理解了这个机制你就能明白为什么我说“光看弹窗没用”了。比如 State 5 告诉你的是账号被禁用State 8 是密码错误State 12 是账号被锁。每一种的处理思路完全不一样甚至截然相反——如果账号被锁你还一个劲改密码可能白忙活半天。1.2 为什么用 SSMS 连不上的时候错误日志反而读不了这里有个很经典的鸡生蛋问题SSMS 连不上实例而精确的错误原因又写在 SQL Server 错误日志里可错误日志默认只能通过 SSMS 的“对象资源管理器”去看连都连不上怎么看实操中有两条出路如果你只是拿sa连不上但 Windows 身份验证还能用前提是服务器上允许本机 Windows 账号登录那就先用 Windows 身份连进 SSMS再去“管理”-“SQL Server 日志”里找。如果整个实例都连不上了那就只能去文件系统层面翻日志。默认安装路径是C:\Program Files\Microsoft SQL Server\MSSQL{版本号}.{实例名}\MSSQL\Log\ERRORLOG。这个文件没有扩展名直接用记事本打开即可最新一次启动的日志就是当前的 ERRORLOG历史日志则带有编号后缀如 ERRORLOG.1、ERRORLOG.2。在我维护过的服务器里至少有一半的“误报密码错误”案例最终都在 ERRORLOG 里找到了真正的 State从而快速定位。建议刚接触 SQL Server 的朋友养成习惯遇到连接失败第一反应是去看 ERRORLOG而不是一遍遍重试登录。2. sa 登录失败的常见原因拆解从配置到策略2.1 身份验证模式这是 sa 能登录的“入场券”SQL Server 安装时默认的是“Windows 身份验证模式”这本身没有错安全性更高。但问题是很多业务系统尤其是老旧的 ERP、OA、财务软件的连接串里写死了User IDsa;Passwordxxx。当服务器是 Windows 身份验证模式时sa无论如何都登不上哪怕密码完全正确。这时需要把实例改成“SQL Server 和 Windows 身份验证模式”。操作路径用 Windows 身份登录 SSMS。右键实例名 - “属性” - “安全性”。在“服务器身份验证”里选“SQL Server 和 Windows 身份验证模式”。确定后会提示重启服务点“确定”后在“服务”里重启 SQL Server 服务或使用services.msc。这里我强烈建议在改模式之前先确认一下应用侧是否真的必须用sa。如果可以创建一个具备最小权限的独立登录名比如只给db_datareader、db_datawriter角色远比开放sa要安全。如果业务系统已经上线且改连接串成本太高那才考虑启用sa并设置强密码。2.2 sa 账号被禁用SQL Server 2005 以来的默认策略从 SQL Server 2005 开始安装完成后sa账号默认就是禁用的。很多人安装时一路下一步压根没注意“指定 SQL 管理员”这个页面装完了拿sa一登直接18456。这种情况在 ERRORLOG 里通常是 State 5。启用方法-- 先以 Windows 身份登录然后在新建查询里执行 ALTER LOGIN [sa] WITH PASSWORD N强密码; ALTER LOGIN [sa] ENABLE;注意顺序很重要先改密码再启用或者同时执行也可以ALTER LOGIN [sa] WITH PASSWORD N强密码, CHECK_POLICY ON, CHECK_EXPIRATION OFF; ALTER LOGIN [sa] ENABLE;CHECK_EXPIRATION OFF是我个人的建议因为企业里如果开启了系统密码策略sa的密码会按 Windows 策略定期过期。对于无人值守的服务账户来说密码过期会导致业务在半夜突然断开连接那种事故很难跟业务方解释清楚。2.3 密码错误与密码过期比想象的更容易混淆SQL Server 的密码错误提示是 State 8。但这并不仅仅意味着“你输错了”还可能是因为密码中含有特殊字符在连接串或者某个配置文件里被转义错误。复制粘贴时带上了前后空格这类问题极其隐蔽。应用程序配置文件中密码段被加密过解密后得到的是旧密码。此外如果该登录名开启了强制密码过期策略登录时就会报类似“密码已过期”的 18487 或 18488有些人误以为是 18456 的一种。若登录名勾选了“用户必须在下次登录时更改密码”首次用该账号连接时也会被拒SSMS 会提示“必须更改密码”但部分老客户端根本不给改密码的机会。解决方式是管理员强制清除过期状态ALTER LOGIN [sa] WITH PASSWORD N新密码 UNLOCK;UNLOCK关键字顺便把锁定状态一并清掉一举两得。2.4 登录名被锁定密码策略中的“触发器”如果你在实例级别开启了密码策略强制执行并且多次输入错误密码sa会被自动锁定。报错 State 是 12提示信息为“由于重复的登录尝试该登录名已被锁定”。这个机制本身是安全的但在生产环境里要特别注意某些老旧系统用定时任务频繁重连数据库若密码管理不当或连接串配置错误可能在几分钟内就把sa锁死。处理办法是ALTER LOGIN [sa] WITH PASSWORD N新密码 UNLOCK;如果不做 UNLOCK单纯改密码不会解锁。这一点是我在实际排查中见过的最大误区——有人把密码改对了依然登不上因为账号还锁着。2.5 服务器是否允许远程连接容易被忽略的一环sa登录失败还有一种场景在服务器本机用 SSMS 能连但在其他机器上就是 18456。这种多半不是登录名的问题而是实例没开 TCP/IP 协议或防火墙拦截了 1433 端口。检查方法打开“SQL Server 配置管理器”。展开“SQL Server 网络配置” - 对应实例 - “协议”。确认 TCP/IP 已启用。默认实例监听 1433 端口命名实例会监听动态端口。检查 Windows 防火墙是否有入站规则放行对应端口。判断到底是网络问题还是账号问题的一个快速方法在远程机器上用telnet 服务器IP 1433测试端口连通性或者用tnsping、Test-NetConnectionPowerShell验证。如果端口不通sa密码再正确也没用因为客户端请求根本到不了 SQL Server。3. 完整排查实操手把手走一遍 18456 的解决流程3.1 阶段一确认服务和端口状态任何连接问题的第一步永远不是改密码而是确认数据库服务真的活着。打开“服务”WinR 输入services.msc找到类似SQL Server (MSSQLSERVER)的服务确认状态是“正在运行”。如果是“已停止”右键“启动”。接着确认端口监听。PowerShell 执行netstat -ano | findstr 1433正常情况会看到TCP 0.0.0.0:1433或TCP [::]:1433处于 LISTENING 状态。如果没有输出说明 SQL Server 没在监听 1433要么是 TCP/IP 协议没启用要么是端口被改过。可以再查一下 SQL Server 错误日志启动信息里会写明Server is listening on [ any ipv4 1433]。3.2 阶段二查看 ERRORLOG 定位 State 值以 Windows 身份或通过文件路径打开 ERRORLOG 后CtrlF搜索18456。典型的记录长这样Logon Error: 18456, Severity: 14, State: 8. Logon Login failed for user sa. Reason: Password did not match that for the login provided. [CLIENT: 10.1.1.88]State 8 很清楚密码错误。但注意这只是 SQL Server 层面的结论具体为什么密码会“错误”还得回到客户端或业务系统去找原因。如果看到的是 State 5Logon Login failed for user sa. Reason: SQL Server is running in Windows authentication mode only.那就不是密码问题而是身份验证模式问题。此时即使你密码输得再对也登不上。还有一个容易忽略的点ERRORLOG 是按启动周期轮转的。如果服务今天刚重启过可能当前日志里并没有昨天 18456 的历史记录。这时需要打开带有编号的历史日志如 ERRORLOG.1继续搜索。3.3 阶段三根据 State 分路处理根据我上面列出的常见 State操作方法如下State 5身份验证模式限制操作路径SSMS - 实例属性 - 安全性 - 选“SQL Server 和 Windows 身份验证模式” - 重启服务。补充检查如果应用仍连不上确认连接串里是否漏了AuthenticationSqlPassword之类的参数不同驱动写法不同。State 8密码错误先用管理员账号Windows 身份登录执行ALTER LOGIN [sa] WITH PASSWORD N新密码 UNLOCK;然后立即用新密码测试登录。如果还在报 18456很可能是密码里有特殊字符但在某个配置文件里被转义建议临时把密码改成纯字母数字再次测试逐步缩小范围。State 5 与 State 8 同时存在的迷惑现象实际工作中可能遇到一种更绕的情况ERRORLOG 里连续出现多条 18456State 既有 5 又有 8。原因往往是界面上的“SQL Server 和 Windows 身份验证模式”确实改了但服务没重启或者 SQL Server 代理服务SQLAgent还在用旧的内存配置。切记改了身份验证模式后必须重启数据库引擎服务才能完全生效。State 12被锁定使用ALTER LOGIN [sa] WITH PASSWORD N新密码 UNLOCK解锁。如果服务器配置了密码策略检查域策略中“账户锁定阈值”和“复位账户锁定计数器”的时间避免反复触发锁定。3.4 阶段四所有方法都不奏效时的终极大法如果以上方法全试过还是登不上SSMS 窗口纹丝不动地报 18456还有一招用单用户模式启动 SQL Server 实例。步骤停掉 SQL Server 服务。打开命令行管理员权限进入 SQL Server 的Binn目录例如C:\Program Files\Microsoft SQL Server\MSSQL15.MSSQLSERVER\MSSQL\Binn执行sqlservr.exe -m以“管理员身份”打开 SSMS此时可以尝试用 Windows 身份连接单用户模式下只允许一个连接然后调整所有需要的登录名配置。处理完毕后关闭命令行窗口或按CtrlC停止再正常启动 SQL Server 服务。这个方法是最后的手段需要谨慎操作不要在生产环境轻易尝试。因为单用户模式会暂时拒绝所有业务连接。但如果遇到的是sa和 Windows 管理员都被锁死这类极端情况这是唯一能进系统的门。4. 从 18456 延伸两个经常一起出现的高频报错排查sa登录失败的过程中你大概率还会遇到下面两个“同宗同源”的问题。它们不属于 18456但经常被混在一起讨论顺手梳理一下免得大家查资料时被误导。4.1 证书链是由不受信任的颁发机构颁发的-2146893019在使用 ODBC Driver 17/18 连接 SQL Server 时可能会看到类似[08001] [Microsoft][ODBC Driver 17 for SQL Server]SSL 提供程序: 证书链是由不受信任的颁发机构颁发的。 (-2146893019)这个报错发生在 TLS 握手阶段也就是说身份验证还没轮到sa那一步。原因是 SQL Server 默认强制加密连接时客户端不信任服务器自签的证书。常见场景服务器没有安装受信任的 CA 证书而客户端又开启了“Encryptyes”或“TrustServerCertificateno”。SQL Server 实例勾选了“强制加密”。快速验证是身份验证问题还是证书问题的方法把连接串里加上TrustServerCertificateTrue或EncryptFalse但 less 安全。如果入口是 ODBC类似Driver{ODBC Driver 18 for SQL Server};ServermyServer;DatabasemyDb;Uidsa;Pwdxxx;TrustServerCertificateyes;如果能连上说明身份验证本身没问题纯粹的证书信任问题。生产环境建议正规处理——把服务器的 TLS 证书换成企业 CA 签发的证书并正确配置 DNS 名称不要贪图方便一直用TrustServerCertificateyes。4.2 无法连接到 SQL Server与 SolidWorks Electrical 的恩怨很多工程师在装 SolidWorks Electrical 时会碰到“SolidWorks Electrical 无法连接到 SQL Server。此故障的可能原因- 用户名或密码”之类的提示。SolidWorks Electrical 依赖本机或远程的 SQL Server 实例来存储电气原理图数据。这个场景里安装程序通常会要求你提供一个 SQL Server 实例和登录凭据默认往往写死为sa或 Windows 身份验证。如果你安装时用的不是默认实例或者实例是 SQL Server Express连接字符串里的实例名写错也会表现为登录失败。比如把localhost\SQLEXPRESS写成了localhost。这种问题的排查思路和上面大同小异但有一个额外注意点SolidWorks Electrical 要求数据库账号必须有db_owner或sysadmin权限否则后续脚本无法创建数据库。因此如果sa登录成功但程序依然报错需要检查该登录名是否被映射到了对应数据库的角色。5. 排查思路汇总与快速决策表说了这么多为了让你在紧急时刻能更快定位我把整个排查链归纳成一张速查表。这张表的核心逻辑是先看服务再看端口然后看 ERRORLOG 的 State最后看账号状态。症状可能原因快速验证方法处理动作服务器本机也登录失败身份验证模式不对 / sa 被禁用 / 密码错误查看 ERRORLOG 中 18456 的 State对应执行 ALTER LOGIN 或改模式本机能连远程连不上TCP/IP 未启用 / 防火墙拦截netstat 查 1433 端口远程 telnet配置管理器启用 TCP/IP加防火墙规则错误日志显示 State 5SQL Server 处于仅 Windows 身份验证模式查看实例属性-安全性改为混合模式并重启服务错误日志显示 State 8密码不匹配用 Windows 身份重置密码再试ALTER LOGIN WITH PASSWORD错误日志显示 State 12多次失败导致锁定查询 sys.sql_logins 的 is_locked 字段ALTER LOGIN ... UNLOCK错误日志显示 State 7登录名被禁用或密码错误检查 is_disabled 字段ALTER LOGIN ENABLE 并重置密码错误日志显示 State 38密码过期检查 must_change 字段重置密码或修改 CHECK_POLICY/EXPIRATION日志没有任何 18456请求根本没到 SQL Server检查网络、端口、防火墙按网络问题处理另外提醒一句sa是 SQL Server 里的高权限账号如果业务并不强依赖它建议始终处于禁用状态。日常运维用 Windows 身份验证或专用账号即可。若必须使用sa务必设置强密码、开启审计并且限制可访问sa的 IP 来源。6. 实战中的那些坑写在最后的叮嘱我在处理过的案例里总结几条共性的“坑”这些不会写在官方文档里但每一条都是真金白银换来的经验坑一改了密码却忘了同步到应用连接串。很多老系统的连接配置不是明文而是加密存放在注册表或配置文件里。你用 SSMS 把sa密码改了sa本身没问题了但业务系统立刻大面积报 18456。正确做法是先排查所有依赖sa的连接串来源安排维护窗口统一变更。坑二共享实例上的“公说公有理”。开发环境往往是几个人共用一台 SQL Server你改了密码别人不知道立刻开始互相指责。我的习惯是在开发环境的登录名策略里加一条约定开发库如果要改密码必须在群公告里同步更新连接串模板。这不是技术问题是协作问题。坑三安全软件或组策略拦住了 SQL Server 服务。有一次排查了很久SQL Server 服务总是启动后几秒内自动停止错误日志也没有 18456后来发现是杀毒软件把sqlservr.exe的端口监听拦截了。如果你的环境装了 EDN 或主机安全软件记得把 SQL Server 的安装目录和监听端口加白名单。坑四别忘了查看 SQL Server Agent 的运行状态。如果实例依赖 SQL Agent 作业Agent 服务密码过期一样会导致作业失败报错可能不是 18456 但本质还是登录凭据问题。所以养成定期轮换服务账号密码并同步更新 SQL Agent 登录凭据的习惯。坑五本地连接用localhost和.可能走向不同逻辑。在客户端连接时localhost解析为 IPv6::1个别老旧客户端在 IPv6 环境下会异常表现为间歇性 18456换成 IP 地址或主机名反而稳定。可以在hosts里固定解析或让应用连接串直接写内网 IP。最后再分享一个我个人的小习惯排查 SQL Server 登录问题时不要只盯着一个错误日志文件。把ERRORLOG从头到尾翻一遍重点观察 18456 报错出现的频率和来源 IP。如果发现某个不认识的 IP 在反复尝试登录sa说明你的实例正被暴力破解扫描。这种情况要立刻启用账户锁定策略并且在防火墙层限制 1433 端口的访问来源。毕竟在如今这个网络环境下开放到公网的 SQL Server 实例一天被扫描几千次都是常事。运维的活不怕出问题就怕找不到问题从哪来。掌握这套 18456 的排查方法再配合良好的账号和密码管理习惯你会少接很多凌晨两点的故障电话。
SQL Server 18456错误排查：sa登录失败原因与解决方案
作为长期和 SQL Server 打交道的人我可以负责任地说18456这个错误码几乎算得上是数据库运维生涯里最“亲切”的一张熟脸了。无论是刚装好的开发库还是跑了好几年的生产环境只要哪天你突然连不上了SSMS 弹窗里十有八九躺着这句用户 sa 登录失败。更让人头疼的是这提示太简略就一个错误码加一个用户名具体是哪一环出了问题根本不告诉你。这篇文章就是要把这条让人抓狂的报错彻底拆开。我会完整梳理从“检查服务是否启动”到“查看错误日志状态码”再到“修改服务器身份验证模式”的整套排查链路重点针对sa账号登录被拒的场景把背后的原理、每一步操作的逻辑以及我在实战里踩过的坑都讲透。这套方法不仅适合刚入门的 DBA 新手对要经常处理开发环境连接问题的后端同事同样适用。1. 初识 18456先搞懂 SQL Server 到底在拒绝什么1.1 一条报错背后的三级判断机制从 SQL Server 的角度来看一次登录尝试要经过三道关卡连接请求是否到达数据库引擎网络层是否通畅。提供的凭据是否能通过身份验证是 Windows 身份还是 SQL 身份。通过验证后该登录名有没有权限连入实例登录名是否被启用、是否被拒绝访问。客户端收到18456时往往第一反应是“用户名或密码错了吧”但真实情况远不止这一种可能。实际上SQL Server 会把更精确的失败原因写在自身的错误日志里。这也是整个排查过程中最重要的一条原则不要只看客户端弹窗一定要去翻 SQL Server 错误日志找那条带有状态码State的 18456 记录。在错误日志中18456会附带一个 State 值常见的包括State含义1用户信息无效或未提供必要的身份验证信息2用户 ID 无效登录名不存在5使用 SQL 身份验证但该登录名被禁用6尝试使用 Windows 登录名如域名\用户但使用了 SQL 身份验证模式7登录名已禁用或密码不正确8密码不正确9参数无效11连接有效但登录失败通常是服务器配置层面的问题12凭据有效但登录名被锁定了SQL Server 2008 新增18更改密码时出现问题38因密码过期无法登录若勾选“用户必须在下次登录时更改密码”也会触发理解了这个机制你就能明白为什么我说“光看弹窗没用”了。比如 State 5 告诉你的是账号被禁用State 8 是密码错误State 12 是账号被锁。每一种的处理思路完全不一样甚至截然相反——如果账号被锁你还一个劲改密码可能白忙活半天。1.2 为什么用 SSMS 连不上的时候错误日志反而读不了这里有个很经典的鸡生蛋问题SSMS 连不上实例而精确的错误原因又写在 SQL Server 错误日志里可错误日志默认只能通过 SSMS 的“对象资源管理器”去看连都连不上怎么看实操中有两条出路如果你只是拿sa连不上但 Windows 身份验证还能用前提是服务器上允许本机 Windows 账号登录那就先用 Windows 身份连进 SSMS再去“管理”-“SQL Server 日志”里找。如果整个实例都连不上了那就只能去文件系统层面翻日志。默认安装路径是C:\Program Files\Microsoft SQL Server\MSSQL{版本号}.{实例名}\MSSQL\Log\ERRORLOG。这个文件没有扩展名直接用记事本打开即可最新一次启动的日志就是当前的 ERRORLOG历史日志则带有编号后缀如 ERRORLOG.1、ERRORLOG.2。在我维护过的服务器里至少有一半的“误报密码错误”案例最终都在 ERRORLOG 里找到了真正的 State从而快速定位。建议刚接触 SQL Server 的朋友养成习惯遇到连接失败第一反应是去看 ERRORLOG而不是一遍遍重试登录。2. sa 登录失败的常见原因拆解从配置到策略2.1 身份验证模式这是 sa 能登录的“入场券”SQL Server 安装时默认的是“Windows 身份验证模式”这本身没有错安全性更高。但问题是很多业务系统尤其是老旧的 ERP、OA、财务软件的连接串里写死了User IDsa;Passwordxxx。当服务器是 Windows 身份验证模式时sa无论如何都登不上哪怕密码完全正确。这时需要把实例改成“SQL Server 和 Windows 身份验证模式”。操作路径用 Windows 身份登录 SSMS。右键实例名 - “属性” - “安全性”。在“服务器身份验证”里选“SQL Server 和 Windows 身份验证模式”。确定后会提示重启服务点“确定”后在“服务”里重启 SQL Server 服务或使用services.msc。这里我强烈建议在改模式之前先确认一下应用侧是否真的必须用sa。如果可以创建一个具备最小权限的独立登录名比如只给db_datareader、db_datawriter角色远比开放sa要安全。如果业务系统已经上线且改连接串成本太高那才考虑启用sa并设置强密码。2.2 sa 账号被禁用SQL Server 2005 以来的默认策略从 SQL Server 2005 开始安装完成后sa账号默认就是禁用的。很多人安装时一路下一步压根没注意“指定 SQL 管理员”这个页面装完了拿sa一登直接18456。这种情况在 ERRORLOG 里通常是 State 5。启用方法-- 先以 Windows 身份登录然后在新建查询里执行 ALTER LOGIN [sa] WITH PASSWORD N强密码; ALTER LOGIN [sa] ENABLE;注意顺序很重要先改密码再启用或者同时执行也可以ALTER LOGIN [sa] WITH PASSWORD N强密码, CHECK_POLICY ON, CHECK_EXPIRATION OFF; ALTER LOGIN [sa] ENABLE;CHECK_EXPIRATION OFF是我个人的建议因为企业里如果开启了系统密码策略sa的密码会按 Windows 策略定期过期。对于无人值守的服务账户来说密码过期会导致业务在半夜突然断开连接那种事故很难跟业务方解释清楚。2.3 密码错误与密码过期比想象的更容易混淆SQL Server 的密码错误提示是 State 8。但这并不仅仅意味着“你输错了”还可能是因为密码中含有特殊字符在连接串或者某个配置文件里被转义错误。复制粘贴时带上了前后空格这类问题极其隐蔽。应用程序配置文件中密码段被加密过解密后得到的是旧密码。此外如果该登录名开启了强制密码过期策略登录时就会报类似“密码已过期”的 18487 或 18488有些人误以为是 18456 的一种。若登录名勾选了“用户必须在下次登录时更改密码”首次用该账号连接时也会被拒SSMS 会提示“必须更改密码”但部分老客户端根本不给改密码的机会。解决方式是管理员强制清除过期状态ALTER LOGIN [sa] WITH PASSWORD N新密码 UNLOCK;UNLOCK关键字顺便把锁定状态一并清掉一举两得。2.4 登录名被锁定密码策略中的“触发器”如果你在实例级别开启了密码策略强制执行并且多次输入错误密码sa会被自动锁定。报错 State 是 12提示信息为“由于重复的登录尝试该登录名已被锁定”。这个机制本身是安全的但在生产环境里要特别注意某些老旧系统用定时任务频繁重连数据库若密码管理不当或连接串配置错误可能在几分钟内就把sa锁死。处理办法是ALTER LOGIN [sa] WITH PASSWORD N新密码 UNLOCK;如果不做 UNLOCK单纯改密码不会解锁。这一点是我在实际排查中见过的最大误区——有人把密码改对了依然登不上因为账号还锁着。2.5 服务器是否允许远程连接容易被忽略的一环sa登录失败还有一种场景在服务器本机用 SSMS 能连但在其他机器上就是 18456。这种多半不是登录名的问题而是实例没开 TCP/IP 协议或防火墙拦截了 1433 端口。检查方法打开“SQL Server 配置管理器”。展开“SQL Server 网络配置” - 对应实例 - “协议”。确认 TCP/IP 已启用。默认实例监听 1433 端口命名实例会监听动态端口。检查 Windows 防火墙是否有入站规则放行对应端口。判断到底是网络问题还是账号问题的一个快速方法在远程机器上用telnet 服务器IP 1433测试端口连通性或者用tnsping、Test-NetConnectionPowerShell验证。如果端口不通sa密码再正确也没用因为客户端请求根本到不了 SQL Server。3. 完整排查实操手把手走一遍 18456 的解决流程3.1 阶段一确认服务和端口状态任何连接问题的第一步永远不是改密码而是确认数据库服务真的活着。打开“服务”WinR 输入services.msc找到类似SQL Server (MSSQLSERVER)的服务确认状态是“正在运行”。如果是“已停止”右键“启动”。接着确认端口监听。PowerShell 执行netstat -ano | findstr 1433正常情况会看到TCP 0.0.0.0:1433或TCP [::]:1433处于 LISTENING 状态。如果没有输出说明 SQL Server 没在监听 1433要么是 TCP/IP 协议没启用要么是端口被改过。可以再查一下 SQL Server 错误日志启动信息里会写明Server is listening on [ any ipv4 1433]。3.2 阶段二查看 ERRORLOG 定位 State 值以 Windows 身份或通过文件路径打开 ERRORLOG 后CtrlF搜索18456。典型的记录长这样Logon Error: 18456, Severity: 14, State: 8. Logon Login failed for user sa. Reason: Password did not match that for the login provided. [CLIENT: 10.1.1.88]State 8 很清楚密码错误。但注意这只是 SQL Server 层面的结论具体为什么密码会“错误”还得回到客户端或业务系统去找原因。如果看到的是 State 5Logon Login failed for user sa. Reason: SQL Server is running in Windows authentication mode only.那就不是密码问题而是身份验证模式问题。此时即使你密码输得再对也登不上。还有一个容易忽略的点ERRORLOG 是按启动周期轮转的。如果服务今天刚重启过可能当前日志里并没有昨天 18456 的历史记录。这时需要打开带有编号的历史日志如 ERRORLOG.1继续搜索。3.3 阶段三根据 State 分路处理根据我上面列出的常见 State操作方法如下State 5身份验证模式限制操作路径SSMS - 实例属性 - 安全性 - 选“SQL Server 和 Windows 身份验证模式” - 重启服务。补充检查如果应用仍连不上确认连接串里是否漏了AuthenticationSqlPassword之类的参数不同驱动写法不同。State 8密码错误先用管理员账号Windows 身份登录执行ALTER LOGIN [sa] WITH PASSWORD N新密码 UNLOCK;然后立即用新密码测试登录。如果还在报 18456很可能是密码里有特殊字符但在某个配置文件里被转义建议临时把密码改成纯字母数字再次测试逐步缩小范围。State 5 与 State 8 同时存在的迷惑现象实际工作中可能遇到一种更绕的情况ERRORLOG 里连续出现多条 18456State 既有 5 又有 8。原因往往是界面上的“SQL Server 和 Windows 身份验证模式”确实改了但服务没重启或者 SQL Server 代理服务SQLAgent还在用旧的内存配置。切记改了身份验证模式后必须重启数据库引擎服务才能完全生效。State 12被锁定使用ALTER LOGIN [sa] WITH PASSWORD N新密码 UNLOCK解锁。如果服务器配置了密码策略检查域策略中“账户锁定阈值”和“复位账户锁定计数器”的时间避免反复触发锁定。3.4 阶段四所有方法都不奏效时的终极大法如果以上方法全试过还是登不上SSMS 窗口纹丝不动地报 18456还有一招用单用户模式启动 SQL Server 实例。步骤停掉 SQL Server 服务。打开命令行管理员权限进入 SQL Server 的Binn目录例如C:\Program Files\Microsoft SQL Server\MSSQL15.MSSQLSERVER\MSSQL\Binn执行sqlservr.exe -m以“管理员身份”打开 SSMS此时可以尝试用 Windows 身份连接单用户模式下只允许一个连接然后调整所有需要的登录名配置。处理完毕后关闭命令行窗口或按CtrlC停止再正常启动 SQL Server 服务。这个方法是最后的手段需要谨慎操作不要在生产环境轻易尝试。因为单用户模式会暂时拒绝所有业务连接。但如果遇到的是sa和 Windows 管理员都被锁死这类极端情况这是唯一能进系统的门。4. 从 18456 延伸两个经常一起出现的高频报错排查sa登录失败的过程中你大概率还会遇到下面两个“同宗同源”的问题。它们不属于 18456但经常被混在一起讨论顺手梳理一下免得大家查资料时被误导。4.1 证书链是由不受信任的颁发机构颁发的-2146893019在使用 ODBC Driver 17/18 连接 SQL Server 时可能会看到类似[08001] [Microsoft][ODBC Driver 17 for SQL Server]SSL 提供程序: 证书链是由不受信任的颁发机构颁发的。 (-2146893019)这个报错发生在 TLS 握手阶段也就是说身份验证还没轮到sa那一步。原因是 SQL Server 默认强制加密连接时客户端不信任服务器自签的证书。常见场景服务器没有安装受信任的 CA 证书而客户端又开启了“Encryptyes”或“TrustServerCertificateno”。SQL Server 实例勾选了“强制加密”。快速验证是身份验证问题还是证书问题的方法把连接串里加上TrustServerCertificateTrue或EncryptFalse但 less 安全。如果入口是 ODBC类似Driver{ODBC Driver 18 for SQL Server};ServermyServer;DatabasemyDb;Uidsa;Pwdxxx;TrustServerCertificateyes;如果能连上说明身份验证本身没问题纯粹的证书信任问题。生产环境建议正规处理——把服务器的 TLS 证书换成企业 CA 签发的证书并正确配置 DNS 名称不要贪图方便一直用TrustServerCertificateyes。4.2 无法连接到 SQL Server与 SolidWorks Electrical 的恩怨很多工程师在装 SolidWorks Electrical 时会碰到“SolidWorks Electrical 无法连接到 SQL Server。此故障的可能原因- 用户名或密码”之类的提示。SolidWorks Electrical 依赖本机或远程的 SQL Server 实例来存储电气原理图数据。这个场景里安装程序通常会要求你提供一个 SQL Server 实例和登录凭据默认往往写死为sa或 Windows 身份验证。如果你安装时用的不是默认实例或者实例是 SQL Server Express连接字符串里的实例名写错也会表现为登录失败。比如把localhost\SQLEXPRESS写成了localhost。这种问题的排查思路和上面大同小异但有一个额外注意点SolidWorks Electrical 要求数据库账号必须有db_owner或sysadmin权限否则后续脚本无法创建数据库。因此如果sa登录成功但程序依然报错需要检查该登录名是否被映射到了对应数据库的角色。5. 排查思路汇总与快速决策表说了这么多为了让你在紧急时刻能更快定位我把整个排查链归纳成一张速查表。这张表的核心逻辑是先看服务再看端口然后看 ERRORLOG 的 State最后看账号状态。症状可能原因快速验证方法处理动作服务器本机也登录失败身份验证模式不对 / sa 被禁用 / 密码错误查看 ERRORLOG 中 18456 的 State对应执行 ALTER LOGIN 或改模式本机能连远程连不上TCP/IP 未启用 / 防火墙拦截netstat 查 1433 端口远程 telnet配置管理器启用 TCP/IP加防火墙规则错误日志显示 State 5SQL Server 处于仅 Windows 身份验证模式查看实例属性-安全性改为混合模式并重启服务错误日志显示 State 8密码不匹配用 Windows 身份重置密码再试ALTER LOGIN WITH PASSWORD错误日志显示 State 12多次失败导致锁定查询 sys.sql_logins 的 is_locked 字段ALTER LOGIN ... UNLOCK错误日志显示 State 7登录名被禁用或密码错误检查 is_disabled 字段ALTER LOGIN ENABLE 并重置密码错误日志显示 State 38密码过期检查 must_change 字段重置密码或修改 CHECK_POLICY/EXPIRATION日志没有任何 18456请求根本没到 SQL Server检查网络、端口、防火墙按网络问题处理另外提醒一句sa是 SQL Server 里的高权限账号如果业务并不强依赖它建议始终处于禁用状态。日常运维用 Windows 身份验证或专用账号即可。若必须使用sa务必设置强密码、开启审计并且限制可访问sa的 IP 来源。6. 实战中的那些坑写在最后的叮嘱我在处理过的案例里总结几条共性的“坑”这些不会写在官方文档里但每一条都是真金白银换来的经验坑一改了密码却忘了同步到应用连接串。很多老系统的连接配置不是明文而是加密存放在注册表或配置文件里。你用 SSMS 把sa密码改了sa本身没问题了但业务系统立刻大面积报 18456。正确做法是先排查所有依赖sa的连接串来源安排维护窗口统一变更。坑二共享实例上的“公说公有理”。开发环境往往是几个人共用一台 SQL Server你改了密码别人不知道立刻开始互相指责。我的习惯是在开发环境的登录名策略里加一条约定开发库如果要改密码必须在群公告里同步更新连接串模板。这不是技术问题是协作问题。坑三安全软件或组策略拦住了 SQL Server 服务。有一次排查了很久SQL Server 服务总是启动后几秒内自动停止错误日志也没有 18456后来发现是杀毒软件把sqlservr.exe的端口监听拦截了。如果你的环境装了 EDN 或主机安全软件记得把 SQL Server 的安装目录和监听端口加白名单。坑四别忘了查看 SQL Server Agent 的运行状态。如果实例依赖 SQL Agent 作业Agent 服务密码过期一样会导致作业失败报错可能不是 18456 但本质还是登录凭据问题。所以养成定期轮换服务账号密码并同步更新 SQL Agent 登录凭据的习惯。坑五本地连接用localhost和.可能走向不同逻辑。在客户端连接时localhost解析为 IPv6::1个别老旧客户端在 IPv6 环境下会异常表现为间歇性 18456换成 IP 地址或主机名反而稳定。可以在hosts里固定解析或让应用连接串直接写内网 IP。最后再分享一个我个人的小习惯排查 SQL Server 登录问题时不要只盯着一个错误日志文件。把ERRORLOG从头到尾翻一遍重点观察 18456 报错出现的频率和来源 IP。如果发现某个不认识的 IP 在反复尝试登录sa说明你的实例正被暴力破解扫描。这种情况要立刻启用账户锁定策略并且在防火墙层限制 1433 端口的访问来源。毕竟在如今这个网络环境下开放到公网的 SQL Server 实例一天被扫描几千次都是常事。运维的活不怕出问题就怕找不到问题从哪来。掌握这套 18456 的排查方法再配合良好的账号和密码管理习惯你会少接很多凌晨两点的故障电话。
