SQL布尔字段优化需明确语义、统一类型、善用索引、规避隐式转换：MySQL用TINYINT(1)+CHECK，PostgreSQL优先BOOLEAN；联合索引将布尔列置前；ORM需显式映射NULL与0/1，避免逻辑误判。
SQL中布尔字段（如 BOOLEAN、TINYINT(1)、BIT(1) 等）看似简单，但实际使用中常因类型选择不当、索引失效、ORM映射偏差或NULL处理疏忽，导致查询变慢、存储浪费甚至逻辑错误。优化核心在于：**明确语义、统一类型、善用索引、规避隐式转换**。
选对底层类型，别被“BOOLEAN”字面意思带偏
PostgreSQL原生支持 BOOLEAN 类型，语义清晰且优化良好；但MySQL其实没有真正的布尔类型——BOOLEAN 只是 TINYINT(1) 的别名，存储仍是整数（0/1），且允许插入2、-1等非法值；SQL Server的 BIT 虽紧凑，但不支持直接比较字符串（如 WHERE is_active = 'true' 会触发隐式转换）。
- MySQL项目中，显式用
TINYINT(1)并加CHECK (col IN (0,1))约束（8.0.16+），避免非法值入库 - PostgreSQL优先用
BOOLEAN，它支持TRUE/FALSE/NULL三值逻辑，且索引和查询计划更优 - 避免用
VARCHAR存 “yes/no”、“Y/N” —— 字符比较开销大，无法利用位运算，也难做统计聚合
索引不是加了就有效：注意谓词写法与NULL影响
布尔字段基数低（通常只有0/1/NULL），单独建B-tree索引往往无效——优化器大概率放弃使用。但结合高频过滤条件或用于排序分页时，仍可优化。
- 高频查询如
WHERE is_deleted = 0 AND created_at > '2024-01-01'，建议建联合索引：(is_deleted, created_at)，把布尔列放前面（因等值查询优先） - 避免写
WHERE is_active != 0或WHERE is_active <> FALSE，部分数据库无法走索引；统一用= TRUE/= FALSE - 若字段允许NULL（如“未确认”状态），而业务只需查“已启用”，记得写
WHERE is_enabled = TRUE，而非WHERE is_enabled（后者在某些方言中不标准，且可能漏掉NULL安全逻辑）
ORM映射要显式，别让框架自动“脑补”
MyBatis、Hibernate、Sequelize等常将布尔字段映射为Java的 Boolean 或Python的 bool，但数据库NULL可能转成null或False，造成空指针或逻辑误判。
- JPA中用
@Column(columnDefinition = "TINYINT(1)")显式指定，并配合@Convert自定义转换器，确保NULL→null，0→false，1→true - MyBatis XML里用
<if test="status != null">判断入参，而非依赖自动非空判断；动态SQL中避免AND status = #{status}直接拼NULL值 - 查询返回时，用
COALESCE(is_valid, FALSE)统一NULL语义（如“未知即无效”），再交由应用层处理
批量更新与默认值：小细节决定稳定性
布尔字段常用于开关控制，上线后频繁执行 UPDATE ... SET is_archived = 1，若无WHERE条件或索引，极易锁表或拖慢主库。
- 建表时设合理默认值：
is_deleted TINYINT(1) DEFAULT 0 NOT NULL，避免NULL干扰统计和索引区分度 - 批量归档时，务必带上时间范围或ID区间，例如
WHERE created_at ，并确保该组合有索引 - 考虑用无锁更新策略：先
SELECT id WHERE ... LIMIT 1000，再按ID分批UPDATE，降低单次事务压力
