Mysql筛选（和）查询多个连接行中的多个字段

我创建了一个查询，它返回产品列表及其字段和值。现在我想在字段中搜索某个值，并获得与此搜索查询匹配的结果列表。问题是我需要一个AND构造，所以fieldx值必须像%car%，fieldy值必须像%chrome%

下面是我的查询和结果集的示例：

查询

SELECT p.id as product,pf.field_name,pfv.field_value
FROM product p
JOIN field pf ON pf.product_id = p.product_id
JOIN field_val pfv ON pfv.field_id = pf.field_id

结果集

product | field_name | field_value
pr1     | meta_title | Example text
pr1     | meta_kw    | keyword,keyword1
pr1     | prod_name  | Product 1
pr2 ....

因此，考虑到上述查询和结果集，我希望执行以下操作： 查询meta_title包含“Example”且prod_name包含“Product”的所有产品。之后，我想对结果进行分组，以便只返回两个搜索查询都匹配的产品

我尝试了我所能想到的一切，我也尝试了许多解决相同问题的方法，但我认为我的方法不同，因为我需要字段名上的和匹配，以及多行上的值

例如，我尝试添加以下内容作为WHERE子句：

WHERE
(field_name = 'meta_title' AND field_value LIKE '%Example%') AND 
(field_name = 'prod_name' AND field_value LIKE '%Product%')

显然，这是行不通的，因为在meta_标题的第一个where之后，其他字段名就没有结果了。但是改变WHERE to或WHERE不会给我想要的结果

我也试过了，但结果似乎是一样的

有没有人知道如何解决这个问题，或者这是不可能的？

试试这个：

select product from [table_name]
    WHERE field_name like 'meta_title' AND field_value LIKE '%Example%'

UNION

select product from [table_name]
    WHERE field_name like 'prod_name' AND field_value LIKE '%Product%'

---

一种相对简单的方法是使用

分组方式

和

拥有

：

SELECT p.id as product
FROM product p JOIN
     field pf
     ON pf.product_id = p.product_id JOIN
     field_val pfv
     ON pfv.field_id = pf.field_id
WHERE (field_name = 'meta_title' AND field_value LIKE '%Example%') OR 
      (field_name = 'prod_name' AND field_value LIKE '%Product%')
GROUP BY p.id
HAVING COUNT(DISTINCT field_name) = 2;

---

通过修改

HAVING

子句（或者删除

WHERE

），可以为不同字段的存在和不存在表达许多不同的逻辑。例如

>0

将是

或
，而
=1
将是一个或另一个值，但不是两个值。
首先：我会选择最简单的方法。如果Prerak Solas解决方案有效，并且性能适合您，请尝试

另一种解决方案是使用透视表。使用此选项，表的select将返回如下内容：

product | meta_title   | meta_kw          | prod_name
pr1     | Example text | keyword,keyword1 | Product 1
pr2 ...

您可以轻松地查询以下内容：

SELECT 
  p.Id 
FROM 
  (subquery/view) 
WHERE 
  meta_title LIKE '%Example%' AND 
  prod_name LIKE '%Product%'

有关pivot的更多信息，请阅读
Perfect！就像一个魅力，完全有道理。我没有想到与Where的组合，这实际上使它充当AND语句。谢谢谢谢，但我使用了Gordon的解决方案，我可能会测试建议的解决方案之间的性能差异，但现在拥有解决方案对我来说是最容易实现的。谢谢，我之前确实想到过这个，但我不想使用它的原因是，查询现在非常小，但最终会变得更大，因为搜索查询可以扩展到大约15个字段。对于许多工会来说，这将是一个丑陋的大问题。无论如何谢谢你！