根本不清楚“ value1
”来自哪里,或者“ uid2
”来自哪里,或者“”列来自哪里like_id
。这些列名不会出现在您的示例表中。您的示例查询引用了两个不同的表名(table
和likes
),但您只显示一个示例表的数据,并且该表没有名为 的列like_id
。
如果我们假设您的查询中的“ value1
”和“ uid2
”是文字,或者是提供给查询的绑定参数,这似乎是合理的,考虑到您的规范(不同地),值 1、2、3 和 4。但是我们'仍然留下“ like_id
”列。鉴于它在 IN 子查询的 SELECT 列表中被引用,我们将假定它是 " likes
" 表中的一列,并且鉴于它在外部查询中被引用,我们将假定它是(不幸命名)table
表。
(归根结底,鉴于您无法复制工作测试用例,您的查询如何返回“正确”结果根本不清楚。)
给定一个表格,如您的示例数据所示,例如
CREATE TABLE likes (id INT, name VARCHAR(4), uid INT);
INSERT INTO likes VALUES (1,'bil',3),(2,'test',3),(3,'test',4)
,(4,'test',4),(5,'bil',5),(6,'bil',5);
ALTER TABLE likes ADD PRIMARY KEY (id);
ALTER TABLE likes ADD CONSTRAINT likes_ix UNIQUE KEY (uid, name);
假设我们正在针对该单个表运行查询,并且我们正在将与 uid=3 关联的“likes”与与 uid=4 关联的“likes”进行匹配,并且匹配是在“name”列上完成的,然后
SELECT t.id
FROM `likes` t
WHERE t.uid = 3
AND EXISTS
( SELECT 1
FROM `likes` s
WHERE s.name = t.name
AND s.uid = 4
)
这将从表中返回uid=3 的id
行likes
,我们还在likes
表中找到 uid=4 具有匹配name
值的行。
鉴于要从外部查询的表中检查的行数likes
有限,这给出了需要运行相关子查询的有限次数,这应该会提供合理的性能:
对于大型集合,连接操作通常会更好地返回等效结果:
SELECT t.id
FROM `likes` t
JOIN `likes` s
ON s.name = t.name
AND s.uid = 4
WHERE t.uid = 3
GROUP
BY t.id
任一查询的最佳性能的关键是适当的索引。