将布尔类型字段单独拆表存储是否可节省数据库存储空间？

绝大多数场景下，为了省banned列的那点存储空间单独拆表存封禁用户ID，是典型捡芝麻丢西瓜的坏设计，完全不推荐。

先算明白你以为的“存储浪费”到底有多少 #

• 就算按最占空间的实现算，常规数据库里布尔类型字段单条记录最多占1字节，99万条非封禁用户的banned列总占用空间是990000字节，换算下来不到0.95MB，连1MB都不到。现在不管是云存储还是本地服务器磁盘，1MB空间的成本基本可以忽略，为了这点成本动核心表结构完全是本末倒置。
• 真要抠这点存储空间，根本不用拆表：把banned列设为允许NULL的BIT(1)类型，未封禁用户存NULL（行存储里NULL值只占极短的标记位，比1字节的开销还小），封禁用户存1，比拆表省的空间多得多，还完全不影响原有查询逻辑。

单独拆表带来的隐形成本，比你省的那点空间高几个数量级 #

• 核心业务逻辑复杂度陡增：所有涉及用户权限判断的场景——用户登录、访问账户、发帖评论、发起交易——本来单查user表就能拿到封禁状态，现在要么写LEFT JOIN关联封禁表，要么分两次查库，不仅写代码麻烦，还非常容易漏判断：哪天写新功能忘了关联封禁表，直接放封禁用户进系统出线上事故，损失的钱够买几千万个1MB的存储。
• 数据一致性风险陡增：用户状态拆在两张表里存，封禁、解封操作必须同时操作两张表，但凡有一步操作失败（比如网络波动、代码漏写逻辑），就会出现“用户已解封但封禁表留了记录”“用户实际被封但封禁表没数据”的脏数据，后续排查问题要花几倍的精力。
• 查询性能反而下降：高QPS场景下，每次用户请求多一次JOIN或者多一次数据库查询的开销，攒起来的性能损耗，比扫描主表那1MB布尔字段的开销大太多，完全得不偿失。干开发这么多年，见过太多为了省几MB存储把表拆得七零八落，最后线上出事故赔了几万块的案例，这笔账怎么算都亏。

什么场景下单独建封禁表才是合理设计？ #

只有当你需要给封禁行为存大量附属信息的时候，单独拆表才划算：比如你不仅要记录用户是否被封，还要存封禁时间、封禁原因、操作的管理员ID、封禁时长、申诉记录、解封时间这些字段——这些字段99%的正常用户永远用不上，全塞在user主表里才是真的浪费空间，这时候单独建banned_user表，以用户ID为主键存所有封禁相关的完整信息才是合理方案，核心目的从来不是省那点布尔字段的空间，是避免大量无用字段挤占主表空间。

内容的提问来源于stack exchange，提问作者Robo-Hobo