SQL数据库巡检须聚焦安全与性能两大维度：安全类查弱密码、过度授权、明文敏感信息及备份加密；性能类盯CPU/内存占用、慢查询、阻塞链和日志增长；需自动化脚本、监控告警与健康档案闭环管理。
SQL数据库定期巡检不是“有空看看”，而是通过标准化检查项，提前发现隐患、预防故障、保障业务连续性。核心围绕安全底线和性能水位两大维度展开，关键在“可量化、可追踪、可告警”。
一、安全类必查指标（防未然）
安全漏洞往往不爆发于高负载时，而藏在配置疏忽与权限失控中：
-
弱密码与默认账户：检查
sa、root等高危账户是否仍用默认口令或简单密码（如123456、password），建议用SQL脚本批量查询密码策略启用状态及过期时间； -
过度授权用户：筛选拥有
db_owner、sysadmin等高权限但近90天无登录/操作记录的账号，及时回收或降权； - 明文敏感信息：扫描建表语句、存储过程、注释中是否硬编码密码、密钥、身份证号等，可用正则匹配+脱敏规则识别；
- 备份加密与传输安全：确认全量备份是否启用TDE（透明数据加密）或备份压缩加密，远程备份链路是否强制SSL/TLS。
二、性能类高频指标（控水位）
性能问题多由缓慢积累导致，需盯住“资源瓶颈点”和“SQL质量洼地”：
-
CPU与内存持续占用 >85%：非峰值时段也超阈值？需结合
sys.dm_os_performance_counters查SQLServer:Resource Pool Stats定位争用池； - 慢查询TOP 10（执行时间 >3s 或逻辑读 >10万页）：用扩展事件（XEvent）或Query Store自动捕获，重点分析缺失索引、参数嗅探、大字段LOB操作；
-
阻塞链深度 ≥3 层或持续 >30秒：通过
sys.dm_exec_requests+blocking_session_id实时抓取，检查长事务、未提交更新、锁升级是否开启； - 日志文件自动增长频次 >5次/天：说明日志预分配不足，易引发VLF碎片，应按业务峰值预设合理初始大小并禁用小步增长（如每次1MB）。
三、巡检自动化建议（省人力）
手工查几十个视图效率低且易遗漏，推荐轻量落地方式：
- 用T-SQL写巡检脚本，输出HTML报告（含红/黄/绿状态标识），每日凌晨自动执行并邮件推送；
- 将关键指标（如阻塞数、缓存命中率、备份成功率）接入Zabbix/Prometheus，设置动态基线告警（非固定阈值）；
- 对SQL Server，启用Query Store并设置自动清理策略（如保留30天），它本身就是最可靠的性能“黑匣子”；
- 每次巡检后更新《数据库健康档案》，记录异常项、处理动作、责任人和闭环时间——这是追责与复盘的唯一依据。
四、容易被忽略但很关键的细节
很多事故源于“看起来正常”的配置：
- tempdb文件数量 ≠ CPU核心数：若为单文件或过多（如32核配32个文件），反而加剧PAGELATCH争用；
- 自动更新统计信息被禁用：尤其在ETL后未手动更新，会导致优化器选错执行计划；
- 数据库兼容级别长期停留在旧版本（如SQL Server 2012级），无法启用新优化器特性（如批次模式、自适应联接）；
- 错误日志循环数设为0（无限保留）：磁盘被占满前毫无预警，建议保留6–12个归档文件即可。
