数据库常用脚本实战指南：从故障排查到性能优化的高效工具库

作为在数据库方向摸爬滚打多年的老手，我越来越发现一个道理：真正拉开日常工作效率差距的，往往不是那些花哨的架构设计，而是手边有没有一套趁手、稳定、随时能用的“数据库常用脚本”。

这就像老厨师都有自己的秘制调料包，数据库管理员和后端开发也应该维护一套属于自己的“配方”。本篇文章我要分享的，就是我个人积累多年、在多个生产环境实测过的高频脚本库。它们不追求高深莫测，核心目标只有一个：当故障发生时，你能像条件反射一样掏出正确的脚本，而不是手忙脚乱地去翻历史命令。

这适用于想提升排障效率的数据库管理员、经常要跟数据库纠缠的后端开发，以及刚入门但不想走弯路的运维新人。我会按照“为什么要有”、“分类长啥样”、“具体怎么写”、“踩过哪些坑”这条线，把这些脚本连同背后的思路逻辑一并拆解清楚。

1. 为什么要自建一套数据库常用脚本库

很多人觉得，查询数据库嘛，临时写一条SQL不就行了？这种想法在规模小、压力低的环境下没什么问题，但你一旦进入生产环境，或者负责的系统开始有真实用户流量，临时拼凑SQL的弊端就会立刻暴露。

1.1 日常工作中反复敲的那几条SQL

我统计过自己某个月在命令行工具里的操作历史，发现一个很有意思的现象：大概有七成以上的查询，其实都是在重复执行二十来条固定的SQL。比如看当前有哪些耗时很长的会话、看看表空间还够不够、查一查某个索引到底有没有被用上。这些操作场景特别固定，完全没必要每次都现场敲一遍。

比如查当前正在执行的慢SQL，你每次都要写select * from information_schema.processlist where command != 'Sleep'这种长串。时间紧、心里慌的时候，少写一个字段或者漏掉一个过滤条件，查出来的结果就是偏的，甚至会误导你的故障判断方向。

要是有一套固化好的脚本，文件名叫什么、参数传什么、输出结果关注哪一列，你已经烂熟于心。敲一个命令等于完成一套标准动作，内心完全不慌。

1.2 脚本库的定位：不是工具集，是方法论

很多团队喜欢引入特别重的可视化监控平台，当然那是好事，但监控平台再完善，它回答的是“现在系统怎么了”的宏观问题。而脚本库回答的是“现在这个会话到底在干什么”、“这个表为什么这么大”、“这个索引为什么没生效”这种微观的、具体的问题。

所以我的建议是，不要把脚本库做成一个大而全的文档合集，而是做成一个“带着注释的救命箱”。每一个脚本都应该解决一类特定场景，最好还带一段注释说明“什么时候用这个脚本、看结果的时候重点看哪一列”。

这里也要说明一句，以下脚本以 MySQL 为主要示例，因为它在互联网公司覆盖面最广，但很多思路迁移到其它数据库也是一样的。

2. 核心脚本分类：基于实战场景的五大类

我这几年整理脚本，强迫自己遵循一个原则：脚本必须按“场景”分类，而不是按“数据库对象”分类。也就是说，不要搞一个“索引脚本包”、“表脚本包”这样纯按对象划分的文件夹，因为真到了线上，你是按场景去思考问题的。

2.1 巡检诊断类脚本：先回答系统“活没活”

这类脚本是数据库管理员每天早上到了工位，或者接到线上告警之后，第一时间要跑的“体检项目”。它回答的是三个最基础的问题：数据库连不连得上、整体压力大不大、有没有会话卡死。

连接数是否快要打满，这是很多故障的前奏。一旦连接数耗尽，新的应用请求全部排队，那种故障是非常恐怖的。所以巡检脚本里，连接数使用率必须排第一位。

另外一个容易被忽视的是主从延迟。很多开发写代码的时候只管主库，从库什么时候落后了根本不关心。等到做报表查询或者切主的时候，才发现从库的数据已经落后老远了。巡检脚本里一定要有一条能快速查看所有从库复制状态的命令，这条命令在故障发生时能帮你快速判断“能不能马上切换”。

还有一类诊断是看当前的长时间未提交事务。这类事务最危险，它可能锁住一大堆其他会话的操作。我遇到过一次故障，某同事开启了一个事务但忘记提交，直接导致核心表的更新操作全部阻塞，业务方反馈“系统卡死”，实际情况就是那一个未提交事务在作祟。

2.2 元数据与结构管理类脚本：搞清楚对象长什么样

这一类的价值在于“不知己”的时候帮你“知己”。很多时候我们排查问题半天，最后发现是对表结构不了解，比如字段类型不匹配导致索引失效，或者压根不知道一个大表上有好几个冗余索引。

表大小统计脚本，用来回答“哪个表最占空间”。磁盘空间告警的时候，往缓冲区里塞数据，然后观察命中率，其实方向就错了。你应该先搞清楚大表在哪儿，才能决定是优化还是归档。

索引使用情况统计脚本，用来回答“这个索引有没有人在用”。我们经常会遇到一种情况：某个开发同事出于好心，给一个频繁更新的列加了索引，结果因为这个索引的存在，每次更新都要多维护一棵索引树，反而拖慢了写入速度。用这个脚本，你就能找到哪些索引是“僵尸索引”，然后名正言顺地把它干掉。

2.3 性能统计与慢查询分析类脚本：定位“卡”在哪

“系统变慢了”，这是日常收到最多的反馈。性能分析脚本就要起作用了。这类脚本的核心思路是“抓现场”——把正在发生的事情定格下来分析。

当前活跃会话快照是首选脚本。它能列出当前所有正在执行的SQL、由哪个账号发起、已经跑了多久、在等待什么资源。这就像给正在运行的数据库拍了一张X光片，哪根骨头有问题一目了然。

状态变量对比脚本也很有用。数据库有很多计数器，比如累计执行了多少次查询、扫描了多少行、临时表创建了多少个。通过间隔几秒钟拍两次快照做差值，你就能算出“这短短几秒钟内，数据库内部到底发生了多少剧烈动作”。

2.4 数据变更与批量处理类脚本：安全地“动刀子”

线上数据变更是最危险的操作，一不小心就会出事。这类脚本的核心价值不是帮你把活干完，而是帮你在安全边界内把活干完。

批量更新数据时，怎么控制影响范围很重要。我见过不止一次因为一条update语句忘加where条件，导致全表数据被改的惨剧。所以此类脚本必须是“带刹车”的，要么限制每次处理的行数，要么强制要求先统计影响行数再执行。

2.5 备份恢复与数据归档类脚本：留好后路

很多团队一说到备份，就以为是每天定时跑一下备份命令，就觉得万事大吉。但备份的重点不在于“有没有备份”，而在于“能不能恢复”，以及“恢复要多久”。这类脚本是压在箱子底部的保险单，平常不觉得有用，真出事的时候就是救命稻草。

3. 实操过程与核心脚本实现

下面这部分是文章的重头戏。我会把我整理过的脚本，直接按可复用的格式贴出来，同时补充我对每个脚本的设计思路和参数理解。这些脚本我都加上注释，你在自己环境里部署时，只需要调整库名、阈值等参数即可。

3.1 巡检脚本第一式：一条SQL看尽实例健康

我先给出一套我每天到岗后必跑的巡检脚本。核心思想是“一条联合查询，一眼看全”。

-- 1. 看当前总连接数、活跃连接数与最大连接数 SELECT COUNT(*) AS total_conn, SUM(IF(command != 'Sleep', 1, 0)) AS active_conn, @@max_connections AS max_conn, ROUND(COUNT(*) * 100.0 / @@max_connections, 2) AS conn_usage_pct FROM information_schema.processlist;

这个脚本的价值在于让“连接数使用率”这项指标变成一屏数据。我一般会盯两个点：一是conn_usage_pct长期超过80%，说明连接池配置可能需要调整；二是active_conn与total_conn差距极大，说明大量连接可能是被闲置占用的，需要去排查应用侧连接池配置。

再配合一条看长事务的，这是很多异常的根源：

-- 2. 找出运行时间超过60秒的事务会话 SELECT id, user, host, db, command, time, state, LEFT(info, 200) AS sql_text FROM information_schema.processlist WHERE command != 'Sleep' AND time > 60 ORDER BY time DESC;

这条脚本我加了LEFT(info, 200)，因为有时候一个SQL文本特别长，把整个结果集都撑爆了，反而影响你快速浏览。只截前200个字符，足够你判断它是不是需要关注的对象。

3.2 巡检脚本第二式：主从复制与延迟检查

主从架构下，最怕的就是从库延迟还后知后觉。

-- 3. 查看所有从库的复制状态 SHOW SLAVE STATUS\G;

这个脚本输出内容很杂，你需要关注的是以下三个字段：

• Slave_IO_Running: 负责接收主库日志的IO线程是否正常，需要看到Yes。
• Slave_SQL_Running: 负责执行日志的SQL线程是否正常，也需要看到Yes。
• Seconds_Behind_Master: 从库落后主库的秒数，这个值越大越危险。

如果你管理的是MySQL 8.0以上的版本，SHOW SLAVE STATUS改成了SHOW REPLICA STATUS，字段名也有调整，老脚本直接拿到新版本上跑会报错，这一点要注意。我是吃过亏的，在生产环境用5.7的脚本去跑8.0的实例，当时就懵了。

3.3 元数据脚本第一式：按大小给表排座次

磁盘空间不够的时候，你需要的是下面这条：

-- 4. 统计当前库里所有表的大小并按大小倒序排列 SELECT table_schema AS '库名', table_name AS '表名', engine AS '存储引擎', table_rows AS '行数(估算)', ROUND((data_length + index_length) / 1024 / 1024 / 1024, 2) AS '总大小(GB)', ROUND(data_length / 1024 / 1024 / 1024, 2) AS '数据大小(GB)', ROUND(index_length / 1024 / 1024 / 1024, 2) AS '索引大小(GB)' FROM information_schema.tables WHERE table_schema = 'your_db_name' ORDER BY (data_length + index_length) DESC LIMIT 30;

这里要特别提醒一下，table_rows在 InnoDB 引擎下是一个估算值，它来自数据库的统计信息，不是精确值。千万别拿这个字段去做精确对账，否则你会发现怎么都对不上。

3.4 元数据脚本第二式：揪出失效与冗余索引

索引问题是性能问题的大头。我常用的有两招。

第一招：查表上有哪些索引，以及这些索引到底被用没用。

-- 5. 查看指定表的索引详情 SELECT INDEX_NAME AS '索引名', SEQ_IN_INDEX AS '索引中的顺序', COLUMN_NAME AS '字段名', NON_UNIQUE AS '是否唯一', CARDINALITY AS '基数估算' FROM information_schema.STATISTICS WHERE table_schema = 'your_db_name' AND table_name = 'your_table_name' ORDER BY INDEX_NAME, SEQ_IN_INDEX;

看这张表的时候，重点看两点：一是CARDINALITY，这个值除以表行数，如果比例特别低（比如不到10%），那这个索引的区分度就太差了，优化器大概率不会用；二是看看有没有多个索引都以同一个字段开头，这种大概率是冗余索引。

第二招：在开启了performance_schema的情况下，去查表上索引的实际使用频率。

-- 6. 查看本实例所有表的索引使用统计（8.0及以上版本） SELECT OBJECT_SCHEMA, OBJECT_NAME, INDEX_NAME, COUNT_STAR FROM performance_schema.table_io_waits_summary_by_index_usage WHERE OBJECT_SCHEMA = 'your_db_name' AND INDEX_NAME IS NOT NULL ORDER BY COUNT_STAR ASC LIMIT 20;

排在末尾的那些索引，说明从数据库启动到现在几乎没被用过。这样的索引，基本就是“僵尸索引”，确认没在查询计划中被用到之后，可以择机删除。但千万注意，先确认再删，有些查询可能只是频率极低，而不是完全不用。

3.5 性能分析脚本第一式：当前到底卡在哪儿

系统卡顿的时候，我用得最多的是这两条，它们能从不同维度告诉你数据库当前的“瞬时状态”。

-- 7. 立即抓取当前正在执行的完整SQL快照 SELECT id, user, host, db, command, time, state, REPLACE(LEFT(info, 300), '\n', ' ') AS sql_text, ROUND(info/1024, 2) AS '已读数据量(MB)' FROM information_schema.processlist;

注意第十列写法需要说明一下，通常info是文本字段，如果要看它发送的字节数，应该改用information_schema.processlist中不带这个信息。MySQL 的 processlist 不直接提供“已读数据量”，所以这一列可以直接去掉，不要被这个字段误导。真实场景里，我们主要看time和state两列。state如果一直停留在Sending data或者Copying to tmp table，说明SQL可能正在进行大量的磁盘临时表操作，这种一般就是SQL写得有问题。

另一条是看数据库内部的等待事件，这是定位“锁”相关问题的重要参考：

-- 8. 查看最近一段时间的锁等待情况 SHOW ENGINE INNODB STATUS\G;

这个命令输出内容很长，不要从头看到尾，直接搜索两个关键片段：LATEST DETECTED DEADLOCK用来查看最近一次死锁的详细现场，里面会打印出死锁涉及的两条SQL和持有锁的线程；TRANSACTIONS部分可以看当前有哪些事务处于LOCK WAIT状态。

3.6 性能分析脚本第二式：慢查询日志分析基础

光看当前快照还不够，你还需要结合历史慢查询日志来复盘。很多数据库默认没开慢查询日志，或者阈值设置得不合理，这种情况要先确认：

-- 9. 查看慢查询配置 SHOW VARIABLES LIKE 'slow_query_log'; SHOW VARIABLES LIKE 'long_query_time';

如果slow_query_log是 OFF，或者long_query_time设置成了 10秒 这种基本等于没设的门槛，我建议你开启并把阈值调低到 1秒，这是性价比非常高的一项优化。开了之后，定期用工具分析慢日志，可以直接下钻到具体某一条SQL的执行计划，然后针对性地优化索引或改写SQL。

3.7 批量处理脚本设计：大表删除的“龟速”方案

删除大表数据算是一个高危操作。如果直接跑DELETE FROM big_table WHERE create_time < '2024-01-01'，一旦数据量超过千万级别，会带来两个后果：一是产生超大的事务，导致undo日志膨胀；二是长时间的锁等待，直接影响线上业务。

我一般用分批删除的方式，核心思路是把一个大事务拆成无数个小事务，每删一批就提交释放锁。这里我通常会写成存储过程来跑，其中用到了SET SESSION autocommit这种事务控制语句，批量提交的效果完全不一样。

-- 10. 分批删除大表数据（请先在一个测试表上验证，再上生产） DELIMITER $$ CREATE PROCEDURE batch_delete_old_data( IN p_batch_size INT, IN p_sleep_seconds INT ) BEGIN DECLARE v_rows_affected INT DEFAULT 1; WHILE v_rows_affected > 0 DO DELETE FROM your_table_name WHERE create_time < DATE_SUB(NOW(), INTERVAL 180 DAY) LIMIT p_batch_size; SET v_rows_affected = ROW_COUNT(); COMMIT; IF v_rows_affected > 0 THEN DO SLEEP(p_sleep_seconds); END IF; END WHILE; END$$ DELIMITER ; -- 调用：每批删500行，每批之间停2秒 CALL batch_delete_old_data(500, 2);

这段代码里有两个点值得说明一下。一是LIMIT p_batch_size这个条件必须有，否则循环一次就直接删光了，它会变成一个大型事务，后果严重；二是每次循环后DO SLEEP(p_sleep_seconds)这个操作看似多余，实际上它承担了两个功能：给主从复制留出追日志的时间，避免因为删除太快造成从库延迟飙升；同时给其他业务SQL留出抢占资源的时间窗口，避免删除线程一直独占IO。

3.8 批量更新与误操作防御脚本

跟删除并列的高危操作还有更新。我给自己定下规矩：线上执行 update 之前，必须先跑一遍更新条件对应的select查询，看看到底会命中多少行、影响哪些数据。这一步看似耽误了一分钟，实则能防止绝大多数惨案。

-- 11. 更新前必跑的确认脚本 SELECT COUNT(*), MIN(id), MAX(id), SUM(CASE WHEN status != 'valid' THEN 1 ELSE 0 END) AS invalid_cnt FROM your_table_name WHERE order_time > '2025-01-01' AND order_status = 'pending';

如果确认后仍要执行更新，我也推荐使用分批更新的方式，思路和分批删除完全一致，同样可以保证每次事务规模可控。

3.9 数据归档脚本：让主表持续保持轻盈

数据量达到一定规模，光靠删除是不够的，因为业务可能要保留历史数据。这时候就需要“归档”：把旧数据从主表搬到历史表中去。归档脚本的核心流程是“先建表、再插入、后删除”。

-- 12. 创建归档表（保证结构一致的前提） CREATE TABLE your_table_name_archive LIKE your_table_name; -- 13. 搬移超过180天的数据（分批次循环，每批5000条） INSERT INTO your_table_name_archive SELECT * FROM your_table_name WHERE create_time < DATE_SUB(NOW(), INTERVAL 180 DAY) LIMIT 5000;

实际跑的时候，我会把“插入归档表”、“从主表删除对应记录”这两个动作放在同一个事务里，保证两边数据强度一致。如果先插入再删除中间没有事务包裹，一旦第二步失败，就会出现既在归档表里、同时还在主表里的“双份数据”，后续对账就很麻烦。

4. 常见问题与排查技巧实录

脚本本身不复杂，真正复杂的是在跑脚本的过程中遇到的形形色色的问题。我在这部分把高频踩坑点和排查逻辑整理成一个“速查手册”，照着做基本能解决八成问题。

4.1 参数类问题的坑：版本差异与设置失效

先列几个我印象深刻的问题。

第一是版本差异导致脚本报错。同样的information_schema.processlist，在 MySQL 5.7 和 8.0 下面的某些字段行为不一样。5.7 下processlist可以看所有用户的会话，8.0 里如果你权限不足，就只能看到自己账号的会话。这个区别在权限分配时尤其重要，否则用监控账号去跑巡检脚本，查出来的数据永远是“一片祥和”。

第二是设置参数未持久化。查询得知slow_query_log是 ON，但其实它是全局临时的，重启后依然会恢复原样。正确做法是写到配置文件里，并确认global和persist两种方式是不是都生效。

第三是字符集不一致导致的查询异常。比如脚本里硬编码了中文条件，但如果客户端连数据库的字符集和表的字符集不一致，查询结果可能为空，或者直接报“Illegal mix of collations”错误。

4.2 经典问题速查表

我把平时被问得最多的一些问题整理成了表格，方便你照着做。

这个表格里的结论，都是实际项目中验证过的高频走向。顺带说一句，删除数据后磁盘空间不释放，是 InnoDB 引擎的一种特性，它删除行只是在页上打标记，表空间文件不会马上缩小，所以不要在“删了数据但空间没变化”这件事上太纠结，这不一定代表磁盘故障。

4.3 脚本库管理的小技巧

脚本积累到一定数量之后，管理本身也会成为问题。我个人的习惯是，把脚本文件按“场景_功能.sql”的形式命名，比如01_check_conn_by_business.sql、02_kill_long_transaction.sql。

在脚本文件顶部，我建议加一段固定的注释头，内容包括：脚本适用版本、执行权限要求、主要输出字段说明、最后验证日期。不要觉得这是形式主义，当你在半夜三点被叫起来处理故障的时候，一段清晰的注释头就是你最可靠的导航。

再补充一个多数人不知道的小技巧：把某些高频命令封装成函数或命令别名。比如在命令行工具配置中设置上方提到的连接命今的别名，这样到现场后只需要敲几个字母，就能连上目标数据库并直接进入工作流。这个小习惯在争分夺秒的故障现场特别有价值。

5. 关于执行计划：手腕上的最后一公里

脚本查出了问题，定位到了具体SQL，但这只是完成了上半场。下半场要回答的核心问题是：这条SQL为什么会慢，以及怎么让它快起来。这就要用到执行计划分析。

-- 14. 查看SQL的执行计划（关键一步） EXPLAIN SELECT ... -- 或者如下方式，直接看优化器的成本估算 EXPLAIN FORMAT=JSON SELECT ...

执行计划里优先关注三样东西：

• type：这个字段体现了访问类型。如果看到ALL，意味着全表扫描，大表上出现这个字段值通常意味着要出问题。至少要达到range或者ref，理想状态当然是const。
• Extra：出现了Using filesort，说明排序操作无法利用索引完成，需要在内存或磁盘里做额外排序，大量数据时很伤性能；出现Using temporary，说明使用了临时表，大查询下这是典型的性能瓶颈信号。
• rows：优化器估算的需要扫描的行数。这个值比真实值可能偏大也可能偏小，但数量级是否在可接受范围，基本能判断SQL的“健康度”。

我个人在确认某条SQL需要优化时，会强制让自己先把执行计划截图保存，再去改SQL或者加索引，改完后再跑一次计划对比。前后两次计划的差异，就是你这次优化的直接证据，也是后续向同事宣讲“为什么这样改有效”的凭据。

6. 实战复盘：一次典型的“深夜救火”脚本组合

最后我用一个真实经历过的故障场景，把本文提到的脚本串联一遍，让你对这些脚本怎么组合使用有一个完整的体感。

事故背景是：某核心业务的数据库在某天晚上流量突增，应用监控大面积告警，业务反馈接口响应时间从几十毫秒飙升到好几秒。

当时我的操作顺序是这样的：

第一步，我先确认连接和实例是否还活着。这个动作说是对上述第一条巡检脚本的响应式应用，其实更加直接——我先跑了一条快速命令看能不能返回结果。能返回，说明实例本身还活着，没有直接挂掉。

第二步，我跑了活跃会话快照脚本。结果很清晰：出现大量time在10秒以上的会话，SQL文本高度集中在同一条查询上。它的共同点是都在查同一张核心订单表。

第三步，我立刻查看这张订单表上的索引，确认这张表有一个单列索引create_time，却没有组合索引(user_id, create_time)。而问题SQL的过滤条件正好是WHERE user_id = xxx AND create_time > yyy，在只有单列索引的情况下，只能先根据create_time拿到一大片数据，再逐行过滤user_id，导致大量无效扫描。

第四步，我加了一个组合索引，并在测试环境对同样数据量跑了一次验证，确认type从ALL变成了ref，扫描行数从百万级降到了千级。随后把索引变更提交到生产并执行。

第五步，索引生效后，我再跑一次活跃会话快照脚本，发现长时间会话数量肉眼可见地降下来了，接口耗时也恢复到正常区间。

整个过程中，我实际上用到了：连接巡检、会话快照、索引查看、执行计划分析、变更验证这五类脚本。它们之间是有清晰的组合逻辑的：先确认性命是否无虞，再抓取现场，然后定位表与索引的“症结构”，最后用数据验证优化效果。

所以我的真实体会是：数据库常用脚本最大的价值，不是在某个特定时刻处理某个特定故障，而是它形成了一套确定性动作，让你在面对未知问题时，可以按固定路径推进，而不是随机乱撞。只要你把基础脚本维护好，再复杂的故障也能一步步拆解成几个清晰的动作。

最后再分享一个小技巧：脚本库里一定要留一个“暂存区”文件夹，把你临场写的、还没有验证过的脚本放进去，然后在文件名上标注日期和“未验证”字样。这样既能保留灵感，又避免了把不确定的东西混入正式脚本导致误用。等你验证通过后，再移入正式分类目录，同时更新一下注释头版本号。这套机制看着很简单，但长期坚持下来，你的脚本库会越来越值钱。