用 JSON 字段存集合，查询性能会明显下降
MySQL 5.7+ 支持
JSON类型，很多人用它存标签、权限列表、多选值等集合数据，比如
{"roles": ["admin", "editor"]}。但直接用 JSON_CONTAINS()或
JSON_EXTRACT()做 WHERE 条件，基本无法走索引——除非你建了生成列 + 函数索引。否则每次查询都要全表解析 JSON 文本，数据量一过十万，响应就明显变慢。
实操建议：
避免在WHERE中对
JSON字段做动态路径提取，例如
JSON_EXTRACT(meta, '$.tags[0]')—— 这种写法完全不可索引 如果必须用 JSON，把高频查询的字段单独抽成生成列，例如：
ALTER TABLE users ADD role_list JSON AS (meta->'$.roles');<br>ALTER TABLE users ADD INDEX idx_role_list ((CAST(role_list AS CHAR(255))));更稳妥的做法是放弃 JSON 存集合，改用关联表（如
user_roles），配合
JOIN或
EXISTS查询，性能和可维护性都更可控
用逗号分隔字符串存集合，LIKE 查询几乎必然慢
类似
role = 'admin,editor,viewer'这种设计，常见于老系统迁移或图省事的场景。想查“是否含 editor”，写
role LIKE '%editor%'看似简单，实则灾难：无法使用索引、易误匹配（比如匹配到
supereditor）、不支持原子更新。
实操建议：
绝对不要用LIKE '%xxx%'在长文本字段上做集合成员判断 哪怕加了前缀索引（如
INDEX(role(10))），也对
LIKE '%...'无效 如果真要保留字符串结构，至少用定长分隔（如
|admin|editor|）并配合正则：
role REGEXP '(^|\|)editor(\||$)'，但仍是全表扫描，仅比
LIKE少点误匹配
关联表 + 覆盖索引是集合查询最稳的方案
标准的多对多关系（用户-角色、文章-标签、订单-商品）应该用中间表，这是 MySQL 最擅长的模式。只要索引设计得当，即使千万级数据也能毫秒响应。
实操建议：
中间表主键设为联合主键，顺序按查询频次排，例如常用「查某用户所有角色」，就设PRIMARY KEY (user_id, role_id)；若常用「查某角色下所有用户」，则反过来 需要统计数量时，避免
SELECT COUNT(*) FROM user_roles WHERE user_id = ?，改用
SELECT COUNT(role_id) FROM user_roles WHERE user_id = ?并确保
role_id非空（NOT NULL），这样能走索引覆盖，无需回表 如果还要查带名称的集合（如用户+角色名），用
JOIN比多次查询快得多，但注意别漏掉
role.name上的索引
全文索引只适合模糊搜索，不适合精确集合判断
有人试过把集合字段（如逗号字符串）设为
TEXT+
FULLTEXT索引，再用
MATCH ... AGAINST查关键词。这在搜索场景有用，但对「是否包含某值」这类确定性判断，结果不可靠（停用词、分词逻辑、最小词长限制都会干扰），且无法保证一致性语义。
实操建议：
FULLTEXT不适用于权限校验、状态枚举、ID 列表等需要精确匹配的集合字段 如果业务同时需要「精确包含」和「模糊搜索」，拆成两个字段：一个用关联表做精确查询，另一个用
JSON或字符串 + 全文索引做搜索补充 注意
innodb_ft_min_token_size默认是 3，意味着单字符值（如
a,
Y）根本不会被索引进去 实际中，集合字段性能差，往往不是因为 MySQL 不行，而是模型没对齐。关联表看着多建一张表、多写几行 SQL，但换来的是可预测的执行计划、稳定的 QPS 和清晰的约束边界。那些“先快速上线再优化”的 JSON 或字符串集合，后期基本都成了慢查询根因。
