17370845950

MySQL无原生集合类型，SET仅为位图压缩字符串枚举，不支持动态集合运算；多值场景应优先用关联表，JSON数组需权衡性能代价；集合逻辑可用UNION/JOIN/NOT IN等基础语法模拟。

MySQL 中没有原生的「集合类型」（如 Python 的 set 或 SQL 标准中的 ARRAY），所谓“集合相关 SQL”，实际是指对**多值场景的模拟与处理**——比如去重、交集、并集、差集、枚举约束、JSON 数组字段查询等。初学者容易误以为 MySQL 有 SET 类型就能当集合用，结果在业务中踩坑不断。

别把 SET 当集合用：它只是字符串枚举

MySQL 的 SET 数据类型看起来像集合（支持存多个预定义值，如 SET('a','b','c')），但它底层是**位图压缩的字符串**，不是真正的数学集合：

• 插入 'a,b' 和 'b,a' 存储效果相同（自动排序+去重），但你无法用它做动态交集计算
• 不能索引单个成员（WHERE my_set LIKE '%b%' 会全表扫描）
• 不支持 UNION/INTERSECT 等集合运算（MySQL 8.0.19+ 才支持 INTERSECT 和 EXCEPT，且仅用于查询结果集，非字段级）
• 真正需要集合语义时，应拆成关联表（如 user_tags(user_id, tag_id)）

用标准 SQL 模拟集合运算：UNION、NOT IN、INNER JOIN

MySQL 早于 8.0.19 版本不支持 INTERSECT 和 EXCEPT，但所有集合逻辑都能用基础语法组合实现：

SELECT id FROM table_a
INTERSECT
SELECT id FROM table_b;

等价写法（兼容所有版本）：

SELECT a.id 
FROM table_a a 
INNER JOIN table_b b ON a.id = b.id;

差集（A - B）不用 EXCEPT，改用：

SELECT id FROM table_a 
WHERE id NOT IN (SELECT id FROM table_b WHERE id IS NOT NULL);

注意：NOT IN 遇到子查询含 NULL 会整个返回空——必须加 WHERE ... IS NOT NULL 过滤，否则逻辑出错。

JSON 字段里存数组？先想清楚性能代价

MySQL 5.7+ 支持 JSON 类型，很多人用它存标签列表：{"tags": ["mysql", "sql", "index"]}。看似灵活，但：

• JSON_CONTAINS(json_col, '"mysql"') 可查，但**无法走索引**（除非建函数索引，如 CREATE INDEX idx_tag ON t ((CAST(json_extract(tags, '$[0]') AS CHAR)))）
• 更新单个 tag 要读-改-写整字段，高并发下易锁表
• 聚合统计（如“每个 tag 出现次数”）必须用 JSON_TABLE() 拆开，性能远低于关联表 GROUP BY tag_id

真实业务中，只要 tag/分类/权限等关系超过 3 个值、且需频繁查询或关联，就该用规范的多对多表结构。

入门路径推荐：从「能跑通」到「敢优化」分三步走

别一上来就啃《高性能 MySQL》。按真实使用节奏推进：

• 第 1 周：只学 DQL + 小数据集练习 —— 在 SQLZOO 或 牛客网 SQL 题库 刷完 50 道题，重点练 JOIN、GROUP BY、HAVING、ORDER BY LIMIT。不装 MySQL，浏览器里敲就行
• 第 2 周：本地装 MySQL 8.0，动手建真实小表 —— 比如 users、orders、products，自己导 1000 行测试数据，执行 EXPLAIN SELECT ... 看 type 是 ALL 还是 ref，感受索引有没有生效
• 第 3 周：聚焦一个痛点深挖 —— 比如发现某条 SELECT 很慢，就专门查它：开 slow_query_log，用 EXPLAIN FORMAT=TREE（8.0+），看是否走了索引、有没有临时表、是否文件排序。这时候再回头读《MySQL 必知必会》第 12 章或官网 EXPLAIN 输出说明

集合操作本身不难，难的是判断什么时候该用关联表、什么时候能妥协用 JSON、什么时候必须上中间件分片——这些决策点，永远藏在慢查询日志和 EXPLAIN 的 rows 字段里，而不是语法手册中。