《Kingbase护城河》——数据库存储空间全景探测与精细化瘦身实战

当你的数据库页面文件从50GB悄悄膨胀到500GB，你以为是业务增长，其实是“数据肥胖症”在作祟。

一、为什么你的数据库总在“悄悄变胖”？

某电商公司的运维老张最近很焦虑：Kingbase数据库每季度需要扩容存储，硬件成本飙升，运维团队疲于奔命。直到一次大促期间，磁盘直接爆满，宕机3小时，损失超200万。

事后他找我排查，发现数据库中躺着大量“僵尸表”——历史备份残留、重复索引、未清理的临时表。最离谱的一张日志表，单表占用180GB，实际有效数据不到5%。

这不是个案。 据IDC统计，企业数据库中平均有30%-45%的存储空间被无效或冗余数据占用。在Kingbase这类高性能数据库中，空间浪费往往更隐蔽——因为默认参数乐观，开发者容易忽视“数据粪便”的堆积。

二、第一步：给数据库做一次“CT扫描”

要精准瘦身，先要知道哪里胖。推荐三把“手术刀”：

1. 全景空间探测SQL

SELECT
    schemaname,
    tablename,
    pg_size_pretty(pg_total_relation_size(schemaname||'.'||tablename)) AS total_size,
    pg_size_pretty(pg_relation_size(schemaname||'.'||tablename)) AS table_size,
    pg_size_pretty(pg_indexes_size(schemaname||'.'||tablename)) AS index_size
FROM pg_tables
WHERE schemaname NOT IN ('pg_catalog','information_schema')
ORDER BY pg_total_relation_size(schemaname||'.'||tablename) DESC
LIMIT 20;

这条命令会列出排名前20的“大胃王”，一眼找出问题表。

2. 索引健康检查

索引就像书的目录，太多反而找不快。执行：

SELECT indexrelname, idx_scan, idx_tup_read, idx_tup_fetch
FROM pg_stat_user_indexes
WHERE idx_scan = 0;

那些从未被扫描的索引（idx_scan=0），就是“寄生虫”，建议果断删除。

3. 死元组侦探

Kingbase的MVCC机制会导致大量死元组（已删除但未回收的数据行）。使用：

SELECT relname, n_dead_tup, n_live_tup,
    round(n_dead_tup * 100.0 / nullif(n_live_tup, 0), 2) AS dead_ratio
FROM pg_stat_user_tables
WHERE n_dead_tup > 0
ORDER BY dead_ratio DESC;

当死元组占比超过20%，这个表就需要“排毒”了。

三、第二步：针对性“吸脂手术”

实战案例：某物流系统表优化

上面提到的电商老张，其核心表logistics_orders占180GB，我先执行：

SELECT pg_size_pretty(pg_relation_size('public.logistics_orders'));
-- 输出: 180 GB

然后查询死元组比例：

SELECT n_dead_tup, n_live_tup FROM pg_stat_user_tables WHERE relname='logistics_orders';
-- 输出: 死元组占比高达73%

方案：

清理死元组：VACUUM FULL VERBOSE public.logistics_orders; 释放约120GB空间。
归档旧数据：将6个月前的历史记录迁移至logistics_orders_archive表，再用分区表管理。
删除无用的复合索引：发现该表有8个索引，其中3个从未被使用，直接DROP。

结果： 表空间从180GB降至28GB，查询性能反而提升30%（因索引减少）。

实用建议清单：

✅ 定期VACUUM：对高频更新的表，每夜执行VACUUM ANALYZE（非FULL版本，轻度整理）。
✅ 使用分区表：按时间分区的表，可单独DROP老旧分区，比DELETE快100倍。
✅ 监控膨胀率：设置阈值告警，当死元组比例超过15%自动触发优化。
❌ 避免全量DELETE：不要用DELETE FROM big_table，改用TRUNCATE或分批删除。

四、第三步：长期“塑形计划”——自动化瘦身脚本

手动操作太累，我们可以写一个每周运行一次的自动化脚本（伪代码，需根据环境调整）：

#!/bin/bash
# kingbase_cleanup.sh

# 1. 获取所有数据库，排除系统库
db_list=$(ksql -l -t | grep -v 'template\|postgres\|kingbase' | cut -d'|' -f1)

for db in $db_list; do
    # 2. 对每个数据库进行温和清理
    ksql -d $db -c "VACUUM ANALYZE;" > /dev/null 2>&1

    # 3. 查找死元组超过20%的表
    ksql -d $db -c "SELECT relname FROM pg_stat_user_tables 
        WHERE n_dead_tup > 0.2 * n_live_tup;" -t > /tmp/table_list.txt

    # 4. 对高危表执行VACUUM FULL
    while read tab; do
        ksql -d $db -c "VACUUM FULL $tab;"
    done < /tmp/table_list.txt
done

将此脚本加入crontab，每周日凌晨执行。注意：VACUUM FULL会锁表，建议在低峰期操作。

五、行动号召 + 免责声明

🎯 你的下一步行动：

今天：运行上文“全景探测SQL”，看看你的数据库前10名“大胃王”是谁。
本周：选择一个闲置索引或死元组超过30%的表，执行一次VACUUM FULL。
下月：建立分区表策略和自动化脚本，避免问题复发。

记住： 数据库越轻，查询越快，成本越低。每释放100GB空间，一年可能省下3000-8000元云存储费用。

⚠️ 免责声明

本文提供的SQL命令和脚本方案供学习参考。实际操作前，请务必：

在测试环境验证，确认无副作用。
准备完整备份（特别是VACUUM FULL操作会锁表且不可逆）。
对于生产环境，建议先在业务低峰期测试，或咨询数据库管理员。

作者不对因执行脚本导致的任何数据丢失、服务中断或性能下降承担责任。安全第一，瘦身第二！

你的数据库“瘦”了吗？ 欢迎在评论区分享你的存储优化故事或踩坑经历——也许下一个实战案例的主角就是你。