WHERE子句中AND表示所有条件必须为真，OR表示至少一个为真；需注意AND优先级高于OR、NULL不能用=判断、LIKE以%开头导致索引失效、IN列表过长影响性能。
WHERE 子句里多个条件用 AND 还是 OR？看逻辑关系
子句本身不决定用哪个逻辑运算符，关键是你想表达的业务含义。
表示所有条件都必须为真，
表示只要一个为真就匹配。
查询年龄在 25 到 35 之间且城市是“北京”的用户：
查询是管理员或者状态为激活的用户：
混用时注意优先级：
优先级高于
，没加括号容易出错。比如
实际等价于
，不是你想查的“（管理员或激活）且未删除”。
NULL 值在 WHERE 条件中不能用 = 判断
MySQL 中
不等于任何值，包括它自己。写
永远不返回结果。
正确写法是用
或
：
如果要同时匹配非空值和
，不能写成
，得拆开：
使用
或
可以临时把
转成具体值再比较，但要注意索引失效风险。
LIKE 模糊查询带 % 开头会导致索引失效
是常用多条件筛选手段，但性能差异极大：
MySQL（Linux）
MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。
下载
：能走
字段上的 B+ 树索引
或
：无法使用索引，全表扫描
中文场景下还容易遇到字符集问题：确保字段和连接的
支持中文，比如
；否则
可能漏掉某些拼音变体
替代方案：全文索引（
）适合大文本搜索，但只支持
和
（5.6+），且对短词效果差
IN 列表超过 1000 项可能触发性能或语法限制
看似简洁，但实际使用有隐性边界：
MySQL 默认没有硬性上限，但过长的
列表会显著增加 SQL 解析时间和执行计划复杂度
某些中间件（如 ShardingSphere、MaxCompute JDBC 驱动）会主动截断或报错，常见阈值是 1000 项
替代做法：
把 ID 列表写入临时表，改用
或子查询
分批查询，比如每次 500 个 ID，循环执行
用
配合有序主键，效率更高
注意
的行为：如果字段本身允许
，这个条件不会匹配
行，因为
返回
，不是
实际写多条件
时，最容易被忽略的是运算符优先级、
的三值逻辑，以及看似无害的
对查询性能的毁灭性影响。
WHEREANDORSELECT * FROM users WHERE age >= 25 AND age <= 35 AND city = '北京';SELECT * FROM users WHERE role = 'admin' OR status = 'active';ANDORrole = 'admin' OR status = 'active' AND deleted = 0role = 'admin' OR (status = 'active' AND deleted = 0)NULLWHERE column = NULLIS NULLIS NOT NULLSELECT * FROM orders WHERE shipped_at IS NULL;NULLWHERE status = 'shipped' OR status = NULLSELECT * FROM orders WHERE status = 'shipped' OR status IS NULL;COALESCE()IFNULL()NULLLIKEname LIKE '张%'namename LIKE '%三'name LIKE '%王%'collationutf8mb4_unicode_ciLIKE '李%'FULLTEXTMyISAMInnoDBININJOINWHERE id BETWEEN ? AND ?IN (NULL, 1, 2)NULLNULLNULL IN (NULL, 1, 2)UNKNOWNTRUEWHERENULLLIKE '%xxx'