核心内容摘要
DamoFD-0.5G与YOLOv5在密集人脸场景下的对比评测
关注我们,设为星标,每天7:30不见不散,每日java干货分享案发场景你的团队开发了一个短链接系统Short URL。
核心逻辑是生成 6 位随机字符作为 ID区分大小写Base62 编码以扩大 ID 容量。
灵异事件• 用户 A 生成了短链s.cn/AbCdEf跳转到 Google。
• 用户 B 生成了短链s.cn/abcdef跳转到 Baidu。
•结果当用户访问s.cn/abcdef时数据库竟然返回了用户 A 的 Google 链接原因MySQL 的默认字符集校对规则Collation通常是utf8mb4_general_ci或utf8mb4_0900_ai_ci。
注意后缀_ci(Case Insensitive)—— 意思是大小写不敏感。
在 MySQL 眼里A a是天经地义的真理。
核心原理从字符到字节在默认的_ci校对规则下MySQL 会将字符“归一化”后再比较。
而在BINARY操作符的作用下MySQL 会强制将字符串转换为二进制字节流然后进行逐字节比对。
•普通比较 ():A和a被视为同一个东西。
•BINARY 比较:A(Hex:
和a(Hex:
是完全不同的字节序列。
实战演练一字之差谬以千里场景一短链接 / 邀请码 (Case Sensitive Codes)这是最典型的场景。
邀请码MyCode和mycode必须代表两个不同的人。
Bug 写法SELECT * FROM invite_codes WHERE code MyCode; -- 结果可能把 mycode, MYCODE 都查出来了修正写法 (加照妖镜):SELECT * FROM invite_codes WHERE BINARY code MyCode; -- 结果只有 MyCode 能匹配mycode 滚粗场景二API Key / Token 校验背景你分发给客户的AppSecret通常是一串乱码比如k8Yt9z。
风险如果不加区分黑客如果猜到了K8YT9Z在默认配置下竟然也能通过校验这大大降低了暴力破解的难度。
修正写法:SELECT * FROM api_secrets WHERE app_id 1001 AND BINARY secret_key k8Yt9z;场景三数据清洗与去重 (Data Cleaning)背景历史遗留数据里因为早期的 Bug导致数据库里同时存在了User和user两个标签。
现在要合并去重。
如果你直接GROUP BY tag_nameMySQL 会把它们合成一组。
需求必须把大小写不同的标签区分开统计。
-- 强制按二进制分组 SELECT tag_name, COUNT(*) FROM tags GROUP BY BINARY tag_name;场景四隐形字符的“显形” (Trailing Spaces)冷知识在某些 MySQL 版本和校对规则下a和a (末尾有空格) 在比较时是相等的PAD SPACE 行为。
但加上BINARY后空格的字节0x20无处遁形。
SELECT a a ; -- 可能返回 1 (True) SELECT BINARY a a ; -- 必定返回 0 (False)
进阶永久解决方案 (Collation)BINARY操作符只是临时的“照妖镜”Ad-hoc 查询。
如果你的某个字段如invite_code天生就必须区分大小写那么在建表时就应该定好规矩而不是每次查询都加BINARY。
最佳实践使用_bin后缀的校对规则。
CREATE TABLE invite_codes ( id INT PRIMARY KEY, -- 指定 collation 为 utf8mb4_bin (Binary) code VARCHAR(
CHARACTER SET utf8mb4 COLLATE utf8mb4_bin, UNIQUE KEY idx_code (code) );效果
自动区分以后查询WHERE code ...自动区分大小写不需要加BINARY关键字。
唯一性约束生效你可以同时插入abc和ABC数据库认为是两条不同的记录不会报 Duplicate Key。
避坑指南索引失效危机这是使用BINARY操作符最大的代价。
问题如果你的列code是默认的_ci校对规则并且建了索引。
当你执行WHERE BINARY code ...时索引可能会失效原因索引树是按照“不区分大小写”的逻辑排序构建的。
当你要求“区分大小写”时MySQL 可能认为原本的索引树没法用了只能全表扫描来逐个比对字节。
解决如果你需要高性能的精确匹配请务必采用“进阶方案”直接修改列的 Collation 为_bin并重建索引。
5.
总结BINARY 操作符是 MySQL 给开发者留的一个“严谨模式”开关。
•什么时候用当业务逻辑依赖字符的精确匹配邀请码、Token、密码散列值时。
•注意什么别滥用小心索引失效。
长治久安之策是修改 Table Collation。
推荐阅读 点击标题可跳转50个Java代码示例全面掌握Lambda表达式与Stream API16 个 Java 代码“痛点”大改造“一般写法” VS “高级写法”终极对决看完代码质量飙升为什么高级 Java 开发工程师喜爱用策略模式精选Java代码片段覆盖10个常见编程场景的更优写法提升Java代码可靠性5个异常处理最佳实践为什么大佬的代码中几乎看不到 if-else因为他们都用这个...还在 Service 里疯狂注入其他 Service你早就该用 Spring 的事件机制了看完本文有收获请转发分享给更多人关注「java干货」加星标提升java技能❤️给个「推荐 」是最大的支持❤️.cls-1{fill:#001e36;}.cls-2{fill:#31a8ff;}.cls-1{fill:#001e36;}.cls-2{fill:#31a8ff;}