不能直接在字段属性选“binary”，因为它是BINARY数据类型别名，会将字段改为VARBINARY，丢失字符语义；正确做法是在Collation下拉框中选择utf8mb4_bin等带_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 - 勾选
Save—— 此时 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 做校验——应始终用哈希+盐值方式处理
_bin 后缀的 collation 名，而不是界面上看起来像“二进制”的类型选项。 
