phpMyAdmin字段字符序设为二进制

在 phpMyAdmin 中设置“二进制字符序”看似简单，但有一个常见误区很容易被忽略——许多用户在字段属性下拉菜单中看到 binary 就直接选择，殊不知这实际上是 MySQL 的 BINARY 数据类型别名。选择后字段类型会被改为 VARBINARY，原本存储的字符串语义全部丢失，变为纯粹的字节流，比较和排序不再按字符进行。

正确的做法是在 Collation 下拉框中选择一个带 _bin 后缀的排序规则，例如 utf8mb4_bin，同时保持字段类型仍为 VARCHAR 或 TEXT。这里的关键区别在于：前者改变了数据类型，后者只改变了比对规则，字段依然保留字符串属性。

为什么不能在“字段属性”中直接选择 binary？

在 phpMyAdmin 的“结构”页添加或编辑字段时，下拉菜单中的 binary 并非字符序（collation），而是 MySQL 的 binary 数据类型别名（等同于 VARBINARY）。选择它会导致字段类型被强制改为二进制串，丢失字符语义——例如原本想存储 utf-8 文本，结果变成无法按字符比较或排序的字节流。

正确设置二进制字符序的完整步骤

MySQL 中“二进制 collation”是指以字节为单位严格比对的排序规则，如 utf8mb4_bin 或 latin1_bin。它们与字段类型无关，只作用于字符串类型的值（VARCHAR、TEXT 等）：

• 进入表的结构页，找到目标字段，点击右侧的更改图标（铅笔）
• 在 Collation 下拉框中，选择带 _bin 后缀的选项，例如：utf8mb4_bin（推荐）、utf8_bin（已弃用）、latin1_bin
• 确保字段类型仍为 VARCHAR / TEXT 等字符串类型，不要误选 BINARY 或 VARBINARY
• 点击保存——此时 ALTER TABLE 语句实际执行的内容类似：

  ALTER TABLE `my_table` MODIFY `my_column` VARCHAR(255) COLLATE 'utf8mb4_bin';

常见错误现象与兼容性注意事项

设置错误的 collation 后，最典型的表现包括：明明内容相同却查询不到、ORDER BY 结果顺序异常、WHERE 条件区分大小写失效（或意外生效）：

• utf8mb4_general_ci 和 utf8mb4_unicode_ci 不区分大小写和重音；utf8mb4_bin 区分每一个字节，包括大小写、变音符号，甚至零宽空格
• 如果字段已有数据，修改 collation 通常不会报错，但后续查询行为会立即改变——建议先在测试环境验证逻辑是否符合预期
• PHP 中使用 mysqli 或 PDO 查询时无需额外设置；但若手动拼接 SQL 比较字符串（如 WHERE name = 'A' COLLATE utf8mb4_bin），该 collation 优先级高于字段默认设置
• 避免混用 collation：同一张表中多个字符串字段若 collation 不一致，JOIN 或 GROUP BY 可能触发隐式转换警告或性能下降

何时该使用 _bin 而非 _ci？

并非所有场景都需要二进制 collation。以下情况较为适用：

• 存储需要精确字节匹配的 token、哈希值、base64 编码串（如 api_token 字段）
• 用户注册时要求用户名“大小写敏感”，且不希望 和 A 被视为相同
• 调试字符问题：临时将 collation 改为 _bin 可快速判断是否因排序规则导致查询异常
• 注意：密码字段通常不应存储明文，更不依赖 collation 做校验——应始终使用哈希加盐的方式处理

修改 collation 属于 DDL 操作，会影响表元数据以及后续所有字符串操作行为。真正生效的是那个带 _bin 后缀的 collation 名称，而非界面上看似“二进制”的数据类型选项。