在MySQL表中搜索包含CSV数据的列是否存在输入值

我在MySQL中有一个表，比如ITEM，它存储的数据如下：

ID    FEATURES
--------------------
1     AB,CD,EF,XY
2     PQ,AC,A3,B3
3     AB,CDE
4     AB1,BC3
--------------------

select * from ITEM where MATCH_ANY(FEAURES, "AB,PQ") = 0

作为输入，我将得到一个CSV字符串，类似于“AB，PQ”。我想得到包含AB或PQ的记录。我意识到我们必须编写一个MySQL函数来实现这一点。因此，如果我们在MySQL中定义了一个神奇的函数MATCH_ANY来实现这一点，那么我只需执行一个SQL，如下所示：

ID    FEATURES
--------------------
1     AB,CD,EF,XY
2     PQ,AC,A3,B3
3     AB,CDE
4     AB1,BC3
--------------------

select * from ITEM where MATCH_ANY(FEAURES, "AB,PQ") = 0

上述查询将返回记录1、2和3

但是我在实现这个函数时遇到了各种各样的问题，因为我意识到MySQL不支持数组，也没有简单的方法根据分隔符分割字符串

重塑桌子是我最后的选择，因为它涉及很多问题

我可能还希望执行包含多个匹配函数的查询，例如：

select * from ITEM where MATCH_ANY(FEATURES, "AB,PQ") = 0 and MATCH_ANY(FEATURES, "CDE")

在上面的例子中，我们将得到一个记录（1，2，3）和（3）的交集，它将是3

非常感谢您的帮助

谢谢

想一想：

是否必须在SQL中完成？这是您通常希望用PHP或Python或任何用于与数据库接口的语言编写的东西

这种方法意味着您可以使用所需的任何复杂逻辑构建查询字符串，然后只提交一个普通的SQL查询，而不是尝试在SQL中构建过程

本

---

或者创建一个自定义函数来进行匹配\u ANY

首先，数据库当然不应该包含逗号分隔的值，但希望您已经意识到这一点。如果表格已标准化，则可以使用以下查询轻松获取项目：

select distinct i.Itemid
from Item i
inner join ItemFeature f on f.ItemId = i.ItemId
where f.Feature in ('AB', 'PQ')

可以匹配逗号分隔值中的字符串，但效率不高：

select Id
from Item
where
  instr(concat(',', Features, ','), ',AB,') <> 0 or
  instr(concat(',', Features, ','), ',PQ,') <> 0

选择Id
从项目
哪里
仪器（concat（‘，’，特征，‘，’），‘，AB’）0或
仪器（混凝土（’，’，特征，’，’），’，PQ，’）0
<代码> > P>可考虑使用Rice（）< /P>
对于所有喜欢REGEXP的人，我想我会添加以下内容作为解决方案：

SELECT * FROM ITEM WHERE FEATURES REGEXP '[[:<:]]AB|PQ[[:>:]]';

从包含REGEXP'[[：：]]特征的项目中选择*；

对于区分大小写：

SELECT * FROM ITEM WHERE FEATURES REGEXP BINARY '[[:<:]]AB|PQ[[:>:]]';

从包含REGEXP二进制“[[：：]]”的项中选择*；

对于第二个查询：

SELECT * FROM ITEM WHERE FEATURES REGEXP '[[:<:]]AB|PQ[[:>:]]' AND FEATURES REGEXP '[[:<:]]CDE[[:>:]];

从项目中选择*，其中包含要素REGEXP'[[：：]'和要素REGEXP'[[：：]]；

干杯
 我真正想做的是预测符合给定条件的记录数。此查询将通过PHP使用AJAX触发。因此，结果返回得越快，对我越有利。这让我只有一个选择——点击一次数据库。这就是我被卡住的地方，我觉得！是的，我可以使用PHP构造复杂的查询字符串。但是我无法理解这个查询字符串在那时是什么样子的。你搞定了！谢谢你，哈哈！我担心使用LIKE或RLIKE，因为大家都知道这两种语言天生就比较慢。至少比简单的仪器慢。我根据这个逻辑编写了动态查询生成器，它的工作方式很有魅力。我知道这种表模型在规范化方面不是很正确。但这是我目前所能提供的最好的了。@Adarsh：是的，它比像

这样的

稍快一点，但它仍然不能在字段上使用任何索引，所以它永远不会太快。它工作起来很有魅力，它为我节省了大量代码和一个小时的开发时间。我建议其他人也使用这种方法，因为它是紧凑的，并且只是“where”子句下的一个条件。