卧槽!我一个 SQL 老 Boy 竟然栽在 Not IN 上
共 2085字,需浏览 5分钟
·
2021-02-13 21:04
点击蓝色“有关SQL”关注我哟
加个“星标”,天天与10000人一起快乐成长
图 | Lenis
是的,大年三十,我踩中一个 Bug.
平时风平浪静,今天给我找茬。这一天是什么日子?
全中国14亿人,都在等着这一天。父亲大人,母亲大人,老婆大人,满堂老少齐集一屋,都在等着我发红包,连邻居家牙没长齐的娃儿,都在门口笑着,等我的糖吃。
现在居然出现了一个Bug!
箭矢般的归心,嗷嗷叫的告警,就像 2 个大巴掌,左手一记勾拳,右手一记销魂掌。打得我就像紫霞仙子与牛魔王飞进了肚子,表面冷静无比,肚里翻江倒海。
按照往年的规律,年前最后一天不发代码。不做事,哪来错。以这样的物理措施,保障了新年的祥和,一年又一年。
但今年特殊,原地过年,想着年前把事做完整。结果上午贪心小朋友找我聊聊天,洗了个脑,不自觉的又加了几百行代码。
可,偏偏,心里怕啥,就来啥。下午就爆Bug.
好了,不给自己的错误,找借口。这个 SQL Bug 其实也不高深。举个简单的例子,就像下面这样:
SELECT *
FROM dbo.Products
WHERE Brand NOT IN (
SELECT Brand
FROM dbo.Products
WHERE NAME = 'Transformer'
)
这段 SQL 的目的,是从玩具产品中,查找不是 Transformer 品牌商的玩具。
本来是自信满满,写完提交,毫无悬念。但 QA 硬生生打回来了。
附上的评语,口气异常轻蔑:
你居然让我找到如此简单的 bug,毫无成就感
嗯,好吧。我承认!栽了……
表面上看着一点错没有,逻辑清晰,语法正确通顺,那为什么会错了呢?
原因是这样的:
SELECT Brand
FROM dbo.Products
WHERE NAME LIKE 'Transformer%'
在子查询中,如果不做 Brand 的约束,它有机会是 NULL 值。子查询返回 NULL 值,则无果。
以我做了3年多老测试的角度看,QA绝不能发现这么奇怪的Bug. 于是我好奇打听,他们怎么测的,才发现,原来他们有神器。
这,就是 SonarQube. 本文真正的主角。
之前我也写过,要注意对 SQL 运行的“事后”做监控,提高数据库运行“三高”:高可用,高稳定,高性能。
但,没有涉及到 SQL “事前”审核。经某知友(知乎网友)提醒,SQL 审核最好做在部署代码前。
这款 SonarQube 代码审核平台,正好可以满足需求。它支持 T-SQL, PL/SQL 等常用 SQL 方言。当然,其他近 30 种编程语言,Java,C#, Python, C/C++等,都是支持的。
SonarQube 真正折服我的,是全自动代码测试。它能找到隐藏的Bug,安全漏洞,测试覆盖率,怪味道代码,还有代码复用场景,甚至能精确到某几个存储过程的代码行。
如果有这样的自动化查错机器,你还怕别人说你的代码烂么:
我查了下,微信读书上居然没有一本完整的书来讲它。很可惜。但有两本书,讲到了 SonarQube 平台,他们分别是《Jenkins 2权威指南》和《Jenkins 2.x实践指南》
作为持续集成必知的组件,我觉得这部分知识,不可或缺。
像上面这种 bug 要由人工查,很容易漏掉!
等等,今天不是 2月12号吗,农历大年初一。
你要问我,大年初一为什么还在发技术文,那我就来说点花絮。权当给大家伙儿新年一点乐子。
本来前一周已经在写一篇大数据治理长文,参考了很多论文,博客还有书籍。透露下内容也没关系,毕竟咱是小台,不怕抄袭。但,写着写着,内容突然写海了,失控了。我的天,我完全不知道该怎么刹住闸。
但这个时候,偏偏冲进来这么个有趣的bug. 我想大部分读者会踩到这个坑,所以我就先写这篇 Not IN.
但,我得自己搭环境啊,没有亲自实现过的东西,我从来都不乱讲的。
于是模拟公司的一整套开发流程,从 JIRA, Bitbucket, 一路拐到 Jenkins, SonarQube, Github, 试了 n 多配置环境,云上,本地,最后好不容易凑到一块儿,发现 SonarQube 支持 SQL 审查,需要 GPL License.
完了!
缺了那种在自己的计算机实验室打造出来的环境,怎么着,都差点意思。但是呢,文章一路记录下来,总不能不发吧。
哎,硬着头发,咬着牙,发吧。
朋友们,《有关SQL》还活着。2021年,我们齐头并进,大步子迈向人生巅峰!
嗯,大过年的,谁家不喝点鸡汤啊
往期精彩: