MySQL存储过程不支持BOOLEAN变量声明，必须用TINYINT(1)替代；赋值可用TRUE/FALSE常量，判断和WHERE条件须显式比较=0或=1；应用层需手动转换整数结果为布尔；BIT(1)因兼容性和可读性差不推荐日常使用。
MySQL 存储过程中不能直接声明 BOOLEAN 变量
MySQL 的 DECLARE 语句不支持 BOOLEAN 类型，哪怕你写 DECLARE is_valid BOOLEAN DEFAULT FALSE;，也会报错 ERROR 1064。这是因为 MySQL 解析器在变量声明阶段就拒绝该类型，和建表时的 BOOLEAN 自动转 TINYINT(1) 完全不是一回事。
正确做法是统一用 TINYINT(1) 声明逻辑变量：
-
DECLARE is_valid TINYINT(1) DEFAULT 0;（显式指定类型，避免歧义） - 赋值时可直接用
SET is_valid = 1;或SET is_valid = TRUE;（TRUE是常量，值为 1） - 判断时推荐写成
IF is_valid = 1 THEN ...，而非IF is_valid THEN ...—— 后者虽能运行，但一旦字段被意外存入 2、-5 等非 0/1 值，逻辑就失效了
WHERE 条件中对 TINYINT(1) 字段的布尔写法要小心
在存储过程的 SELECT 或 UPDATE 里，如果条件列是 TINYINT(1)，别依赖 MySQL 的“隐式真值转换”：
- ❌
WHERE is_active：看似简洁，但只要该字段值是非零（比如 2、99），也会被当作TRUE匹配，破坏布尔语义 - ✅
WHERE is_active = 1：明确只匹配逻辑上的“真”，安全可控 - ✅
WHERE is_active IN (0, 1)：适合做数据清洗或校验逻辑，防止脏数据干扰
尤其当该字段没加 CHECK 约束（MySQL 8.0.16+ 才支持）或应用层未做校验时，这种显式比较是唯一靠谱的方式。
从查询结果取布尔值时，PHP/Java 等语言需手动转换
MySQL 返回的永远是整数（0 或 1），不会自动变成语言原生的 boolean。这在存储过程调用后取结果时特别容易出错：
- PHP 中：
$row['is_deleted'] === 1才是 true，== true可能因类型松散导致误判 - Java JDBC 中：
rs.getInt("is_valid") == 1是安全写法；用rs.getBoolean("is_valid")虽然能返回boolean，但遇到NULL会返回false，掩盖空值问题 - 如果你在存储过程中用
SELECT is_valid INTO @out_flag FROM ...再传给上层，记得上层代码必须按整数处理，不能假设它已是布尔
别为了“省空间”改用 BIT(1)，它会让逻辑更难维护
虽然 BIT(1) 理论上只占 1 位，比 TINYINT(1)（1 字节）更省，但它在实际使用中带来一堆麻烦：
-
SELECT返回的是二进制字节串（如0x01），不是直观的0/1，调试困难 - 存储过程里无法直接用
= 1比较，得写成= b'1'或配合CONV()，可读性差 - ORM（如 MyBatis、Hibernate）普遍不友好，容易映射失败或静默转错
- 绝大多数业务场景下，单个字段省 7 位毫无意义；而维护成本上升是实打实的
真正需要极致压缩的批量布尔列（比如百万级用户的状态标记），才值得考虑 BIT + 位运算，日常逻辑判断请老实用 TINYINT(1)。
