FIND_IN_SET能查逗号分隔字段是因为其内部逐段解析、逐项比较，但无法利用B+树索引，执行时必为全表扫描（type: ALL）。
为什么FIND_IN_SET能查逗号分隔字段，但不能用索引
FIND_IN_SET(str, strlist) 是 MySQL 提供的专用函数，用于判断 str 是否出现在以英文逗号分隔的字符串 strlist 中。它内部逐段解析、逐项比较，所以能正确处理 'apple,banana,cherry' 这类值。但它**完全无法利用 B+ 树索引**——因为 MySQL 无法对逗号分隔字符串建立有效前缀或范围扫描，执行计划里一定会显示 type: ALL（全表扫描）。
常见错误是以为加了索引就能加速这类查询，结果发现数据量一过万，SELECT * FROM t WHERE FIND_IN_SET('x', tags) 就明显变慢。这不是写法问题，是设计层面的限制。
如何安全地写 FIND_IN_SET 查询语句
基本语法是 FIND_IN_SET('value', column_name)，返回非零整数（位置索引）表示匹配，返回 0 表示不匹配。注意两个关键点：
-
value不能含逗号、括号或空格——否则匹配行为不可靠；例如FIND_IN_SET('a,b', 'a,b,c')返回 0，因为函数只按字面逗号切分，不会做子串匹配 -
column_name值必须是纯逗号分隔字符串，且首尾不能有空格；' apple , banana '会导致FIND_IN_SET('apple', col)失败，得先用TRIM和REPLACE清洗 - 区分大小写取决于列的排序规则（collation），比如
utf8mb4_bin下'Apple'≠'apple'
实用写法示例：
SELECT * FROM products
WHERE FIND_IN_SET('sale', TRIM(BOTH ',' FROM REPLACE(REPLACE(tags, ' ', ''), '\t', '')));
替代方案：什么时候该放弃 FIND_IN_SET
当出现以下任一情况，说明已到临界点，应停止使用逗号分隔 + FIND_IN_SET：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 单表记录超过 5000 条，且该字段查询频率高
- 需要支持“同时包含 A 和 B”（AND）、“排除 C”（NOT IN）等组合逻辑
- 业务要求按标签分组统计（如
GROUP BY tags），而FIND_IN_SET无法参与GROUP BY推导 - 需要关联其他维度表（比如查“带 sale 标签且属于 category_id=3 的商品”），此时 JOIN 效率远低于正规多对多关系
标准解法是拆成三张表：products、tags、product_tags（含 product_id 和 tag_id），然后用 INNER JOIN 或 EXISTS 替代。
MySQL 5.7 下的兼容性细节
MySQL 5.7 对 FIND_IN_SET 的行为与 5.6 基本一致，但有两个易忽略点：
- 如果
strlist为NULL，整个函数返回NULL，不是 0 —— 所以WHERE FIND_IN_SET(...) != 0在字段可能为空时会漏数据，应写成WHERE FIND_IN_SET(...) > 0 - 最大支持约 64K 个逗号分隔项（受
max_allowed_packet和内部缓冲限制），但实际建议单字段不超过 50 项，否则解析开销陡增 - 在
ORDER BY或HAVING中使用该函数会导致无法使用文件排序（Using filesort），性能雪上加霜
真正棘手的不是语法怎么写，而是当别人已经把数据存成逗号分隔格式后，你得判断：是硬着头皮优化查询，还是推动改表结构。后者往往更省时间。
