关于mysql:记一次MySQL-DB实例磁盘告警的处理过程

51次阅读

共计 2056 个字符，预计需要花费 6 分钟才能阅读完成。

明天早上，业务库磁盘告警了，之前咱们有聊过如何对 web 服务器磁盘告警的解决，明天咱们来讲一下如何解决 DB 实例磁盘告警，最常见的解决办法有如下几种：

磁盘扩容，当初大部分公司的业务都应用了各种云的 Paas 产品，间接界面扩容即可。

对数据进行归档，常见的是对一些日志表的解决，比方只保留最近三个月或半年或一年的数据，其余过往数据都归档到一个冷备库中。

清理数据，比方业务上的一些 bug 导致的短时间内业务数据量增长过快的状况。

迁徙数据，比方把告警的 DB 实例上一些库迁往另一个 DB 实例。

不论用哪种形式，首先咱们都须要理解一下 DB 库里到底是哪些表比拟占空间，这样才比拟好，因为很有可能是因为某个不合理的业务点导致某个表过大，从而引起磁盘告警，这样从优化业务的角度去从根本上解决磁盘告警的问题。

那么咱们首先要找到某个库或者某个表占用比拟大，我明天遇到的是告警实例就一个业务库，那我能够通过以下几种形式来获取占用比拟大的表：

1. 通过 Phpmyadmin size 字段排序查看哪个表占用过大

2. 通过 SQL 来获取占用空间大小的表的排序

SELECT 
  TABLE_NAME, 
  concat(truncate(data_length/1024/1024,2),'MB') as data_size, 
  concat(truncate(index_length/1024/1024,2),'MB') as index_size 
FROM information_schema.tables 
WHERE TABLE_SCHEMA = '库名' GROUP BY TABLE_NAME ORDER BY data_length desc

+--------------------------------+-----------+------------+
| TABLE_NAME                     | data_size | index_size |
+--------------------------------+-----------+------------+
| xxxxxxxxxxxxxxxxx              | 499.08 MB | 95.03 MB   |
| yyyyyyyyyyyyyyyyy              | 101.96 MB | 19.13 MB   |
| zzzzzzzzzz                     | 63.49 MB  | 14.32 MB   |
| ddddddddddddddddddddd          | 56.97 MB  | 30.93 MB   |
| eeeeeeee                       | 52.17 MB  | 12.31 MB   |
| fffffffffffffffffffff          | 39.94 MB  | 0.00 MB    |
| gggggggggggggggg               | 37.22 MB  | 21.50 MB   |

3. 如果有多个数据库想查问所有数据库占用空间大小：

SELECT 
  TABLE_SCHEMA, 
  concat(truncate(sum(data_length)/1024/1024,2),'MB') as data_size, 
  truncate(sum(data_length)/1024/1024,2) as data_size2, 
  concat(truncate(sum(index_length)/1024/1024,2),'MB') as index_size 
FROM information_schema.tables GROUP BY TABLE_SCHEMA ORDER BY data_size2 desc

+--------------------+--------------+------------+------------+
| TABLE_SCHEMA       | data_size    | data_size2 | index_size |
+--------------------+--------------+------------+------------+
| database1           | 926887.93 MB |  926887.93 | 37913.96MB |
| database2           | 2.72 MB      |       2.72 | 0.21MB     |
| database3           | 0.17 MB      |       0.17 | 0.00MB     |
| database4           | 0.14 MB      |       0.14 | 0.00MB     |
| performance_schema | 0.00 MB      |       0.00 | 0.00MB     |
+--------------------+--------------+------------+------------+
5 rows in set, 48 warnings (0.07 sec)

当咱们找到某张表磁盘占用过大时，咱们能够通过写脚本的形式来实现数据清理工作（我明天遇到的就是能够清理的状况），这里须要留神的是最好不要一次性删除过多记录，或者短时间删除过多记录，这样有可能会导致从库提早加大，或者引起线上服务故障。所以稳当的形式是在零碎闲时，通过间歇式少量多次删除表记录，最初清完记得 optimize table。

以上就是当一个 DB 实例磁盘告警时的一些解决思路。

专一 Web 开发、后盾开发、DB 性能及架构
我的公众号“码农漫谈”，如果喜爱我的文章，能够关注公众号，打工不易：（，欢送技术沟通与交换，每天提高一点点

正文完