MySQL 条件查询是入门阶段最容易被高估也最容易卡住的地方。很多人以为会写SELECT * FROM user WHERE status 1就算会条件查询了但真到同一张表、不同字段、可传可不传参数的时候条件一多就乱要么结果比预期多要么有一条 NULL 数据始终查不出来要么条件里套了函数后整表扫描。尤其对准备走网络安全、安全开发方向的人MySQL 条件查询不是孤立语法题而是后面看日志、做数据审计、理解业务查询逻辑的基本功。这篇内容继续把“不同条件查询”拆开讲多条件组合、NULL 判断、范围枚举、模糊匹配、子查询条件、动态拼 WHERE以及查询出问题时的排查顺序。1. 条件查询不是背语法而是先把“取什么数据”想清楚1.1 条件查询解决的是“数据漏斗”问题条件查询的本质是把一张表里的数据按规则过滤成更小的结果集。一张用户表可能有几十万行但真正要处理的可能只是“已禁用账号”“超过 18 岁”“最近一个月有登录记录”这几个子集。如果你不知道条件查询能组合出哪些形状后面所有数据相关工作都容易断在第一步。安全方向也一样。很多学习资料喜欢直接带人看漏洞案例但我更建议先回到最基础的数据查询你需要在授权的测试环境里理解一条 SQL 在什么样的情况下会返回什么才能真正看懂业务代码里那一段查询条件为什么写得有问题。没有这个基础后面学代码审计、日志审计都会很吃力。1.2 复现环境建两张表和一份测试数据下面所有例子都可以在 MySQL 5.7 或 8.0 里直接跑。如果本机没有 MySQL可以用 Docker 临时起一个学习实例docker run --name mysql-study \ -e MYSQL_ROOT_PASSWORDyour_password \ -p 3306:3306 \ -d mysql:8.0这个命令会启动一个 MySQL 8.0 容器默认端口映射到本机 3306。如果本机 3306 已经被占用可以把3306改成其他端口比如13306:3306。连接进去后先建一张用户表CREATE TABLE sys_user ( id INT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(50) NOT NULL, email VARCHAR(100), age INT, status TINYINT NOT NULL DEFAULT 1 COMMENT 1启用 0禁用, vip_level TINYINT DEFAULT 0, created_at DATETIME ) DEFAULT CHARSETutf8mb4;插入测试数据INSERT INTO sys_user (username, email, age, status, vip_level, created_at) VALUES (zhangsan, zhangsanexample.com, 22, 1, 0, 2024-05-01 10:00:00), (lisi, NULL, 17, 0, 1, 2024-06-01 11:00:00), (wangwu, wangwutest.com, NULL, 1, 0, 2024-06-15 09:30:00), (admin, adminexample.com, 30, 1, 2, 2024-07-01 08:00:00), (test01, test01example.com, 18, 1, 1, 2024-07-02 20:00:00), (audit01, audit01example.com, 33, 0, 0, 2024-05-20 15:00:00);再建一张登录日志表因为后面子查询条件会用CREATE TABLE login_log ( id INT PRIMARY KEY AUTO_INCREMENT, user_id INT NOT NULL, login_at DATETIME NOT NULL, ip VARCHAR(45) ); INSERT INTO login_log (user_id, login_at, ip) VALUES (1, 2024-06-10 09:00:00, 192.0.2.1), (2, 2024-06-11 10:00:00, 192.0.2.2), (1, 2024-07-01 11:00:00, 192.0.2.30);1.3 安全方向学条件查询重点看什么不需要一上来就把所有 SQL 语法背完。对于安全开发或者做数据审计的人条件查询重点看三块查询条件的组合逻辑AND、OR、NOT 怎么配合括号放在哪里。特殊值的处理NULL、空字符串、0、日期边界是不是被漏掉了。条件由外部传入时的写法怎么拼条件才不对原有逻辑产生破坏。后面所有内容都围绕这三块展开。2. 多条件组合真值表比 SQL 关键字更重要2.1 AND 和 OR 同时出现优先级先于你的直觉先看一条最常见的错误写法SELECT id, username, status, created_at FROM sys_user WHERE status 1 OR age 20 AND created_at 2024-06-01;你的脑海里可能想的是“状态是启用的或者年龄小于 20 的用户并且创建时间要在 2024-06-01 之后”。但 MySQL 不会按你的想法执行。它执行的是WHERE status 1 OR (age 20 AND created_at 2024-06-01);AND 的优先级高于 OR。如果业务真正想要的逻辑是“状态为启用或年龄小于 20且创建时间在 2024 年 6 月 1 日之后”必须加括号SELECT id, username, status, created_at FROM sys_user WHERE (status 1 OR age 20) AND created_at 2024-06-01;这两条 SQL 的结果完全不同。第一条会把很多创建时间在 5 月但状态为启用的用户也带出来第二条会先把“启用或低龄”这个整体条件圈出来再用创建时间过滤一遍。我之前见过不少数据统计对不上最后排查下来就是 OR 和 AND 的优先级问题。写复杂条件时不要依赖“我自己觉得 MySQL 应该先算哪边”括号才是明确表达逻辑的正确方式。2.2 NULL 不是空字符串也不是 0NULL 在 SQL 里是一个很特殊的状态它既不是空字符串也不是数字 0。它表示“这个字段值未知”。看这个例子SELECT id, username, age FROM sys_user WHERE NOT (age 20);直觉上这条 SQL 会查出“年龄不大于 20 的用户”。但实际结果里不会出现wangwu因为wangwu的 age 是 NULL。原因在于age 为 17age 20为 falseNOT(false)为 true。age 为 NULLage 20的结果是 unknownNOT(unknown)仍然是 unknown。unknown 不满足 WHERE 过滤条件。NULL 会污染比较运算。如果想查“邮箱没填写”的用户不能只写WHERE email 。邮箱有两种“没填”一种是字段为 NULL一种是字段被存成了空字符串。安全一点的业务查询要同时处理SELECT id, username, email FROM sys_user WHERE email IS NULL OR email ;IS NULL不是 NULL。在 MySQL 中使用WHERE email NULL查不出任何数据因为 NULL 和任何值比较都不会为 true。2.3 组合条件格式化给自己留一条可维护的路条件多了以后最关键的不是把 SQL 写短而是让其他人一眼能看懂逻辑。我习惯把条件按业务维度分组每一组用括号包住SELECT id, username, status, age, vip_level FROM sys_user WHERE (status 1 AND age 18) OR (vip_level 2 AND email IS NOT NULL);这句表达的意思很清晰要么是启用且成年人要么是高级会员且邮箱已填写。如果你用代码生成条件也建议按同样的思路维护。条件分组和缩进不会影响 MySQL 性能但会直接影响你后续排查问题的速度。3. IN、BETWEEN、LIKE、NULL看着简单边界最容易带偏结果3.1 NOT IN 碰到 NULL结果可能整段消失先看一条“查所有没有任何登录记录的用户”的写法SELECT id, username FROM sys_user WHERE id NOT IN ( SELECT user_id FROM login_log );这条 SQL 在 login_log 的 user_id 都不为 NULL 时是正常的。但如果业务表允许 user_id 为 NULL子查询返回结果里一旦出现 NULL情况就不一样了。NOT IN的本质是“不等于任何一项”。当列表中存在 NULL 时任何一个普通数字都无法确认自己“不等于 NULL”结果是 unknown。于是整条查询可能返回空集合。更稳妥的写法是用NOT EXISTSSELECT s.id, s.username FROM sys_user s WHERE NOT EXISTS ( SELECT 1 FROM login_log l WHERE l.user_id s.id );EXISTS只判断子查询有没有返回行不参与 NULL 的三值逻辑。这个差异是条件查询里最容易踩的坑之一。我一般看到NOT IN子查询会先确认子查询结果字段是否非空。如果字段没有强约束直接改成NOT EXISTS更稳。3.2 BETWEEN 是包含边界日期区间要当心BETWEEN看起来简单但它包含两端。SELECT id, username, age FROM sys_user WHERE age BETWEEN 18 AND 30;这个条件等价于WHERE age 18 AND age 30;所以 18 和 30 都会被包含。日期区间用 BETWEEN 时要格外小心SELECT id, username, created_at FROM sys_user WHERE created_at BETWEEN 2024-06-01 AND 2024-06-30;这条查询会漏掉 2024-06-30 当天 00:00:00 之后的所有记录。created_at如果是 DATETIME 类型字符串2024-06-30会被转换成2024-06-30 00:00:00。所以 6 月 30 日当中产生的数据如果不加BETWEEN 2024-06-30 23:59:59就会查不到。更推荐用“左闭右开”的写法SELECT id, username, created_at FROM sys_user WHERE created_at 2024-06-01 AND created_at 2024-07-01;这个写法能完整覆盖整个 6 月而且不容易踩到 23:59:59 这种边界问题。做日志分析、安全统计时日期边界尤其重要。3.3 LIKE 的通配符、转义和字符集问题LIKE 支持两个通配符%匹配任意多个字符。_匹配单个字符。比如SELECT id, username FROM sys_user WHERE username LIKE admin%;可以查出来以 admin 开头的用户名。但如果你要查询的字符串中间有下划线比如test_01这里的_会被当成单字符通配符而不是普通下划线。这时需要用转义SELECT id, username FROM sys_user WHERE username LIKE test\_01 ESCAPE \\;MySQL 默认可以用反斜线转义但为了可读性建议显式写ESCAPE。例如SELECT id, username FROM sys_user WHERE username LIKE test$_01 ESCAPE $;这段 SQL 里$被指定为转义符后面的_就是普通字符。另外LIKE 的%通配符放在条件开头时很难走索引SELECT id, username FROM sys_user WHERE username LIKE %admin%;这种写法不是一定不能走索引但大多数情况下会导致 MySQL 需要扫描更多行。数据量小的时候无所谓数据量大了要谨慎。安全日志里的模糊搜索如果条件允许优先考虑前缀匹配。3.4 写条件前先问一句字段类型和排序规则对吗有时候条件看起来没问题但结果就是不对这时要检查字段类型和排序规则。例如用户名认证场景中MySQL 采用utf8mb4_0900_ai_ci或utf8mb4_general_ci这类排序规则时等号条件不区分大小写SELECT id, username FROM sys_user WHERE username Admin;如果字段排序规则是utf8mb4_bin这个条件可能只匹配到大小写完全一致的记录。如果业务要求用户名大小写不敏感默认排序规则通常没问题如果要求严格区分就要在设计表结构或字段时想好。不要在条件查询阶段临时改变字段比较方式那样很容易影响索引使用。4. 子查询结果作为条件IN、EXISTS、ANY/ALL 的选择逻辑4.1 子查询条件把判断交给另一段查询结果条件不一定是固定的数字或字符串它可以是另一段查询返回的结果。比如要查“2024 年 6 月 1 日之后有过登录记录的用户”SELECT u.id, u.username FROM sys_user u WHERE u.id IN ( SELECT l.user_id FROM login_log l WHERE l.login_at 2024-06-01 00:00:00 );在这个例子里IN 后面的子查询先找出符合条件的 user_id然后再用外层用户表的 id 去匹配。这种写法很自然但要注意几点子查询里的字段要写清楚所属表用别名区分避免内层外层字段重名后逻辑混乱。IN 子查询返回的结果集合一般不会太大如果子查询返回几十万行就要考虑是否合适。别理所当然觉得 IN 一定比 EXISTS 慢实际要看表结构、数据量和优化器的选择。4.2 NOT IN 与 NOT EXISTS结果不同排查方向也不同前面已经提到NOT IN 遇到 NULL 会出问题。这里再补一个对比。如果 login_log 表的一部分 user_id 可以为 NULL业务想查“没有登录记录的用户”用 NOT IN 可能返回空集。但用 NOT EXISTS 则只关心是否存在匹配行SELECT u.id, u.username FROM sys_user u WHERE NOT EXISTS ( SELECT 1 FROM login_log l WHERE l.user_id u.id );这种写法是相关子查询对 sys_user 中的每一行都去 login_log 里检查一次是否存在匹配记录。它不一定总是比 NOT IN 快但对于“查不存在”这种场景结果逻辑更稳健。排查时如果发现“NOT IN 查出的结果比预期少”或“一条都查不出”优先看子查询结果里有没有 NULL。4.3 ANY 和 ALL比较条件里的“至少一个”与“全部”ANY 和 ALL 通常和比较运算符一起用面试和代码审计里会看到业务中也不能完全避免。举个例子SELECT username, age FROM sys_user WHERE age ANY ( SELECT age FROM sys_user WHERE status 0 );第二行子查询会返回所有禁用用户的年龄。假设结果集合是 17 和 33。age ANY (17, 33)等价于age 17 OR age 33只要大于其中任何一个就算满足。age ALL (17, 33)等价于age 17 AND age 33必须大于全部才算满足。也就是说对而言ANY 更接近“大于最小值”。ALL 更接近“大于最大值”。但别急着背。最可靠的理解方式是把 ANY 看成 OR把 ALL 看成 AND。不同比较符号会改变方向背一个固定结论最容易翻车。如果子查询没有返回任何行ANY 和 ALL 的结果会根据具体语句产生比较特殊的行为。所以我一般建议不要依赖空子查询的隐式结果先确认子查询确实有数据或者直接通过统计值把逻辑写得更直白。5. 动态拼 WHERE先处理好参数化再考虑怎么写得更短5.1 最常见的错误把用户输入直接拼到条件字符串里实际开发中经常会遇到“根据某个字段值动态拼 WHERE 查询条件”的需求。例如页面上有一个搜索框用户输入用户名就按用户名查用户输入时间范围就按时间范围查什么都不输入就查全部。这种需求如果不加处理很容易写成# 不推荐只看逻辑不讨论具体数据库驱动 sql SELECT * FROM sys_user WHERE 1 1 if username: sql AND username username 这种写法的最大问题不是1 1而是用户输入被直接拼进了 SQL。一旦用户输入的内容里出现引号、特殊字符SQL 语义就可能被改变。这属于非常典型的注入风险。安全开发现场如果看到这种代码往往会先标记出风险。作为学习阶段不应该去构造攻击语句但必须至少知道为什么参数化写法是底线。5.2 参数化写法条件壳子可以拼值必须走参数位正确思路是动态拼“条件结构”不能把“用户输入值”直接拼进去。以 Python DB-API 为例username zhangsan start_time 2024-06-01 00:00:00 sql SELECT id, username, created_at FROM sys_user conditions [] params [] if username: conditions.append(username %s) params.append(username) if start_time: conditions.append(created_at %s) params.append(start_time) if conditions: sql WHERE AND .join(conditions) cursor.execute(sql, params)这段代码里WHERE 后面的条件名是代码固定写好的而用户名、时间这些值全部通过%s占位符传给数据库驱动。Java 里用 PreparedStatement 也是一样的思路String sql SELECT id, username, created_at FROM sys_user WHERE 1 1; ListObject params new ArrayList(); if (username ! null !username.isEmpty()) { sql AND username ?; params.add(username); } PreparedStatement ps conn.prepareStatement(sql); for (int i 0; i params.size(); i) { ps.setObject(i 1, params.get(i)); }真正可以拼的是AND username ?这段固定字符串拼多少条件由代码逻辑决定但值必须通过?占位。5.3 ORM 和 XML 里的动态条件自己处理 AND 还是交给框架在 Java 的 MyBatis 环境里动态条件通常用where标签解决框架会自动去掉第一个多余的 ANDselect idlistUser resultTypeUser SELECT id, username, status, created_at FROM sys_user where if testusername ! null and username ! AND username #{username} /if if teststartTime ! null AND created_at gt; #{startTime} /if /where /select使用#{}表示绑定参数MyBatis 会替你处理占位和转义。如果写成${username}内容是直接拼接进去的应当非常谨慎。不同框架的处理方式不同但核心原则一致动态拼的是条件结构输入值必须通过绑定参数传递。5.4 动态条件不是堆叠越多越好先保持条件可解释动态条件多了以后容易出三个常见问题条件叠加顺序不一致导致接口在不同环境下返回不同结果。条件重复叠加例如同一个字段既被范围条件过滤又被等值条件过滤最后查不到数据。条件里包含大量无关参数等于没有过滤。所以我更建议把每一次动态拼装都当成一次“条件构造过程”来做先列出本次查询允许传入哪些字段。每一个字段对应一条独立的条件。条件之间统一用 AND 链接。通过单元测试或小样例验证传入一个字段时结果正确传多个字段时结果也正确。如果还要对排序字段做动态处理不要把用户传的排序字段原样拼进 ORDER BY。最稳妥的方式是先做白名单映射比如只允许created_at、username等固定字段排序然后代码里再把对应的字段名写进 SQL。6. 查询结果不对或很慢时按这个顺序