IN能用但需谨慎：字符串必须加单引号，数值类型建议统一格式；NULL不能参与匹配，子查询须排除NULL且非空；值超200个应检查执行计划，超2000个宜拆批或改JOIN；多列IN仅5.7+支持且要求结构严格对齐。
IN 不是万能的多值匹配工具，它能用，但得看怎么用、用在哪、值有多少。
字符串值必须加单引号，否则直接报错
写 WHERE name IN (Alice, Bob) 会触发 Unknown column 'Alice' in 'where clause' —— MySQL 把 Alice 当成列名了。正确写法是每个字符串都包单引号：WHERE name IN ('Alice', 'Bob')。
数值类型可以不加引号，但混写（比如 IN ('1', 2, 'three')）在严格模式下可能触发隐式转换警告或失败；类型一致最稳妥。
- 数字：直接写
id IN (1, 5, 8) - 字符串：全用单引号
status IN ('active', 'draft') - 日期：也得加引号
created_at IN ('2024-01-01', '2024-02-01') -
NULL不能写进列表里：value IN (1, NULL)中的NULL不参与匹配，整条条件对NULL记录无效
子查询必须返回单列，且不能含 NULL（或需额外处理）
WHERE user_id IN (SELECT id FROM users WHERE active = 1) 看似合理，但一旦子查询返回空结果集，主查询就变成 WHERE user_id IN ()，语法错误直接报 You have an error in your SQL syntax。
更隐蔽的问题是子查询里有 NULL：如果 SELECT id FROM users 返回 (1, 2, NULL)，那么 user_id IN (1, 2, NULL) 对任何 user_id 都不会为 TRUE（因为 = NULL 永远是 UNKNOWN）。
- 确保子查询加
WHERE id IS NOT NULL - 值列表为空时，提前判断并跳过整个
IN条件，或改用EXISTS - 大表关联优先考虑
JOIN或EXISTS，尤其当子查询结果超几百行时
IN 列表超过 1000 个值就该警惕性能和协议限制
MySQL 默认 max_allowed_packet=4MB，但实际能塞进 IN 的值数量远低于理论上限。实测中，超过 5000 个整型值就容易触发 Packet for query is too large；超过 10000 个，预处理语句常失败或 OOM。
更关键的是优化器行为：当 IN 值过多，MySQL 可能放弃使用索引，转而走临时表或全表扫描，响应时间陡增。
- 值少于 200 个：放心用
IN，可读性好，执行计划通常干净 - 值在 200–2000 之间：检查执行计划是否用了索引，避免
type: ALL - 值超 2000 个：拆成多个批次执行，或把值写入临时表再
JOIN - 绝对不要拼接上万个 ID 到一条 SQL 里——这是线上事故高发操作
多列 IN 查询只在特定版本支持，且语法严格
像 WHERE (a, b) IN ((1, 'x'), (2, 'y')) 这种写法，在 MySQL 5.7+ 才部分支持，且要求左右两边结构完全一致：列数、顺序、类型都要对齐。
子查询形式更受限：WHERE (name, email) IN (SELECT name, email FROM orders) 要求子查询只返回两列，且不能有 NULL 组合（任意一列为 NULL 就无法匹配）。
- 确认 MySQL 版本 ≥ 5.7（推荐 ≥ 8.0）
- 避免在多列
IN中混用NULL，如需匹配空值，单独用IS NULL - 生产环境慎用，优先拆解为多个单列条件或改用
JOIN
NULL、要不要索引、会不会撑爆 packet —— 这些细节不提前想清楚，IN 很快就会变成慢查询的入口。 
