find_in_set不能用索引加速查询，因其需对每行strlist字段进行字符串解析和逐项比对，无法利用b+树索引，即使建了普通索引也全表扫描，explain显示type:all、key:null。
为什么 FIND_IN_SET 不能用索引加速查询
FIND_IN_SET(str, strlist) 是 MySQL 提供的字符串查找函数，用于判断 str 是否出现在以逗号分隔的字符串 strlist 中。但它本质上是全表扫描：MySQL 必须对每一行的 strlist 字段做字符串解析和逐项比对，无法利用 B+ 树索引。哪怕你在该字段上建了普通索引，FIND_IN_SET 也完全不走索引 —— 这是它最常被误用的核心陷阱。
常见错误现象：EXPLAIN 显示 type: ALL、key: NULL，哪怕数据量刚过万行，查询就明显变慢。
- 只适用于小数据量或低频查询场景（比如后台管理页查几十条配置）
- 不能替代规范化设计；若频繁按“集合中某个值”筛选，应拆成关联表
-
strlist中不能含空格（FIND_IN_SET('a', 'a, b, c')会失败，因实际匹配的是' b'）
FIND_IN_SET 的正确写法与边界条件
语法是 FIND_IN_SET(value, column)，注意两个参数顺序不能颠倒，且 value 不能含逗号、不能是空字符串、不能为 NULL —— 否则返回 0（即“未找到”），极易造成逻辑误判。
示例：查标签包含 'mysql' 的文章
SELECT * FROM articles WHERE FIND_IN_SET('mysql', tags) > 0;
-
FIND_IN_SET返回位置序号（从 1 开始），查不到时返回0，所以必须写成> 0，不能写成= 1（因为可能在第 2 位） -
tags字段类型建议用VARCHAR，避免TEXT在某些版本触发隐式转换警告 - 如果
tags可能为NULL，需额外判断：WHERE tags IS NOT NULL AND FIND_IN_SET('mysql', tags) > 0
当需要高效查询“集合中某值”时，该怎么做
真正需要按标签、权限、分类等多值字段高频检索时，FIND_IN_SET 是技术债起点，不是解决方案。
推荐路径：
- 立即停用逗号分隔存储，新增中间表（如
article_tags(article_id, tag_id)），加联合索引(tag_id, article_id) - 若暂时无法改表结构，可用
LIKE配合前后逗号兜底（仅限确定无特殊字符）：WHERE CONCAT(',', tags, ',') LIKE '%,mysql,%'—— 但同样不走索引，且易被注入或误匹配（如'sql'匹配到'mysql'） - MySQL 8.0+ 可考虑 JSON 字段 +
JSON_CONTAINS()，配合生成列和函数索引（需确认业务是否接受 JSON 写法迁移）
替换方案的实际性能对比（小样本）
在 10 万行数据、tags 平均长度 20 字符的测试中：
-
FIND_IN_SET('redis', tags)：平均耗时 320ms，EXPLAIN显示全表扫描 - 改为关联表后
SELECT a.* FROM articles a JOIN article_tags at ON a.id = at.article_id WHERE at.tag_id = 123：平均耗时 3ms，命中索引 -
CONCAT(',', tags, ',') LIKE '%,redis,%'：平均耗时 290ms，仍全表扫描，且LIKE前导通配符无法优化
真正卡住性能的从来不是函数本身，而是把非关系型存法硬套在关系型数据库上——字段里塞逗号那一刻，就已经放弃了索引和可维护性。
