一个空格引发的“惨案“

缺乏、安全感 2022-10-14 00:48 138阅读 0赞

![cfbd1f1ed36c6cdb374bd5a37356b685.gif][]

“案情”回顾（情景模拟）：

小张是一名软件工程师，**工作兢兢业业、一丝不苟且精益求精，天性乐观的他每天愉快地做着增删改查的工作**，对于这些看似简单的CRUD，小张从来不会掉以轻心，他也笃定地坚信，自己向数据库里插入了什么数据，就能按条件把这些数据查询出来，毕竟，像MySQL这样的数据库，在全世界广为流行，大行其道，不可能不严谨。

然而，意想不到的悲剧还是发生了。。。

小张做的项目与语言处理有点关系，他们把处理的结果也就是字符串保存到在数据库里面，后续需要按照条件把这些数据查询出来，但需要对这些字符串做严格的区分，也就是说，如果查询A字符串，不能把B字符串查询出来，哪怕这两个字符串只有一个空格的差异。**对于这样的需求，小张觉得太天经地义了，根本无需多言，像MySQL这样的数据库天生就是干这样的事，所以当时就自信满满地拍着胸脯保证一定如期开发完成。**

随着工作的推进，小张猛然发现MySQL对于字符串的处理貌似不那么严谨，特别是对于空格字符，比如这两个字符串："Tom"和"Tom "，后面的字符串多了一个空格，然而，MySQL竟然把它们当成了相同的字符串。

我们来测试一下，看看具体的情况，先创建一个表：

CREATE TABLE `white_space`(
    `id` bigint(20)unsigned NOT NULL AUTO_INCREMENT,
    `name`varchar(128) NOT NULL DEFAULT '',
    PRIMARY KEY (`id`)
    ) ENGINE=InnoDBDEFAULT CHARSET=utf8

然后向表里插入两条数据：

INSERT INTO white_space(name) VALUES('Tom');
    INSERT INTO white_space(name) VALUES('Tom ');

注意，后面那条记录在最后多了一个空格。假设我们需要查询名字为Tom的记录（没有空格），SQL很简单：

SELECT * FROM white_space WHERE name = 'Tom';

然而，让小张大跌眼镜的是，上面的SQL竟然返回两条数据，也就是说，本来查找"Tom"（没有空格），却把"Tom "(有空格）也查询出来了：

![8fff7251e46d3e7be1fb130875248e77.png][]

这也太不严谨了，空格也是字符啊，为什么就生生的把它忽略了呢？这样的话，就满足不了项目的需求了，而且，小张还发现，不管后面有多少个空格，都会被忽略。我们再插入一条记录，名字是"Tom          "，后面一共有10个空格：

INSERT INTO white_space(name) VALUES('Tom          ');

再执行上面的查询语句，这时仍然还是返回了三条记录：

SELECT * FROM white_space WHERE name = 'Tom';

![ce27b3d2b571b7c9acfb81e8911f6c33.png][]

这简直太不可理喻了！感觉MySQL在这里完全无视空格的存在，但空格也是一个正正经经的字符啊，而且是一个非常常见的字符，咋就这么没有存在感呢。

当然，如果是前置空格，或者空格在中间是不会有这个问题的，比如数据库里保存的名字为" Tom"（最前面是一个空格），或者是"To m"，再按"Tom"（没有空格）去查询的话，是找不到这条记录的。

这就麻烦了，当初可是拍着胸脯保证可以如期完成的，现在碰到这样的问题，小张可真是有点慌了神，不知道该如何来解决，**而且这也是非常不可思议的事情，强悍如斯、威武如斯、名声震天响的MySQL竟然如此不严谨。**幸亏空格不会说话，要不然它还不得骂街啊，作为一个名正言顺的字符，就这样生生地被忽略了，这也太不尊重人了。

事已至此，小张只能去寻找问题的解决方法，抱怨是没有用的，经过一番辛勤探索和研究，小张终于找到了办法，也就是加上BINARY关键字，像下面这样：

SELECT * FROM white_space WHERE BINARY name = 'Tom';

这时候就会严格地进行匹配，只返回了一条记录，如果要查询包含空格的记录，比如"Tom "(有空格），就会只返回有空格的这条记录：

SELECT * FROM white_space WHERE BINARY name = 'Tom ';

完美！项目就是需要这样的效果，字符串要进行严格的匹配与区分，现在加上BINARY关键字就彻底地解决了这个问题，小张不禁有些沾沾自喜，他也觉得MySQL确实太强大了，不管什么样的问题貌似都有办法解决，怪不得它会风靡全世界，成为了万千企业的首选。

然而，小张还没有高兴没多久，新的问题就又出现了。BINARY是MySQL独有的关键字，Oracle数据库并不认识什么BINARY，而项目需要适配不同的数据库，主要包括MySQL和Oracle。公司有一套ORM来做这样的适配，开发人员只要按照标准来写SQL就可以了，但是，如果在SQL语句中加上BINARY，切换到Oracle数据库就会出错，这可怎么办？！当然，也可以判断数据库的类型，如果是MySQL数据库，就加上BINARY关键字，否则就不加（Oracle数据库可以严格区分后置空格），但是，这样的改动也太大了，因为MySQL中的语句都完全忽略了后置空格的存在，比如GROUP BY：

SELECT name,COUNT(*) FROM white_space GROUP BY name

返回这样的结果：

![4ddb0258d7d81b67de3e73dc54116983.png][]

也是完全忽略了后置空格，当然，加上BINARY也是可以解决问题的。

这样看来，只要涉及到需要严格区分字符串的地方，都需要做这样的改动，而这样的字段还有好几个，改动实在太大了！

事到如今，小张依然还没有找到完善的解决方案，开发的工期也一拖再拖，可以说是一桩不折不扣的“惨案”了。

往期推荐

[进百度了！][Link 1]

[吐血总结 | Java并发编程 72 变][_ Java_ 72]

[121道分布式面试题和答案，25K妥妥的][121_25K]

[美团面试：Java异常14连环炮，附答案][Java_14]

[【建议收藏】35个Spring Cloud 连环炮][35_Spring Cloud]

[283页！阿里P7大佬整理的后端知识库][283_P7]

[Java 集合30个连环炮，难不难试试便知！][Java _30]

·end·

—如果本文有帮助，请分享到朋友圈吧—

我们一起愉快的玩耍！

![f3c9076a1432b276b18d7a923a415ae7.gif][]

你点的每个赞，我都认真当成了喜欢

[cfbd1f1ed36c6cdb374bd5a37356b685.gif]: /images/20221014/c0cb44857a594349a6689d922a2aaf83.png
[8fff7251e46d3e7be1fb130875248e77.png]: /images/20221014/bc139d744b9d4949b22d6032550d8d51.png
[ce27b3d2b571b7c9acfb81e8911f6c33.png]: /images/20221014/838c8a33cc3a4788ac4fea436083f764.png
[4ddb0258d7d81b67de3e73dc54116983.png]: /images/20221014/4d65c3495ffb4a7b979e71a1232d9481.png
[Link 1]: http://mp.weixin.qq.com/s?__biz=MzU4MDM3MDgyMA%3D%3D&chksm=fd556055ca22e943bed2b2095f2fd04e0e7799be8f80836d80eb3a75d2ecb57d41ab848620ba&idx=2&mid=2247502014&scene=21&sn=56440dec02f050fc9303dfe2623a8676#wechat_redirect
[_ Java_ 72]: http://mp.weixin.qq.com/s?__biz=MzU4MDM3MDgyMA%3D%3D&chksm=fd5560abca22e9bddb868f6b6f2b89771df117cef9878e5ab231c31276c152f2bb8dee1ee188&idx=1&mid=2247501888&scene=21&sn=2a5889708d86ccbd0fbeba48037cca67#wechat_redirect
[121_25K]: http://mp.weixin.qq.com/s?__biz=MzU4MDM3MDgyMA%3D%3D&chksm=fd556035ca22e923a421efcfe1d27de7af8b8728567ed3aef5cd63dd92d0d0bd85bbf1dc82ad&idx=2&mid=2247502046&scene=21&sn=bc1a2e872e06b29ff59d319ae09b62b9#wechat_redirect
[Java_14]: http://mp.weixin.qq.com/s?__biz=MzU4MDM3MDgyMA%3D%3D&chksm=fd556f16ca22e60024281315631b8716607d62d2da54420f4719256812605e86fe4b639ad7cb&idx=1&mid=2247501821&scene=21&sn=4ed2f2da195db5344e2d7ad0ffa5c3d4#wechat_redirect
[35_Spring Cloud]: http://mp.weixin.qq.com/s?__biz=MzU4MDM3MDgyMA%3D%3D&chksm=fd556f0eca22e61875e72fee8f35e2afa3d899b0ce2ef87e654e9e495bbfc893c667908595d6&idx=1&mid=2247501797&scene=21&sn=f1726977a36cd950be7a847166b69248#wechat_redirect
[283_P7]: http://mp.weixin.qq.com/s?__biz=MzU4MDM3MDgyMA%3D%3D&chksm=fd556f4fca22e659c702ad5572ae631d286c73d86d63f79d7823640f3cdf86001e6593ae9d71&idx=2&mid=2247501732&scene=21&sn=025c2420aa93aed062cf678e023f517d#wechat_redirect
[Java _30]: http://mp.weixin.qq.com/s?__biz=MzU4MDM3MDgyMA%3D%3D&chksm=fd556f94ca22e682fb63a4b2975606311a45a44f95a9c9a3f4e9d5c0d31eb1bebb340344f5c9&idx=1&mid=2247501695&scene=21&sn=15e8484cd594fb8639a20ca808e719dd#wechat_redirect
[f3c9076a1432b276b18d7a923a415ae7.gif]: /images/20221014/4a70f5d099a04feeaf29f203548b19c5.png