为什么SQL Server中nvarchar比decimal占用更少存储空间？

你对两种类型单位空间占用的常规判断是正确的，出现总占用翻倍的现象是由数据库表结构变更的底层机制和存储布局差异导致的，具体原因如下：

• 类型存储逻辑的认知补全
  常规计算下，nvarchar(12)存储12位纯数字时，每个Unicode字符占2字节，总占用为24字节（不含变长列的2字节长度标记）；decimal(12,0)在主流数据库（SQL Server、MySQL、PostgreSQL）中定长占用9字节，理论上确实比nvarchar(12)占用更小。
• 旧数据页未回收是核心诱因
  几乎所有关系型数据库执行ALTER TABLE修改列类型时，都采用"拷贝写"的变更逻辑：不会直接覆盖原有旧格式的数据页，而是将转换后的新格式数据写入新分配的数据页中，仅将旧数据页标记为可复用状态，不会立即释放对应的磁盘空间。如果变更后没有执行表重建操作，旧数据页的占用会和新数据页叠加，直接导致总存储空间接近翻倍，和你观测到的从9GB升至17GB的现象完全吻合。
• 定长类型的额外存储开销
  decimal(12,0)属于定长数据类型，nvarchar(12)属于变长数据类型。定长类型需要在行头预留固定偏移量指针，同时如果表设置了非100%的填充因子，定长列会按照填充因子规则预留空白存储空间，这部分额外开销也会小幅拉高新数据的总占用。
• 关联索引的同步变更开销
  如果该MSISDN列上建有普通索引、唯一索引或主键约束，修改列类型时数据库会自动重建所有关联索引，旧索引页同样不会立即回收，也会进一步推高总存储空间占用。

执行对应数据库的表空间整理/重建命令，即可回收旧数据页占用的空间，整理后的表总占用会低于变更前的9GB：

• SQL Server：执行 ALTER TABLE [你的表名] REBUILD
• MySQL：执行 OPTIMIZE TABLE [你的表名]
• PostgreSQL：执行 VACUUM FULL [你的表名]

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