MySQL无原生布尔类型，TINYINT(1)仅为别名，可视化工具的布尔显示是客户端映射；DBeaver需启用booleanTreatAsBit，phpMyAdmin依赖ColumnTypes配置与注释；应用层须显式转换、校验并加CHECK约束。
MySQL 中 TINYINT(1) 被当布尔显示，其实是假象
mysql 本身没有原生布尔类型，boolean 和 bool 只是 tinyint(1) 的别名，底层存的还是整数。可视化工具（如 phpmyadmin、dbeaver、navicat）看到 tinyint(1) 就自动渲染成勾选框或开关，但这不是数据库行为，只是客户端“自作主张”的映射。
真正起作用的是字段定义 + 工具配置，不是数据类型本身。
-
TINYINT(1)存 0/1 没问题，但也能存 -128~127；如果业务逻辑没校验，可能混入非法值 - 某些 ORM（如 Laravel Eloquent）会把
TINYINT(1)自动转成 PHP 布尔，但 Django 默认不这样，行为不统一 - 用
BIT(1)或ENUM('0','1')并不能改善可视化表现，多数工具只认TINYINT(1)这个“约定俗成”
让 DBeaver 正确显示 TINYINT(1) 为布尔控件
DBeaver 默认不会把 TINYINT(1) 当布尔渲染，需要手动开启“布尔列识别”。它不依赖字段名（比如是否叫 is_active），只看类型和长度。
- 打开 Database > Driver Properties，找到
booleanTreatAsBit，设为true - 或者在连接配置的 Connection settings > Initialization 里加初始化语句：
SET sql_mode = 'STRICT_TRANS_TABLES';（辅助校验，非必需） - 重启连接后，查询结果中该列会出现复选框；编辑时点一下就切换 0/1，保存即生效
- 注意：如果表里已有
TINYINT(2)或TINYINT（无括号），DBeaver 不识别——必须严格是TINYINT(1)
phpMyAdmin 里为什么有时显示数字、有时显示开关？
phpMyAdmin 的行为取决于两个配置组合：$cfg['ColumnTypes'] 和字段注释（COMMENT）。它不单看类型，还看“上下文暗示”。
- 确保字段定义带
COMMENT 'Boolean flag'或类似文字，phpMyAdmin 会优先按注释判断 - 检查配置文件中是否有：
$cfg['ColumnTypes'] = ['tinyint' => 'boolean'];—— 这行必须存在且未被注释 - 如果字段允许
NULL，phpMyAdmin 会显示三态（空/✓/✗），对应NULL/1/0；若设为NOT NULL DEFAULT 0，就只有两态 - 常见坑：升级 phpMyAdmin 后配置重置，
ColumnTypes又变回默认空数组，开关消失
应用层怎么避免把 TINYINT(1) 当真布尔用出错？
数据库不保证布尔语义，所有“真假”逻辑必须在代码里做显式转换和校验，不能依赖类型或可视化界面的显示。
- 读取时统一转布尔：
boolval($row['is_deleted'])（PHP）、bool(row.is_active)（Python），别直接if ($row['status'])—— 因为 2 也是真值 - 写入前强制归一化：
intval($isActive)或(int) $flag，防止传入字符串"true"导致存成 0（弱类型转换陷阱） - 建表时加
CHECK (status IN (0, 1))（MySQL 8.0.16+），从数据库层堵住非法值，比靠应用层更可靠 - 如果用 Laravel，记得在 Model 里声明
protected $casts = ['is_published' => 'boolean'];，否则 Eloquent 可能返回整数
最麻烦的不是怎么配界面，而是团队里有人往 TINYINT(1) 插了个 2 还说“反正界面显示是对的”。类型只是约定，约束得靠 CHECK、cast 和测试覆盖。
