IN子句需为字符串加单引号，数字建议统一加引号；等价于=ANY但可读性差；大数据量时易致全表扫描，应拆分或改用JOIN；含NULL时表达式恒为UNKNOWN，须单独处理。
IN 子句的基本写法和常见错误
IN 用于判断某字段是否匹配一组离散值，语法简单但容易出错。最常踩的坑是把字符串值漏掉引号，比如写成 WHERE status IN (active, pending) —— 这会触发 MySQL 把 active 当作列名或未定义变量报错 Unknown column 'active' in 'where clause'。
正确写法必须给每个字符串加单引号：WHERE status IN ('active', 'pending')。数字类型可不加引号（如 id IN (1, 2, 3)），但为统一性和避免隐式转换问题，建议全部加引号。
IN 和 = ANY 的等价性与可读性取舍
IN 本质上等价于 = ANY()，例如 WHERE id IN (1,2,3) 和 WHERE id = ANY(VALUES ROW(1), ROW(2), ROW(3)) 行为一致。但后者几乎没人用，因为可读性差、写法冗长。
实际开发中坚持用 IN 即可，除非你正在调试子查询逻辑，需要显式表达“任意一个匹配”语义。注意：子查询返回多行单列时，IN 能直接接，而 = 会报错 Subquery returns more than 1 row。
IN 子句性能瓶颈和替代方案
当 IN 列表超过几百项（比如 IN (1,2,...,5000)），MySQL 可能放弃使用索引，转为全表扫描；尤其在旧版本（5.6 及以前）中更明显。
- 列表项数超 1000 时，考虑拆成多个小批量查询，或改用临时表 +
JOIN - 若值来自另一张表，优先用
JOIN或EXISTS替代IN (SELECT ...)，避免相关子查询反复执行 - 确保被查字段有索引；
IN对索引的利用依赖于字段选择性，低选择性（如gender IN ('M','F')）仍可能走全表
NULL 值在 IN 中的特殊行为
IN 对 NULL 的处理容易被忽略：如果列表中包含 NULL，比如 WHERE col IN ('a', NULL)，整个表达式结果恒为 UNKNOWN（不是 TRUE 也不是 FALSE），该行不会被返回 —— 即使 col 本身是 NULL。
想匹配 NULL，必须单独写 col IS NULL，或用 COALESCE 统一转换：WHERE COALESCE(col, 'null_placeholder') IN ('a', 'null_placeholder')。别指望 IN 自动覆盖空值场景。
