当 MySQL 表字段定义为 BIT(2) 时，直接插入整数 0 或 1 会导致二进制位填充异常（如显示为 3），根本原因在于 BIT 类型不接受常规十进制数值的字符串/数字直插，而需显式转换为二进制字面量或改用更合适的类型。
当 mysql 表字段定义为 `bit(2)` 时，直接插入整数 0 或 1 会导致二进制位填充异常（如显示为 3），根本原因在于 bit 类型不接受常规十进制数值的字符串/数字直插，而需显式转换为二进制字面量或改用更合适的类型。
在 PHP + MySQL 开发中，使用复选框（checkbox）控制布尔状态（如“是否本地”）是常见需求。但若后端将 $_POST['local'] 转换为 0 或 1 后，直接拼接进 SQL 插入 BIT(2) 字段，却意外得到值 3，这并非 PHP 逻辑错误，而是 MySQL BIT 类型的语义与使用方式被误解所致。
? 问题根源：BIT 类型不是“小整数容器”
MySQL 的 BIT(M) 是纯二进制位存储类型，它不自动将十进制数 0/1 解释为单比特值。当你执行：
INSERT INTO table (local) VALUES ('1');MySQL 会将字符串 '1'（ASCII 码 0x31）按字节解释，并填充至 M=2 位 —— 实际存储的是 0b11（即十进制 3），因为 '1' 的最低 2 位恰好是 11。同理，'0'（ASCII 0x30 → 0b00）看似安全，但行为不可靠且依赖字符编码，绝非正确用法。
✅ 正确解决方案（推荐两种）
方案一：改用 TINYINT(1)（最实用）
对于布尔/开关类字段，强烈建议弃用 BIT，改用 TINYINT(1)（语义清晰、ORM 兼容性好、查询直观）：
立即学习“PHP免费学习笔记（深入）”；
ALTER TABLE table MODIFY COLUMN local TINYINT(1) NOT NULL DEFAULT 0;
PHP 保持原有逻辑即可：
$local = isset($_POST['local']) ? 1 : 0;
// 使用预处理语句（防注入！）
$stmt = $pdo->prepare("INSERT INTO table (local) VALUES (?)");
$stmt->execute([$local]);方案二：严格使用 BIT(1) + 二进制字面量（仅限必须用 BIT 场景）
若因历史或规范强制要求使用 BIT，则：
- 将列改为 BIT(1)（仅存 1 位，避免冗余位干扰）；
- 插入时必须用 b'0' / b'1' 二进制字面量：
$local = isset($_POST['local']) ? "b'1'" : "b'0'"; $stmt = $pdo->prepare("INSERT INTO table (local) VALUES ($local)"); $stmt->execute();⚠️ 注意：此方式无法参数化（? 占位符不支持 b'1' 字面量），必须拼接字符串 —— 务必确保输入已过滤（如仅允许 isset 判断，无用户可控内容）。
? 关键注意事项
- 永远不要对 BIT 字段使用字符串拼接插入十进制数字（如 '1'），这是导致 3 等异常值的直接原因；
- BIT 类型在 PHP 中读取时返回二进制字符串（需 ord() 或 unpack() 处理），增加开发复杂度；
- TINYINT(1) 在 MySQL 中虽常被视作布尔别名，但实际是整数类型，支持 WHERE local = 1 等自然查询，兼容所有主流 ORM（如 Laravel Eloquent、Doctrine）；
- 若已存在 BIT(2) 数据，修复需先导出数据，再 ALTER COLUMN 并重写插入逻辑。
总结：用 TINYINT(1) 替代 BIT(1) 是兼顾语义、性能与可维护性的最佳实践；若坚持使用 BIT，必须配合二进制字面量且严格限定位宽。切勿让“看起来像布尔”的字段类型，成为线上数据异常的隐患源头。
