Cloud SQL MySQL磁盘满扩容后服务变慢超时，求排查原因

当Cloud SQL MySQL实例因磁盘耗尽挂掉，扩容磁盘恢复后出现卡顿、查询超时，大概率是磁盘满期间引发的数据库内部状态异常，而非扩容操作本身导致。以下是具体排查方向和解决方法：

可能的核心原因 #

• 表碎片化严重：磁盘满时，InnoDB无法正常完成页合并、写入操作，恢复后会产生大量碎片，导致查询IO开销剧增
• InnoDB缓冲池未预热：服务重启后缓冲池是空的，所有查询都要走磁盘IO，直到常用数据被加载到内存
• 残留事务/锁阻塞：磁盘满期间中断的事务未正常回滚，遗留锁或未提交事务阻塞后续查询
• Django连接池异常：磁盘满时数据库连接被强制断开，Django连接池可能残留无效连接，导致新查询无法获取可用连接

排查步骤 #

1. 定位慢查询
   临时开启慢查询日志：

   SET GLOBAL slow_query_log = 'ON';
   

   或直接筛选运行超时的查询：

   SELECT * FROM INFORMATION_SCHEMA.PROCESSLIST WHERE TIME > 10; -- 筛选运行超过10秒的查询
   

   重点关注是否有全表扫描、索引失效的查询。

2. 检查表碎片
   执行以下SQL查看各表的碎片大小：

   SELECT TABLE_NAME, 
          ROUND(DATA_FREE / 1024 / 1024, 2) AS DATA_FREE_MB 
   FROM INFORMATION_SCHEMA.TABLES 
   WHERE TABLE_SCHEMA = '你的数据库名';
   

   如果DATA_FREE_MB远大于表本身大小，说明碎片严重。

3. 查看InnoDB缓冲池状态
   执行：

   SHOW ENGINE INNODB STATUS;
   

   找到Buffer pool hit rate部分，如果命中率低于99%，说明缓冲池未预热，大部分查询都在走磁盘。

4. 检查事务与锁
   查看阻塞的事务：

   SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCK_WAITS;
   

   或通过SHOW PROCESSLIST找到状态为Locked的线程。

解决方法 #

1. 清理表碎片
   对碎片化严重的表执行（低峰操作，会锁表）：

   OPTIMIZE TABLE `你的表名`;
   

   对于大表，更安全的方式是重建表：

   ALTER TABLE `你的表名` ENGINE=InnoDB;
   

2. 预热InnoDB缓冲池
   手动触发缓冲池加载（需提前配置过缓冲池dump）：

   SET GLOBAL innodb_buffer_pool_dump_now = ON;
   SET GLOBAL innodb_buffer_pool_load_now = ON;
   

   也可以手动执行系统中最常用的几个查询，强制将数据加载到缓冲池。

3. 清理阻塞事务
   通过SHOW PROCESSLIST找到阻塞线程的Id，执行：

   KILL 线程Id;
   

   清理所有长时间运行的未提交事务。

4. 重启Django服务
   磁盘满期间数据库连接异常，Django连接池可能残留无效连接，重启服务可重置连接池，确保新查询使用有效连接。

5. 检查磁盘IO性能
   用iostat -x 1查看磁盘的读写延迟（await指标），如果延迟过高，需检查Cloud SQL的磁盘类型是否符合业务需求。

内容的提问来源于stack exchange，提问作者Assem