MySQL不支持原生数组类型，推荐使用JSON字段或规范的多对多关联表实现集合；SET类型仅适用于固定布尔开关，存在诸多限制。
MySQL 本身不支持数组或集合类型字段
直接在 MySQL 表中定义 ARRAY、SET（非 ENUM 的 SET）、JSON.ARRAY 等结构是不可行的——除非用 JSON 字段模拟，但那不是真正意义上的数组类型。原生 SET 类型只是预定义字符串枚举的位图存储，不支持动态值、不能存数字/对象、长度上限 64 个成员，且查询逻辑别扭。
用 JSON 字段存集合是最常用且可行的方案
MySQL 5.7+ 支持 JSON 类型，可存数组如 [1, 2, 3] 或 ["a", "b", "c"]，配合函数做基础操作：
-
JSON_CONTAINS(json_col, '"value"')判断字符串是否存在（注意引号要匹配） -
JSON_CONTAINS(json_col, '1')判断数字是否存在（不加引号） -
JSON_LENGTH(json_col)获取数组长度 - 插入时用
JSON_ARRAY()构造，如INSERT INTO t (tags) VALUES (JSON_ARRAY("web", "mysql")) - 更新数组需用
JSON_ARRAY_APPEND()或JSON_REMOVE()，不能直接SET tags = tags + ["new"]
UPDATE posts SET tags = JSON_ARRAY_APPEND(tags, '$', 'backend') WHERE id = 123;
⚠️ 注意：JSON 字段无法直接建普通 B-Tree 索引；如需高效查询某个元素，得建生成列 + 索引：
ALTER TABLE posts ADD COLUMN tag_backend TINYINT AS (JSON_CONTAINS(tags, '"backend"')) STORED; CREATE INDEX idx_tag_backend ON posts(tag_backend);
多对多关系表才是规范、可扩展的集合实现方式
如果集合元素有业务含义（如用户标签、商品分类、权限列表），硬塞 JSON 会很快遇到问题：无法关联查询、无法约束值合法性、无法利用外键、难以做聚合统计。
- 拆成三张表：
items（主表）、tags（值字典）、item_tags（关联表，含item_id和tag_id） - 关联表上建联合索引：
INDEX idx_item_tag (item_id, tag_id)和INDEX idx_tag_item (tag_id, item_id) - 查某 item 所有 tag：
SELECT t.name FROM item_tags it JOIN tags t ON it.tag_id = t.id WHERE it.item_id = 123 - 查含多个 tag 的 items：
SELECT item_id FROM item_tags WHERE tag_id IN (1, 5) GROUP BY item_id HAVING COUNT(DISTINCT tag_id) = 2
这种设计天然支持事务一致性、唯一性约束、级联删除，也便于后期加字段（比如 tag 启用状态、创建时间）。
别碰 SET 类型，除非你只存固定几个布尔开关
SET('email', 'sms', 'push') 看似像集合，但它本质是位运算整数，值只能从建表时声明的字面量中选，且最大 64 项。常见误用：
- 想动态增删选项？不行，必须
ALTER TABLE ... MODIFY COLUMN，锁表风险高 - 想存
"email, sms"字符串？MySQL 会自动转成位值，但读出来是逗号拼接，无法用标准字符串函数处理 - 想查 “包含 email 且不包含 push”？得写
col & 1 AND NOT (col & 4)，可读性差，ORM 基本不支持
真只是记录“用户是否开启某几类通知”，用独立的 TINYINT(1) 布尔字段更清晰；否则就用 JSON 或关联表。
JSON 方案适合轻量、读多写少、集合值无强业务语义的场景；关联表适合需要完整性、可检索、可扩展的集合。两者之间没有银弹，但硬用 SET 或逗号分隔字符串（VARCHAR 存 "1,3,5"）基本等于给自己埋坑——尤其是当别人要查“所有带 tag 7 的记录”时，你得写 WHERE tags LIKE '%7%'，结果把 17、71、27 都拖进来了。
