MySQL的BIT类型不适合存单个布尔值，因其返回二进制流、ORM支持差、调试困难；仅适合多状态打包存储，如权限掩码、协议标志位，需配合位运算函数使用。
MySQL 的 BIT 类型不适合存常规布尔值（比如 is_deleted），但特别适合存多个紧密关联的开关位，例如权限掩码、状态组合、协议标志位。
为什么不能直接当布尔字段用
MySQL 的 BIT(1) 看似是“布尔”，但实际行为和 TINYINT(1) 或 BOOLEAN（本质是别名）完全不同：
-
SELECT查询返回的是二进制字节流，不是 0/1 数字 —— 直接看会是乱码或空值，必须显式用bin()或cast(col as unsigned)转换才能读取 - 应用层 ORM（如 SQLAlchemy、MyBatis、Laravel Eloquent）普遍不原生识别
BIT，容易映射失败或自动转成字符串"b'1'"这类不可靠格式 - JSON 输出、日志打印、调试时几乎无法直观判断值，排查成本高
- 索引效率与
TINYINT相当，但写法更晦涩，无实际性能优势
真正适合的场景：多状态打包存储
当你有一组逻辑上强绑定、总数固定、互斥或可叠加的二元状态时，BIT 才发挥价值。典型例子：
- 用户权限位：
BIT(8)存 8 个功能开关（查看/编辑/删除/导出/审核/通知/分享/归档），用位运算快速查/设：SELECT ... WHERE (permissions & 4) = 4表示“有删除权限” - 设备通信协议状态字：
BIT(16)对应硬件寄存器定义，每位代表一个传感器就绪、校准完成、低电警告等 - 订单处理阶段标记：
BIT(6)分别表示已支付、已发货、已签收、已开票、已结算、已归档，支持原子性多状态更新
这类用法依赖位操作函数：&（AND）、|（OR）、~（NOT）、<<（左移），而非普通比较。
插入与查询必须带显式转换
不转换就等于没存对。常见错误包括直接 INSERT INTO t VALUES (1) 到 BIT(1) 字段（可能被截断或报错），或 SELECT flag FROM t 看不到有效值。
- 插入：用
0b00000101字面量，或b'00000101'，或CAST(5 AS BINARY) - 查询显示：必须套一层
bin(flag)（输出'101'）或CAST(flag AS UNSIGNED)（输出5） - 条件判断：避免
WHERE flag = 1，改用WHERE (flag & 1) = 1（检查最低位）
漏掉任一环节，数据就“存在但不可用”。
替代方案对比：什么时候该放弃 BIT
如果只是单个布尔开关，或者状态之间不共享位上下文，立刻换掉：
- 单状态字段 → 用
TINYINT(1) UNSIGNED DEFAULT 0，语义清晰、ORM 友好、调试直观 - 少量枚举状态（≤ 20 个）→ 用
TINYINT+ 注释说明含义，比位运算更易维护 - 需要频繁按某个“位”单独建索引 →
BIT不支持函数索引（如INDEX((flag & 4))在 MySQL 8.0.13+ 才支持，且非标准），不如拆成独立TINYINT字段
BIT 的价值只在「你明确需要把 N 个 0/1 压进一个字段，并用位运算批量操作」这个狭窄前提下成立。超出这个边界，它就是技术负债。
