MySQL数据库存储监控与优化实战指南

1. 项目背景与核心需求

在日常数据库运维工作中，我们经常需要监控MySQL数据库的存储使用情况。特别是当服务器磁盘空间告警时，快速定位哪些业务库占用了大量空间，以及这些库中哪些表是"空间大户"就显得尤为重要。通过命令行直接查询库表大小，比登录phpMyAdmin等图形工具更高效，尤其适合自动化监控场景。

上周我们生产环境就遇到了一次磁盘空间不足的紧急情况。当时通过这套方法，5分钟内就锁定了某个日志表异常增长的问题，及时清理后避免了服务中断。下面就把这个实用技巧完整分享给大家。

2. 核心SQL命令解析

2.1 查看所有业务库大小

基础命令：

sql复制SELECT 
    table_schema AS '数据库',
    ROUND(SUM(data_length + index_length) / 1024 / 1024, 2) AS '大小(MB)'
FROM 
    information_schema.tables 
GROUP BY 
    table_schema
ORDER BY 
    SUM(data_length + index_length) DESC;

关键点说明：

• data_length：数据部分占用空间
• index_length：索引部分占用空间
• 除以1024两次是将字节转换为MB
• ROUND函数保留两位小数

注意：information_schema是MySQL自带的元数据库，存储了所有库表的元信息

2.2 查看指定库中各表大小

以查看名为order_db的库为例：

sql复制SELECT 
    table_name AS '表名',
    ROUND(data_length/1024/1024, 2) AS '数据大小(MB)',
    ROUND(index_length/1024/1024, 2) AS '索引大小(MB)',
    ROUND((data_length + index_length)/1024/1024, 2) AS '总大小(MB)',
    table_rows AS '行数'
FROM 
    information_schema.tables 
WHERE 
    table_schema = 'order_db'
ORDER BY 
    (data_length + index_length) DESC;

3. 高级用法与技巧

3.1 自动化监控脚本

将查询结果输出到文件：

bash复制mysql -uroot -p -e "SELECT table_schema, ROUND(SUM(data_length + index_length)/1024/1024,2) FROM information_schema.tables GROUP BY table_schema;" > db_size_report.txt

3.2 筛选大表（超过1GB）

sql复制SELECT 
    table_schema AS '数据库',
    table_name AS '表名',
    ROUND((data_length + index_length)/1024/1024, 2) AS '大小(MB)'
FROM 
    information_schema.tables 
WHERE 
    ROUND((data_length + index_length)/1024/1024, 2) > 1024
ORDER BY 
    (data_length + index_length) DESC;

3.3 查看碎片化严重的表

高碎片化表会影响性能：

sql复制SELECT 
    table_name AS '表名',
    data_free AS '碎片空间(字节)',
    ROUND(data_free/(data_length + index_length)*100, 2) AS '碎片率(%)'
FROM 
    information_schema.tables 
WHERE 
    table_schema = 'order_db'
    AND data_free > 0
ORDER BY 
    data_free DESC;

4. 实战经验与避坑指南

4.1 权限问题解决方案

常见报错："SELECT command denied to user"

• 解决方案：确保执行用户有SELECT权限

sql复制GRANT SELECT ON information_schema.* TO 'monitor_user'@'%';

4.2 数据准确性说明

• table_rows是估算值，MyISAM准确但InnoDB可能有偏差
• 获取精确行数建议使用COUNT(*)，但大表性能消耗大

4.3 性能优化建议

1. 生产环境避免频繁查询（特别是大集群）
2. 可以查询后存入监控系统
3. 在从库执行这类统计查询

4.4 存储单位换算技巧

常用换算公式：

• KB：/1024
• MB：/1024/1024
• GB：/1024/1024/1024
• TB：/1024/1024/1024/1024

5. 可视化方案扩展

虽然本文聚焦命令行，但可以结合其他工具：

1. 使用Python+Matplotlib生成趋势图
2. 将数据导入Grafana展示
3. 用Excel处理查询结果制作报表

6. 典型应用场景

1. 磁盘扩容评估：找出增长最快的表预测存储需求
2. 性能优化：定位过大的索引或未分区的历史表
3. 归档策略制定：识别可以归档的冷数据
4. 成本分摊：按库表大小计算资源占用成本

7. 常见问题排查

7.1 查询结果为空

可能原因：

• 没有对应权限
• 表名大小写不匹配（Linux下MySQL区分大小写）
• 过滤条件太严格

7.2 数值异常偏大

检查：

• 是否单位换算错误
• 是否有未释放的临时表
• 是否统计了系统表

7.3 查询超时

解决方案：

• 添加LIMIT分批查询
• 在业务低峰期执行
• 使用EXPLAIN分析查询计划

8. 维护建议

1. 定期（如每周）收集库表大小数据，建立基线
2. 设置增长率告警（如单日增长超过20%）
3. 对大表考虑分区策略
4. 建立自动化清理机制（如日志表定期归档）

这套方法在我们生产环境已经稳定运行3年，帮助处理了数十次存储告急情况。特别是当多个业务团队共用数据库时，能快速定位责任方，避免互相推诿。建议DBA同学都将其加入日常巡检清单。