欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页

一个空格引发的“*“

程序员文章站 2024-01-29 17:56:16
...

一个空格引发的“*“

“案情”回顾(情景模拟):

小张是一名软件工程师,工作兢兢业业、一丝不苟且精益求精,天性乐观的他每天愉快地做着增删改查的工作,对于这些看似简单的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 "(有空格)也查询出来了:

一个空格引发的“*“

 

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

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

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

SELECT * FROM white_space WHERE name = 'Tom';

一个空格引发的“*“

 

这简直太不可理喻了!感觉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

返回这样的结果:

一个空格引发的“*“

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

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

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

亲爱的读者朋友,你有什么好的解决方案吗?欢迎后台留言讨论。

一个空格引发的“*“

1. 全栈架构之打包推荐【建议收藏,常读】

2. 探讨确保消息消费幂等性的几种方式

3. 分布式系统中Session共享的常用方案

4Java语言“坑爹”排行榜TOP 10

5. 我是一个Java类(附带精彩吐槽)

6. mysql索引失效,差点我的工作凉了

7. 既生synchronized,何生volatile?

8. 微服务一直火,为什么服务化要搞懂?

9. MySQL的COUNT语句,不简单!

10. 漫画:HashSet和TreeSet实现与原理

一个空格引发的“*“

一个空格引发的“*“

扫码二维码关注我

·end·

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

我们一起愉快的玩耍!

一个空格引发的“*“

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