这种 Non-Standard SQL 语法为什么还能活着
SELECT * FROM table1
WHERE '你好啊这是一句用户输入的查询语句' LIKE CONCAT('%', table1.column1, '%');

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

要结合业务场景来看得

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

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

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

长知识了

以前经常这么干。

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

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

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

怕不是某种敏感词检测？

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

学到了，哈哈😄

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

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

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

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

我们面试题有一道 MYSQL 的不能直接查出来结果 要进行一次变换的
这个大哥吭吃瘪肚的 20 分钟 自己写了一条长达 2KB 的 SQL 语句一个语句卡 4 秒 兴致勃勃地显摆来了。。。

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

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

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

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

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

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

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

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

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

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

性能也没损失呀

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

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

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

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

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

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

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

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

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

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

看到 like 就头疼

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

第一次知道还能这样用

涨姿势了

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

好多年不写 SQL ，没看懂😅

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

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

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

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

见识到了

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

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

感觉是 javaer 写的

这是查敏感词的吧

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

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

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

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

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

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