这是一个创建于 320 天前的主题，其中的信息可能已经有所发展或是发生改变。
这种 Non-Standard SQL 语法为什么还能活着
SELECT * FROM table1
WHERE '你好啊这是一句用户输入的查询语句' LIKE CONCAT('%', table1.column1, '%');
当然不考虑 performance ，它是可以的，但是如果数据量大，就 GG 了吧？
67 条回复 • 2025-03-05 09:55:35 +08:00
 |
1
tomatocici2333 2025 年 3 月 3 日
要结合业务场景来看得
|
 |
2
zhouxelf 2025 年 3 月 3 日
看场景，大部分情况下不会
|
 |
3
root71370 2025 年 3 月 3 日 via Android
神奇，还可以这么玩吗，这什么场景下用到？
|
 |
4
ntedshen 2025 年 3 月 3 日  4
拿 sql 去匹配关键字是这样的。。。
想换写法就得去代码里做，但是自己写还见不得有这么跑一下快。。。 |
 |
5
uibobo 2025 年 3 月 3 日
长知识了
|
 |
6
paranoiagu 2025 年 3 月 3 日 via Android
以前经常这么干。
|
 |
7
nzynzynzy 2025 年 3 月 3 日
我感觉很多 mysql 的论坛程序还是这样的
|
 |
8
kneo 2025 年 3 月 3 日 via Android 2
gg 了就是学到了。不 gg 就你多管闲事。
|
 |
9
billlee 2025 年 3 月 3 日 1
你就说需求有没有实现嘛。要不就加钱部署个全文搜索，要不就只能这么干了。
|
 |
10
CapNemo 2025 年 3 月 3 日
怕不是某种敏感词检测？
|
 |
11
zjsxwc 2025 年 3 月 3 日 via Android 1
学到了，这么写可以动态根据数据库预先设置的敏感词行，来检查用户输入的语句是否包含敏感词。
|
 |
12
quietDown 2025 年 3 月 3 日
学到了，哈哈😄
|
 |
13
weijancc 2025 年 3 月 3 日
长知识了.. 挺有趣的, 毕竟不是每个系统都是大数据互联网系统
|
 |
14
realpg PRO 当年在北京时候搞 PHP 写系统
招聘来过一个面试的 之前写 JAVA 商业软件的 公司倒了 自学 PHP 来面试看我们给的多就投 面试题都很简单 考察一些习惯和性能掌握 我们面试题有一道 MYSQL 的不能直接查出来结果 要进行一次变换的 这个大哥吭吃瘪肚的 20 分钟 自己写了一条长达 2KB 的 SQL 语句一个语句卡 4 秒 兴致勃勃地显摆来了。。。 |
 |
15
me1onsoda 2025 年 3 月 3 日
这不是很常见的做法？就为了这么点事儿你要再折腾一个 es ？
|
 |
16
bestmos 2025 年 3 月 4 日 1
评论区到底学到什么了？为什么我没看懂这个 SQL 特殊在哪
|
 |
17
mayli 2025 年 3 月 4 日
在数据量大之前，肯定有人可以重构的，但是现在一行就搞定了，先用着就行。
|
 |
18
jeesk 2025 年 3 月 4 日 via Android
过早优化是万恶之源——克努特优化原则 (Knuth's optimization principle)
当你发现有性能瓶颈的时候再优化也不迟。 |
 |
19
hvsy 2025 年 3 月 4 日 via iPhone
之前就用这种方式实现过一个小的简陋的敏感识别功能，敏感词的数量不多的情况下还挺凑合的
|
 |
20
liKeYunKeji 2025 年 3 月 4 日 via Android
从输入内容中提取关键词，标签，这个语句还是挺好用的
|
 |
21
Pastsong 2025 年 3 月 4 日
这个语句哪个部分是 Non-Standard SQL 了？
|
 |
22
cpstar 2025 年 3 月 4 日
等等，谁给我解释一下这个语句是要干啥？判断用户输入的那个查询语句是否包括 table1.column1 这个字符串？正经人不应该在语言层面 indexOf 或者正则匹配之类的？从哪开的脑洞回去数据库层面搞这个？
|
 |
23
jzphx 2025 年 3 月 4 日
我也孤陋寡闻了，concat 列 之后 like xxx 见过，没见过 xxx like concat 列
|
 |
24
qinrui 2025 年 3 月 4 日
性能也没损失呀
|
 |
25
ho121 2025 年 3 月 4 日 via Android
楼主都说了不考虑性能是没有问题的。
实际上很多场景确实不用考虑性能。 |
 |
26
harryWebb 2025 年 3 月 4 日
我之前还真经常这么写，但是不是用在系统上面。。。而是自己用来 navicat 面板的时候查特定的数据验证使用。。。。
|
 |
27
GoNewEra 2025 年 3 月 4 日 2
SELECT * FROM table1
WHERE LOCATE(column1, '你好啊这是一句用户输入的查询语句') > 0; |
 |
28
VeryZero 2025 年 3 月 4 日
在复杂的业务和巨大的屎山下没有什么 sql 是不可能的
|
 |
29
Lockroach 2025 年 3 月 4 日
如果你将业务逻辑放到数据库来执行的话，是有可能这样写的
|
 |
30
foufoufm 2025 年 3 月 4 日
业务代码是有可能的，特别是这段 sql 是其中的一环，或者是中间集
|
 |
31
GBdG6clg2Jy17ua5 2025 年 3 月 4 日 1
这是什么神奇的写法，为啥是 like 字段，而不是字段 like 输入的？
1 ）如果是 table1.column1 like '%输入%'，我是经常这样写的。用户量摆在那里，没啥事。比如模糊匹配用户客户号，身份证号。 2 ）如果是'输入' like %table1.column1%,这语法能正确吗？ |
 |
32
lazyfighter 2025 年 3 月 4 日
看个屁场景， 公司有多 low ， 写出这种代码
|
 |
33
cyrivlclth 2025 年 3 月 4 日
@bestmos 大概是搜索用户输入的内容中是否包含表当中设置的关键词
|
 |
34
mmdsun 2025 年 3 月 4 日
这是用了 Mybatis 又不知道怎么传参数拼接吧。。。
'%输入%' mysql 现在有额外优化吗？ |
 |
35
abolast 2025 年 3 月 4 日
看到 like 就头疼
|
 |
36
mayday526 2025 年 3 月 4 日
多层级结构就用到，只有这样能查到 2/3/4/节点的所有祖先节点（节点 2/，节点 2/3/）：
SELECT * FROM department WHERE '2/3/4/' LIKE CONCAT(path,'%'); |
 |
37
jpyl0423 2025 年 3 月 4 日
第一次知道还能这样用
 |
 |
38
cslive 2025 年 3 月 4 日
涨姿势了
|
 |
39
iyiluo 2025 年 3 月 4 日
这种写法我也第一次见，做过滤词我都是在程序端实现的，用 sql 不好迁移，词库一多容易炸掉
|
 |
40
julio867 2025 年 3 月 4 日
好多年不写 SQL ，没看懂😅
|
 |
41
wangtian2020 2025 年 3 月 4 日
大部分公司都不会遇到性能瓶颈。同时性能越差优化越简单，简单修改一下就能提高一个量级，也不会出来发帖的
|
 |
42
b821025551b 2025 年 3 月 4 日
@realpg 业务场景不同罢了，恐怕你没看过这玩意： https://zhuanlan.zhihu.com/p/18660206854
|
 |
43
adoal 2025 年 3 月 4 日 1
这不是 non-standard SQL 语法。SQL 里能用标量值的地方，往往也能用标量类型的结果集，就是相当于把结果集里的标量 for each 一遍而已。
|
 |
44
urlk 2025 年 3 月 4 日
MySQL JSON 功能用多了, 看这个也很正常
|
 |
45
kd9yYw2RyhQwAwzn 2025 年 3 月 4 日
见识到了
|
 |
46
KongLiu 2025 年 3 月 4 日
开始看到这不是挺正常的，一看才发现是 输入 like 字段
|
 |
47
yh7gdiaYW 2025 年 3 月 4 日
我觉得这对对后台和公司内部系统来说挺正常的，数据量不是特别大的时候，也不至于为了模糊匹配再去搞个搜索引擎
|
 |
48
pangzipp 2025 年 3 月 4 日
感觉是 javaer 写的
|
 |
49
unco020511 2025 年 3 月 4 日
这是查敏感词的吧
|
 |
51
githmb 2025 年 3 月 4 日
MySql 连很多标准都不支持，为什么它支持的却不能用？
|
 |
52
Rickkkkkkk 2025 年 3 月 4 日
如果是用户输入，有注入的风险。
|
 |
53
irisdev 2025 年 3 月 4 日
如果这张表只有几十行几百行数据，这一列只有“习*”、“*党”等字符串，用户输入前端卡住最多输 50 字，也不会有什么性能问题吧
|
 |
55
IamUNICODE 2025 年 3 月 4 日
数据量大有数据量大的玩法吧，只能说
|
 |
56
zlowly 2025 年 3 月 4 日
table1 感觉就是个敏感词库吧，这 sql 哪里有问题了？你都说了“但是如果数据量大”，那么显然目前 table1 就是不大的，大概率以后也不会有多大。performance 的话，小表拉到内存里全表扫描，也是相当快的。
|
|
57
zlowly 2025 年 3 月 4 日
补充一下，对比上面有人提出的用 LOCATE 之类的方法，LIKE CONCAT('%', table1.column1, '%');，有个小优势，其实这个 table1 表的 column1 里的存放的敏感词是可以用%_，例如可以是"CN%B"之类的，当然是比较简陋误杀率高。但敏感词嘛，杀错了就杀错了，大家还少见吗。
|
 |
58
changdy 2025 年 3 月 4 日
不是 ..等等... 我怎么有点晕..
Non-Standard SQL 听起来像是说方言问题 .但是下一步又说到了性能问题... op 到底是对那部分问题有疑问? 另外....performance 为什么不直接说性能呢, 略微奇怪. |
 |
59
Yanickkk 2025 年 3 月 4 日
 规模不大的情况下可以这么用，当然也可以 load 到内存里面再搞，没什么区别。规模大了，就不能这么搞了，不如先聊聊多大体量 |
 |
60
sampeng 2025 年 3 月 4 日
一个表就几十万数据。。折腾他干啥呢？
|
 |
62
dode 2025 年 3 月 4 日
这个查询有 SQL 注入漏洞吗
|
 |
63
zpf124 2025 年 3 月 4 日
楼主这个代码好怪啊...
但如果倒过来， WHERE column1 LIKE CONCAT('%', '用户搜索', '%'); 这种代码我反正是没少写. 反正我个菜鸡参与的项目又没有到 qps 百万的水平，以我们那微弱的数据量这种低效代码都可以在 100ms 以内完成了。 |
 |
64
Felldeadbird 2025 年 3 月 4 日
我没试过这样写查询。涨知识了。
|
 |
65
tangping 2025 年 3 月 4 日
涨知识了。
|
|
66
GBdG6clg2Jy17ua5 2025 年 3 月 5 日
网友提示我这是敏感词库，我这才恍然大悟。这种场景，是相当合适啊。涨知识了。
|
 |
67
sir283 2025 年 3 月 5 日 via Android
程序跟人总得有一个能跑吧？
|
Select Language