空格字符影响字符串字段的group分组吗？论技能重要技巧更重要

公司筹备敲钟上市，审计工作正在进行。我们小组的两位同学也参与了一部分数据分析工作。

 

先介绍一个用户表（t_soho）的关键字段：
user_name-varchar(32)-用户姓名
id_card-varchar(255)-身份证号码（密文存储）
create_time-datetime-注册时间

其中有一项数据统计是按身份证号来分组统计。

互为备份的两位同学各自编写sql语句，执行后发现双方结果存在差异。如下是双方的sql，其中的FUN_DECRYPTION是解密函数。差异是第一条语句执行出来的结果比第二条多了一些。

SELECT ... FROM t_soho WHERE ... GROUP BY `FUN_DECRYPTION`(id_card);
SELECT ... FROM t_soho WHERE ... GROUP BY id_card;

可见，区别就在于一个对数据解密了，另一个是没有解密。

按说无论是明文数据还是密文数据，应该不影响计数吧。 那么，既然上面双方结果不一样，必然是哪里出现问题了。

两同学一番琢磨，认为可能是存在空格字符导致的，比如：11011519920120718X的密文与11011519920120718X （注意X后面有一个空格）的加密密文是不同的。系统接收数据如果未处理这种存在空格字符的情况，持久化t_soho表数据记录时就会出现两个不同的密文字段值。

分析归分析，认为归认为，是不是这么一回事，就需要验证其准确性。

一位同学很快证实，上面的差异是由空格字符所致！他是用这条sql证实的：select a,count(1) from (SELECT 'test' as a union all select 'test ') as table1 group by a

另一个同学稍后也证实了这个分析的正确性。他的验证方法是修改表的数据，即，在同一字段上存在两行相同的文本，其中一个后面敲上一个空格，然后求group by。

 

前面这种“不一样的方式”，就是技巧！

 

我们再看另一件事。

excel里有一张复杂的报告，需要统计每月注册用户在后面逐月的活跃度。

这个比较麻烦，一个sql出来所有数据比较费劲。我们的一个小伙伴废了九牛二虎之力，花了一个小时，终于完成。他的实现步骤是，写出来sql后，将执行结果复制到excel里，然后行转列，挨个儿粘贴到每月的单元格里；这一行结束后，继续修改sql中的月份，按同样的操作方式来完成下月的数据行，直到完成所有月份的数据行。而后来在check时，发现他的sql有问题，前功尽弃，小伙不禁长吁短叹。

用一个通俗的例子，比如现在正值疫情期间，我们从菜市场买回来的蔬菜水果，要消毒存放。一种方式是一样一样的消毒和存放，再一种方式是先统一消毒，然后统一存放。我们建议是利用后者这种方式。

上面这个案例中，我们使用excel的行转列属于技能；而批量操作的方式，则是技巧，省去了mysql客户端和excel来回切换操作所花费的时间。

 

技能固然重要，如果再掌握一定的技巧，岂不是锦上添花如虎添翼！

 

我在写作过程中，老母亲收拾家务，递来一片金黄的薄脆饼干，唠叨了一句“买东西送的三小袋饼干，这饼干还挺好吃！”我不自觉听到，然后看了一下包装，叫岩烧芝士脆，“芝士”就是力量。母亲喜欢吃这个饼干，那赶紧安排去！