数据库运维的日常工作中，备份校验、性能排查、权限审计、故障定位往往需要在有限时间内完成。把高频操作沉淀为可复用的SQL脚本，既能减少临时拼写带来的风险，也便于团队内部统一操作口径。本文按备份与恢复、性能优化、权限管理、故障排查四类场景，汇总常用的SQL脚本思路与注意事项，供运维人员参考。

一、备份与恢复类脚本

1. 查看数据库与备份文件的基本信息

在执行备份前，先确认数据库大小、恢复模式和最近一次备份时间，可以避免重复备份或漏备。以SQL Server为例，可通过系统视图查询数据库状态与最近备份记录：

• 查询数据库列表及恢复模式：SELECT name, recovery_model_desc, state_desc FROM sys.databases;
• 查询各库最近一次完整备份时间：SELECT database_name, MAX(backup_finish_date) FROM msdb.dbo.backupset WHERE type = 'D' GROUP BY database_name;
• 查询备份文件所在路径与大小，用于容量规划。

MySQL环境下可查询information_schema.TABLES统计各库数据量与索引量，结合SHOW MASTER STATUS确认二进制日志位置，为逻辑备份与增量恢复提供依据。

2. 备份完整性校验

备份文件生成并不等于可用。建议在备份任务后附加校验步骤：

1. 使用RESTORE VERIFYONLY（SQL Server）或mysqlcheck（MySQL）验证备份集完整性；
2. 记录校验结果与耗时，纳入监控告警；
3. 定期在测试环境执行恢复演练，确认恢复流程可用。

需要提醒的是，校验会带来额外I/O开销，应避开业务高峰，并根据存储性能调整并发度。

3. 清理过期备份记录

备份历史表长期不清理会拖慢相关查询。可按保留策略删除过期记录，但删除前务必确认对应物理文件已按流程归档或销毁，避免记录与文件状态不一致。

二、性能优化类脚本

1. 定位当前活跃会话与阻塞

性能问题发生时，第一手信息通常来自当前会话视图。常用脚本包括：

• 查看当前运行中的会话、执行语句、等待类型与等待时长；
• 查询阻塞链，找出阻塞源头会话及其执行的语句；
• 查看锁等待与死锁相关视图，辅助判断锁粒度是否合理。

在MySQL中可通过SHOW PROCESSLIST、performance_schema与sys库视图获取类似信息。建议将查询结果与业务时间点关联，避免仅凭单次快照下结论。

2. 慢查询与高消耗语句统计

通过统计视图按总耗时、平均耗时、执行次数排序，可以快速筛选出优化优先级最高的语句：

1. 按总CPU时间或总逻辑读排序，找出资源消耗大户；
2. 结合执行计划查看是否存在全表扫描、隐式转换、缺少索引等问题；
3. 对比优化前后的统计差异，验证调整效果。

需要注意，统计信息会随时间窗口滚动，建议定期采集并留存历史数据，而不是只看当前值。

3. 索引使用情况与碎片检查

索引不是越多越好。可通过索引使用统计识别长期未使用的索引，评估其维护成本；同时检查索引碎片率，决定是否执行重建或重组。碎片处理属于较重操作，应在低峰期进行，并评估对复制延迟的影响。

4. 表与索引的容量分布

按表统计数据行数、数据空间、索引空间，有助于发现异常增长的表，提前规划归档或分区策略。对于日志类、流水类表，应重点关注增长速率而非绝对大小。

三、权限管理类脚本

1. 账号与登录信息盘点

定期导出账号清单是权限审计的基础动作，建议包含：

• 账号名称、创建时间、最近登录时间、是否启用；
• 所属角色与直接授予的权限；
• 是否存在空密码、默认密码或长期未登录账号。

2. 权限归属与最小化检查

通过查询角色成员与对象级授权记录，可以识别过度授权情况。常见检查点包括：

1. 是否存在普通业务账号拥有高权限角色；
2. 是否存在已离职或已下线系统的账号仍处于启用状态；
3. 是否存在直接授予表级写权限而绕过角色管理的情况。

权限调整应遵循先申请、后变更、再复核的流程，并保留变更记录，便于事后追溯。

3. 敏感操作的审计线索

结合数据库自身的审计功能或日志表，查询授权、建号、改密等敏感操作记录。若使用审计插件或第三方审计工具，需确认其采集范围覆盖关键实例，并注意日志本身的存储与轮转策略。

四、故障排查类脚本

1. 连接数与资源使用情况

连接数突增是常见的故障表象。可查询当前连接总数、按用户或按客户端IP的分布、连接状态占比，判断是应用侧连接池配置问题，还是慢查询导致的连接堆积。

2. 错误日志与告警信息定位

数据库错误日志、Agent作业日志、复制状态信息是排查的重要来源。建议脚本化提取最近时间窗口内的错误级别记录，并按错误码归类，快速锁定高频问题。对于主从或集群环境，还需检查复制延迟、节点角色切换记录。

3. 空间与文件状态检查

数据文件、日志文件的空间使用率，以及是否开启了自动增长、增长步长是否合理，都会影响故障恢复速度。可编写脚本定期输出各实例文件空间明细，对接近阈值的实例提前告警。

4. 会话与事务的异常终止

在确认需要终止异常会话或长事务时，应先记录会话ID、执行语句、开始时间与相关业务信息，再执行终止操作。终止操作本身可能触发回滚，耗时会超过预期，需评估对业务的影响。

五、脚本管理建议

脚本本身也需要管理，否则容易演变为新的风险点：

• 版本化：脚本纳入版本控制，变更留痕，避免多人各自维护不同版本。
• 参数化：实例名、库名、时间窗口等尽量参数化，减少硬编码带来的误操作。
• 只读优先：排查类脚本以只读查询为主，涉及写操作或终止会话的脚本单独归类并加确认步骤。
• 权限隔离：避免使用高权限账号执行日常查询，降低误操作影响范围。
• 环境区分：生产环境与测试环境的执行策略应明确区分，防止脚本误连生产库。

以上脚本覆盖了数据库运维的主要场景，但不同数据库产品在系统视图、命令语法上存在差异，实际使用时应结合所用数据库版本文档进行调整，并在测试环境验证后再应用于生产。脚本是效率工具，规范的流程与复核机制才是稳定运行的保障。