必须用GROUP BY product_id + HAVING COUNT(DISTINCT tag_id) = N实现多标签共现判断，WHERE tag_id IN (...)仅支持任意匹配，无法表达“全部都有”的与逻辑；COUNT(DISTINCT)防重复计数，N须严格等于目标标签数。
子查询里用 GROUP BY + HAVING COUNT(DISTINCT tag_id) = N 判断共现
直接查“某个产品同时有 tag_id=1、2、3”不能靠 WHERE tag_id IN (1,2,3)，那只是查它有没有其中任意一个。真正要表达“全部都有”，得把问题转成：先找出所有 product_id，它们在 products_tags_association 表中关联的 tag_id 集合完整覆盖目标列表。
核心是两层嵌套：
外层查目标标签（比如 level=3 的候选），内层用 GROUP BY product_id + HAVING COUNT(DISTINCT tag_id) = 3 锁定同时命中三个前置 tag 的 product_id。
- 必须用
COUNT(DISTINCT tag_id)，防止单个产品对同一 tag 多次写入导致计数虚高 -
HAVING后面的数字必须严格等于你传入的 tag_id 个数，少一个就漏判，多一个就无结果 - 内层子查询的
WHERE tag_id IN (1,2,3)要加括号包裹，避免被外层条件意外干扰
MyBatis 动态拼接多标签子查询时，<foreach></foreach> 和 <if></if> 怎么配合
当 tag_id 列表来自接口参数（如 Java 的 List<long></long>），不能硬编码 IN (1,2,3)，得用 MyBatis 的 <foreach></foreach> 动态展开。但要注意：内层子查询的 HAVING 计数值也得同步变，不能写死。
常见错误是只动态了 IN 列表，却把 HAVING COUNT(...) = 3 写成固定值。正确做法是让 Java 传入一个 expectedCount 参数，或在 XML 里用 ${tags.size()}（注意：仅限于整型且可信来源，否则有注入风险）。
- 推荐方式：Java 层校验
tags非空后，显式传expectedTagCount = tags.size() -
<foreach></foreach>的open="("、close=")"、separator=","缺一不可，否则 SQL 语法报错 - 如果标签层级不同（如 level=1 和 level=2 混查），需在内层子查询加
AND level IN (1,2)，否则可能跨级误匹配
WHERE 中多个 IN 子句嵌套时，索引是否还生效
答案是：取决于字段顺序和复合索引结构。单列 INDEX(tag_id) 对 WHERE tag_id IN (...) 有效，但一旦嵌套子查询涉及 product_id 关联，就必须有覆盖两字段的复合索引，否则性能断崖下跌。
实测 23 万行数据下，没索引时嵌套查询耗时从 80ms 涨到 2.3s。关键索引组合有两个：
-
INDEX(tag_id, product_id)：支撑内层子查询的WHERE tag_id IN (...)快速定位行 -
INDEX(product_id, tag_id)：支撑外层关联ON pta.product_id = matched_products.product_id时避免全表扫描 - 别依赖 MySQL 自动优化——即使写了
STRAIGHT_JOIN，没索引照样慢
多列 IN 组合能否替代 GROUP BY + HAVING
不能。有人看到 WHERE (product_id, tag_id) IN ((101,1),(101,2),(101,3)) 就想套用，但这查的是“product_id=101 是否分别关联过 tag_id=1、2、3”，不是“是否存在某个 product_id 同时关联全部三个”。前者返回三行，后者只关心 product_id 是否存在。
多列 IN 本质仍是“或”逻辑，只是把多个单条件合并书写；而多标签共现是“与”逻辑，必须靠分组聚合才能表达。
最容易忽略的一点：当产品表本身有软删除字段（如 is_deleted = 0），所有子查询层级都得显式加上该条件，漏一层就会把已删除产品算进来。
