是不是我孤陋寡闻了，会有人真的在 MySql 里运行这样的查询吗？

[unidotnet]

这种 Non-Standard SQL 语法为什么还能活着

SELECT * FROM table1 
WHERE '你好啊这是一句用户输入的查询语句' LIKE CONCAT('%', table1.column1, '%');

当然不考虑 performance ，它是可以的，但是如果数据量大，就 GG 了吧？

[tomatocici2333]

要结合业务场景来看得

[movelf]

看场景，大部分情况下不会

[root71370]

神奇，还可以这么玩吗，这什么场景下用到？

[ntedshen]

拿 sql 去匹配关键字是这样的。。。
想换写法就得去代码里做，但是自己写还见不得有这么跑一下快。。。

[uibobo]

长知识了

[paranoiagu]

以前经常这么干。

[nzynzynzy]

我感觉很多 mysql 的论坛程序还是这样的

[kneo]

gg 了就是学到了。不 gg 就你多管闲事。

[billlee]

你就说需求有没有实现嘛。要不就加钱部署个全文搜索，要不就只能这么干了。

[CapNemo]

怕不是某种敏感词检测？

[zjsxwc]

学到了，这么写可以动态根据数据库预先设置的敏感词行，来检查用户输入的语句是否包含敏感词。

[quietDown]

学到了，哈哈😄

[weijancc]

长知识了.. 挺有趣的, 毕竟不是每个系统都是大数据互联网系统

[realpg]

当年在北京时候搞 PHP 写系统

招聘来过一个面试的 之前写 JAVA 商业软件的 公司倒了 自学 PHP 来面试看我们给的多就投

面试题都很简单 考察一些习惯和性能掌握

我们面试题有一道 MYSQL 的不能直接查出来结果 要进行一次变换的

这个大哥吭吃瘪肚的 20 分钟 自己写了一条长达 2KB 的 SQL 语句一个语句卡 4 秒 兴致勃勃地显摆来了。。。

[me1onsoda]

这不是很常见的做法？就为了这么点事儿你要再折腾一个 es ？

[bestmos]

评论区到底学到什么了？为什么我没看懂这个 SQL 特殊在哪

[mayli]

在数据量大之前，肯定有人可以重构的，但是现在一行就搞定了，先用着就行。

[jeesk]

过早优化是万恶之源——克努特优化原则 (Knuth's optimization principle)

当你发现有性能瓶颈的时候再优化也不迟。

[hvsy]

之前就用这种方式实现过一个小的简陋的敏感识别功能，敏感词的数量不多的情况下还挺凑合的

[liKeYunKeji]

从输入内容中提取关键词，标签，这个语句还是挺好用的

[Pastsong]

这个语句哪个部分是 Non-Standard SQL 了？

[cpstar]

等等，谁给我解释一下这个语句是要干啥？判断用户输入的那个查询语句是否包括 table1.column1 这个字符串？正经人不应该在语言层面 indexOf 或者正则匹配之类的？从哪开的脑洞回去数据库层面搞这个？

[jzphx]

我也孤陋寡闻了，concat 列 之后 like xxx 见过，没见过 xxx like concat 列

[qinrui]

性能也没损失呀

[ho121]

楼主都说了不考虑性能是没有问题的。
实际上很多场景确实不用考虑性能。

[harryWebb]

我之前还真经常这么写，但是不是用在系统上面。。。而是自己用来 navicat 面板的时候查特定的数据验证使用。。。。

[GoNewEra]

SELECT * FROM table1
WHERE LOCATE(column1, '你好啊这是一句用户输入的查询语句') > 0;

[VeryZero]

在复杂的业务和巨大的屎山下没有什么 sql 是不可能的

[Lockroach]

如果你将业务逻辑放到数据库来执行的话，是有可能这样写的

[foufoufm]

业务代码是有可能的，特别是这段 sql 是其中的一环，或者是中间集

[GBdG6clg2Jy17ua5]

这是什么神奇的写法，为啥是 like 字段，而不是字段 like 输入的？
1 ）如果是 table1.column1 like '%输入%'，我是经常这样写的。用户量摆在那里，没啥事。比如模糊匹配用户客户号，身份证号。
2 ）如果是'输入' like %table1.column1%,这语法能正确吗？

[lazyfighter]

看个屁场景， 公司有多 low ， 写出这种代码

[TomatoCLI]

@bestmos 大概是搜索用户输入的内容中是否包含表当中设置的关键词

[mmdsun]

这是用了 Mybatis 又不知道怎么传参数拼接吧。。。
'%输入%' mysql 现在有额外优化吗？

[abolast]

看到 like 就头疼

[mayday526]

多层级结构就用到，只有这样能查到 2/3/4/节点的所有祖先节点（节点 2/，节点 2/3/）：
SELECT * FROM department WHERE '2/3/4/' LIKE CONCAT(path,'%');

[jpyl0423]

第一次知道还能这样用

[cslive]

涨姿势了

[iyiluo]

这种写法我也第一次见，做过滤词我都是在程序端实现的，用 sql 不好迁移，词库一多容易炸掉

[julio867]

好多年不写 SQL ，没看懂😅

[wangtian2020]

大部分公司都不会遇到性能瓶颈。同时性能越差优化越简单，简单修改一下就能提高一个量级，也不会出来发帖的

[b821025551b]

@realpg 业务场景不同罢了，恐怕你没看过这玩意： https://zhuanlan.zhihu.com/p/18660206854

[adoal]

这不是 non-standard SQL 语法。SQL 里能用标量值的地方，往往也能用标量类型的结果集，就是相当于把结果集里的标量 for each 一遍而已。

[urlk]

MySQL JSON 功能用多了, 看这个也很正常

[kd9yYw2RyhQwAwzn]

见识到了

[KongLiu]

开始看到这不是挺正常的，一看才发现是 输入 like 字段

[yh7gdiaYW]

我觉得这对对后台和公司内部系统来说挺正常的，数据量不是特别大的时候，也不至于为了模糊匹配再去搞个搜索引擎

[pangzipp]

感觉是 javaer 写的

[unco020511]

这是查敏感词的吧

[yh7gdiaYW]

@cpstar 比如 table1.column1 的数据量很大并且有一定更新频率的时候，OP 举的这个写法比在代码里比较更优

[githmb]

MySql 连很多标准都不支持，为什么它支持的却不能用？

[Rickkkkkkk]

如果是用户输入，有注入的风险。

[irisdev]

如果这张表只有几十行几百行数据，这一列只有“习*”、“*党”等字符串，用户输入前端卡住最多输 50 字，也不会有什么性能问题吧

[youngwen]

@angryfish 如果需要检查用户的输入中，是否包含一些预设的敏感词，这种写法就比较合适，敏感词不多的时候，性能也不差

[IamUNICODE]

数据量大有数据量大的玩法吧，只能说

[zlowly]

table1 感觉就是个敏感词库吧，这 sql 哪里有问题了？你都说了“但是如果数据量大”，那么显然目前 table1 就是不大的，大概率以后也不会有多大。performance 的话，小表拉到内存里全表扫描，也是相当快的。

[zlowly]

补充一下，对比上面有人提出的用 LOCATE 之类的方法，LIKE CONCAT('%', table1.column1, '%');，有个小优势，其实这个 table1 表的 column1 里的存放的敏感词是可以用%_，例如可以是"CN%B"之类的，当然是比较简陋误杀率高。但敏感词嘛，杀错了就杀错了，大家还少见吗。

[changdy]

不是 ..等等... 我怎么有点晕..
Non-Standard SQL 听起来像是说方言问题 .但是下一步又说到了性能问题...
op 到底是对那部分问题有疑问?

另外....performance 为什么不直接说性能呢, 略微奇怪.

[Yanickkk]

规模不大的情况下可以这么用，当然也可以 load 到内存里面再搞，没什么区别。规模大了，就不能这么搞了，不如先聊聊多大体量

[sampeng]

一个表就几十万数据。。折腾他干啥呢？

[lxqxqxq]

@changdy #58 我也一脸懵逼

[dode]

这个查询有 SQL 注入漏洞吗

[zpf124]

楼主这个代码好怪啊...

但如果倒过来，

WHERE column1 LIKE CONCAT('%', '用户搜索', '%');

这种代码我反正是没少写.
反正我个菜鸡参与的项目又没有到 qps 百万的水平，以我们那微弱的数据量这种低效代码都可以在 100ms 以内完成了。

[Felldeadbird]

我没试过这样写查询。涨知识了。

[tangping]

涨知识了。

[GBdG6clg2Jy17ua5]

网友提示我这是敏感词库，我这才恍然大悟。这种场景，是相当合适啊。涨知识了。

[sir283]

程序跟人总得有一个能跑吧？