直接用布尔字段名即可筛选，如where is_paid等价于=true，但需注意null不匹配、运算符优先级及跨库兼容性。
WHERE 中直接用布尔字段名就能筛选
多数现代 SQL 数据库（PostgreSQL、SQL Server、GaussDB、SQLite）原生支持 BOOLEAN 类型，字段值为 TRUE / FALSE（或 1/0，取决于方言）。直接写字段名本身，就等价于 = TRUE，无需显式比较。
例如，假设表 orders 有布尔字段 is_paid：
SELECT * FROM orders WHERE is_paid;
这条语句会返回所有已支付的订单。同理，WHERE NOT is_paid 返回未支付的。
- MySQL 实际上没有严格布尔类型，
TINYINT(1)常被当布尔用，此时仍可直接写WHERE paid（非零即真），但语义上不如标准布尔清晰 - Oracle 没有
BOOLEAN类型（PL/SQL 有，但不能用于表列），通常用CHAR(1)存'Y'/'N'或NUMBER(1)存1/0，这时必须写WHERE status = 'Y'或WHERE flag = 1 - 字段为 NULL 时，
WHERE is_paid和WHERE NOT is_paid都不会包含该行 —— 因为NULL既不等于TRUE也不等于FALSE
AND/OR 组合时布尔字段要加括号防歧义
当布尔字段和其它条件混用，尤其含 OR 时，不加括号容易出错。因为 AND 优先级高于 OR，而布尔字段名本身是表达式，不是“开关”。
错误写法（本意是：已支付 OR 是 VIP 用户）：
WHERE is_paid OR user_type = 'vip' AND created_at > '2025-01-01'
实际执行逻辑是：is_paid OR (user_type = 'vip' AND created_at > '2025-01-01')，不是你想要的 (is_paid OR user_type = 'vip') AND created_at > '2025-01-01'。
- 只要涉及多个逻辑运算符，一律用括号明确分组，哪怕看起来“多余”
- 布尔字段参与组合时，建议统一写成
is_paid = TRUE或is_paid IS TRUE（PostgreSQL 支持后者），增强可读性与跨库兼容性 - 在 MySQL 中若用
TINYINT，避免写WHERE paid = 1 AND ... OR ...，先括起来再连AND
NULL 布尔字段必须显式处理
布尔字段允许为 NULL（比如支付状态未确认），但 WHERE is_paid 只匹配 TRUE，WHERE NOT is_paid 只匹配 FALSE，两者都跳过 NULL 行。
如果你需要把 NULL 当作某种业务含义（如“待确认”），就得显式判断：
WHERE is_paid IS TRUE OR is_paid IS NULL
或者更常见的三值逻辑场景：
- 查“已确定状态”的记录：
WHERE is_paid IS NOT NULL - 查“未支付或状态未知”：
WHERE is_paid = FALSE OR is_paid IS NULL - 不要写
WHERE is_paid != TRUE—— 这会漏掉NULL，且在某些数据库中对NULL比较结果为UNKNOWN，整行被过滤
WHERE 中对布尔字段用函数可能破坏索引
虽然可以写 WHERE COALESCE(is_paid, FALSE) = TRUE 或 WHERE CASE WHEN is_paid THEN 1 ELSE 0 END = 1，但这类写法会让数据库无法使用 is_paid 字段上的索引。
- 索引最有效的方式是裸字段 + 简单比较，如
WHERE is_paid = TRUE或WHERE is_paid - 如果业务要求把
NULL视为FALSE，建议在应用层或视图里做转换，而不是在查询 WHERE 中用函数包裹 - MySQL 中若字段是
TINYINT，WHERE paid > 0同样无法走索引，应改用WHERE paid = 1
布尔字段筛选看着简单，真正踩坑的地方全在隐式转换、NULL 处理和运算符优先级上 —— 尤其当你从一个数据库迁移到另一个，或多人协作维护同一套 SQL 时，这些细节最容易被忽略。
