把每行的字节数变成能拿去做规划的表容量
数据库回答问题一律用字节。pg_total_relation_size('orders') 返回的是一个裸整数；information_schema.tables 里的 data_length 和 index_length 也是字节；存储引擎的统计页面丢给你的，是一个九位或十二位、连单位都不写的数字。而容量规划这一侧全是吉字节——你要开多大的盘、要把云盘扩到多少、要让谁签字批的那笔预算。
GB = 字节 ÷ 1 000 000 000。所以一张报出 42 500 000 000 字节的表，就是 42 500 000 000 ÷ 1 000 000 000 = 42.5 GB。真正有用的本事不是这一步除法，而是搞清楚这个数字里到底包含了哪些字节。关系大小和表大小是两个不同的值，容量预测出岔子，多半就出在这两者的差额上。
行宽从来不只是各列之和
索引往往是更大的那一半
增长是速率，不是一张快照
从一个字节数到一份扩容方案
从数据库里取出字节数
要那个未经格式化的整数，别要漂亮的字符串——原始值才是你要换算的对象，也免得服务端已经替你四舍五入到一位小数。
粘进字节一栏
吉字节数随打随出。查询结果常常已经用空格分好组，或者用逗号当小数点，两种都能处理，空格会被直接忽略。
复制进容量方案
每一栏的复制按钮给回的都是纯数字，可以直接落进表格单元格、Terraform 里的云盘大小或一条工单，不用先手工去掉单位。
反过来写监控阈值
监控规则或配额要用数据库自己暴露的单位时，把两栏交换一下，从吉字节回到字节。任一下拉菜单都支持搜索，表长到 GB 装不下时，太字节一敲就有。
行宽 × 行数：一张表究竟要吃多少空间
把落盘后的平均行宽乘以行数，得到堆表字节数；再除以十亿就是吉字节。下表假定行宽已经把每行的头部算进去了，且不含索引——索引要另外加。
| 典型表 | 行宽 | 行数 | 堆表字节数 | 折合 GB |
|---|---|---|---|---|
| 窄表事件流 | 96 B | 250 000 000 | 24 000 000 000 | 24 GB |
| 会话记录 | 128 B | 10 000 000 | 1 280 000 000 | 1.28 GB |
| 订单明细 | 256 B | 50 000 000 | 12 800 000 000 | 12.8 GB |
| 用户资料 | 512 B | 100 000 000 | 51 200 000 000 | 51.2 GB |
| 带 JSON 的审计日志 | 1 024 B | 5 000 000 | 5 120 000 000 | 5.12 GB |
| 宽行文档表 | 2 048 B | 1 000 000 | 2 048 000 000 | 2.048 GB |
还有两项修正几乎总要考虑。等待清理的死元组会让堆表比算出来的更大；任何取值超过大约两千字节的列会被压缩并挪到行外存储关系里，单纯的表大小不含它，而关系总大小含。
比对多张表时两栏都是活的
在任意一栏输入，另一栏立刻跟上，于是一条查询列出来的一串关系大小可以一口气看完，不用每次先清空再重输。
十二位数也读得清
千位之间用空格分隔，结果特别大时切到科学计数法，裸字节数少数一位多数一位，一眼就能看出来。
表涨过 TB 也跟得上
两个单位菜单都支持搜索、且列出全部存储单位，所以同一个页面既能算千字节级的小字典表，也能算太字节级的分区事实表。
生产数据留在本地
页面加载完之后一切都在浏览器里算完，从生产库里抄出来的大小不会被发去任何地方。
数据库容量相关问题
为什么表比各列宽度加起来还大？
数据还没开始存，每行就先背了一笔固定开销。在 PostgreSQL 里是 23 字节的元组头，加上页内 4 字节的行指针，列值还要按各自的对齐边界补齐——bool 后面跟一个 bigint，可能白白浪费七个字节。窄表上这些加起来能占到一行的三分之一。所以要用真实行宽、而不是名义行宽，去换算吉字节。
规划容量时要不要把索引算进去？
要，而且经常被低估。每个索引都要存自己的键列、一个行指针和自己的页开销，所以一张带六个索引的表，花在索引上的空间可能超过堆表。堆表和索引分别估、分别换成吉字节、再按总和去开容量——然后还得给重建索引时那份临时副本留出余量。
关系总大小到底包含了些什么？
它返回的字节数涵盖堆表、全部索引、空闲空间映射和可见性映射，以及挂在这张表上的行外存储关系。而单纯的表大小函数只管堆表和它的映射文件。监控面板和手工查询对同一张表报出不同数字时，原因几乎总是这个——一边把索引算了，另一边没算。
超大的列值会怎样打乱这套算法？
一行必须塞进一个页里，所以某个值一旦涨过大约两千字节，引擎会先压缩它；还不够就把它移出行外、放进一个附属关系，行里只留一个小指针。于是看得见的行宽塌了下去，真正的存储却在别处。对于装大段文本或 JSON 文档的表，不去量那个附属关系，行宽乘行数的估算可能低得离谱。
怎么用每天的新增行数推算明年的容量？
用每天新增行数乘以实测的落盘行宽，得到每天多少字节，换成吉字节，再乘以保留周期。每天 2 000 000 行、行宽 256 字节，就是每天新增 512 000 000 字节——0.512 GB，一个月约 15.4 GB。再按你在现有数据上实测的索引占比往上加，然后过一个月拿实际增长回头校对，别只信第一次估算。
还没有评论，快来发表第一条！