将INT列改为MEDIUMINT，1000万行带B树索引可节省多少空间？

嘿，这个问题问得特别实际——优化数据类型确实是数据库性能调优里性价比超高的操作，你的方向完全没错：把数据体积压得越小，就越容易塞进内存，减少磁盘IO请求，性能提升会很直观。

咱们一步步拆解着算，逻辑很清晰：

1. 表数据本身的节省空间 #

INT占4字节，MEDIUMINT占3字节，单条记录在这个列上能省 1字节。
你有10,000,000行数据，所以表数据部分的总节省是：

10,000,000 × 1字节 = 10,000,000字节 ≈ 9.54 MB

（换算说明：1MB = 1024×1024 = 1,048,576字节，用10^7除以这个数就能得到近似的MB值）

2. B-Tree索引的节省空间 #

这部分很容易被忽略，但其实占比不小。B-Tree索引的叶子节点和非叶子节点都会存储这个列的键值，所以每个索引条目里的键值也会从4字节压缩到3字节，每条索引条目同样省1字节。

针对你的场景：

• 叶子节点的条目数和表的行数完全一致（10,000,000条），这是索引体积的核心部分；
• 非叶子节点的条目数相对极少（比如假设每个索引节点能存1000个键，非叶子节点总共也就1万条左右），和1000万的量级比可以忽略不计。

所以索引部分的总节省也近似是：

10,000,000 × 1字节 ≈ 9.54 MB

总节省量 #

把表数据和索引的节省加起来，总共能节省：

9.54 MB + 9.54 MB ≈ 19.08 MB

这里有个关键场景要提：如果这个列是主键，那所有二级索引都会包含主键值，这时候你还会额外节省所有二级索引里主键部分的空间——比如你有3个二级索引，那总节省就会变成 9.54MB（表数据） + 9.54MB（主键索引） + 3×9.54MB（二级索引），这个节省量就会大很多。

另外再确认下你的思路：尽可能把数据塞进内存确实是提升数据库性能的核心手段之一，减少磁盘随机IO的效果比很多花里胡哨的优化都实在，继续往这个方向深挖准没错~

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