BIT(1)不是ORM友好的假布尔，而是真位存储，需配合位运算和显式转换；插入必须用b'1'或CAST，不可直接写1或'1'；查询需CAST或BIN转换才能显示0/1；WHERE应写(flag & 1) = 1而非flag = 1；单字段场景推荐TINYINT(1)更稳妥。
BIG(1) 能存布尔值，但直接当 BOOLEAN 用会出问题——它不是 ORM 友好的“假布尔”，而是真·位存储，必须配合位操作和显式转换才可用。
BIT(1) 插入数据时为什么常报错或存成 0？
MySQL 的 BIT 类型不接受裸数字（如 1 或 0）直接插入，也不接受字符串 '1'。它只认二进制字面量或带类型转换的值。
- 错误写法：
INSERT INTO t (flag) VALUES (1)→ 可能被静默转成0b0或报Truncated incorrect INTEGER value - 正确写法（推荐）：
INSERT INTO t (flag) VALUES (b'1')（b'0'同理） - 也可用转换：
INSERT INTO t (flag) VALUES (CAST(1 AS BINARY))，但不如b''直观 - 注意：如果字段定义为
NOT NULL却没给值，MySQL 5.7+ 默认拒绝插入；8.0+ 可能补默认0b0，行为不一致
查询 BIT(1) 字段时为什么 SELECT 看不到 0/1？
因为 BIT 返回的是二进制字节流，不是整数。客户端（包括 MySQL CLI、phpMyAdmin、大部分 ORM）拿到的是不可见字符或空字符串，不是你想要的逻辑值。
- 错误写法：
SELECT flag FROM t→ 结果可能是空、乱码或b'\x01'这类原始字节 - 正确显示方式：
SELECT CAST(flag AS UNSIGNED) AS flag FROM t→ 输出0或1 - 或用
SELECT BIN(flag) AS flag FROM t→ 输出'0'或'1'（字符串） - ORM 场景下（如 SQLAlchemy），需在模型字段上加自定义 getter，或用
cast(... as unsigned)包裹查询
WHERE 条件里怎么安全判断 BIT(1) 是否为真？
别用 WHERE flag = 1 —— 表面可行，实则依赖隐式转换，且在联合索引或函数索引场景下可能失效。
- 推荐写法：
WHERE (flag & 1) = 1，明确表达“检查最低位是否置位” - 等价但更清晰：
WHERE flag != b'0'（前提是字段非 NULL） - 避免
WHERE flag这种布尔上下文写法：MySQL 允许，但语义模糊，部分客户端解析异常 - 如果字段允许 NULL，
WHERE (flag & 1) = 1自动过滤 NULL；而WHERE flag会把 NULL 当 false，需额外处理
BIT(1) 和 TINYINT(1) UNSIGNED 到底该选哪个？
关键不在“省那 7 位空间”，而在整个技术链路是否愿意为 BIT 配套改造。
- 选
BIT(1)当且仅当你：需要极致紧凑（亿级表）、后续要扩展为多标志位（比如从BIT(1)升级到BIT(8)）、团队熟悉位运算且接受调试成本 - 选
TINYINT(1) UNSIGNED更常见：ORM 原生支持、日志/监控/BI 工具直接识别、WHERE active = 1直观、迁移和排查零门槛 - 别踩坑：
BOOLEAN是TINYINT(1)别名，不是独立类型；BIT没有别名，不能写BOOL替代
BIT 的真正价值不在单个开关，而在位组合。单独用 BIT(1) 很容易变成“为了用而用”，最后发现连 WHERE 都不敢直写，得全靠函数包装——这时候，它就只是个麻烦的 TINYINT。
