把 MySQL 的不同条件查询和“判断字段是否为空”放在一起练，是最容易让零基础新手快速理解WHERE的切入点。原因很直接：多条件筛选、动态查询、导出统计、接口排查，这些场景全部要落到一句 SQL 上；而 NULL、空字符串、默认值一旦混在一起，查询结果就会出现“少一条、多一条、明明有值却查不出来”的诡异问题。
这篇文章不是把 MySQL 语法从头讲一遍，而是围绕“不同条件怎么组合、为空到底怎么判断”这两个重点展开，同时保持安全实战视角。做接口、做数据分析、做代码审计，或者只在准备网络安全方向面试的人，都应该先把这个基础补扎实。很多线上数据异常，表面看起来是权限或逻辑问题，实际位置往往就是查询条件本身把该带的条件漏掉了。
下面按实际学习的顺序拆：先理解条件查询，再搭复现环境，然后分别讲多条件组合、空值判断、动态条件拼接，最后给一套排查链路。
1. 从零基础到能排查问题：MySQL 条件查询要先会什么
1.1 条件查询不是背语法，而是搞清“留哪几行”
SELECT负责选列，WHERE负责选行。很多人把它理解成“加条件的语句”，这个方向没错，但不够精确。
当数据库执行一句带WHERE的查询时，它会扫描数据行，然后对每一行判断条件是否为真。只有条件结果为真的行，才会进入最终结果。比如：
SELECT id, name, phone, status FROM member WHERE status = 1;这里status = 1是对每一行做的一次布尔判断。为真的保留，为假的丢弃。
难点在于，数据库里除了“真”和“假”，还存在第三种状态，叫“未知”。NULL 参与比较时，结果通常是 NULL，而 NULL 在WHERE逻辑里不等同于假，但也无法让这一行被返回。这一点如果不清楚，后面所有空值判断都会踩坑。
1.2 为什么做接口、数据统计和安全入门都要补这一课
安全方向的初学者容易有一个误区：觉得只要会扫描、会工具、能看报告就够了。但真正进入接口排查、数据校验、日志分析、代码审计这些工作时，最常遇到的不是复杂攻击，而是基础数据查询条件是否正确。
举个典型场景：一个后台页面有多个筛选项，用户不一定每次都会填。比如“按姓名筛选、按手机号筛选、按状态筛选”，用户不填时，查询应该全量返回；填了以后，才把填的那一项当作过滤条件。这个需求靠 Java、Python、Go 都能写，但最终一定会变成 SQL 里的AND条件。如果不会动态拼条件，不会处理空参数，接口要么返回错误结果，要么把用户输入直接拼进 SQL。
所以这里的安全含义不是去构造什么特殊请求，而是反过来：保证查询条件严谨，保证参数安全传递。这也是为什么很多正规项目会把 SQL 注入防护作为必修课，而防护的第一步，就是理解条件查询和参数绑定。
1.3 这篇文章要练成的四个能力
读完并动手执行一遍后，你应该能完成四件事。
第一，能写出多个筛选项组合的查询，并且不会因为AND、OR的优先级问题搞错语义。
第二，能说清楚 NULL 和空字符串的区别，知道为什么phone = NULL查不到数据。
第三，能处理“查询为空”的实际业务需求，比如“查所有没填手机号的用户”“查所有没有邮箱的用户”。
第四，能在动态条件场景里，用参数化的方式拼接查询，而不是把用户输入直接接在 SQL 字符串后面。
这四个能力单看都不难，组合起来就是实际开发和安全审计里最常见的 SQL 功底。
2. 用一张可复现的演示表把空值场景搭起来
2.1 本地环境建议和登录方式
为了避免只看不练，建议本地开启一个 MySQL 环境。手头有 MySQL 5.7 或 8.0 都可以，如果没有，用 Docker 会方便很多，学习环境下不用考虑生产环境的高可用和备份：
docker run -d --name mysql-learn \ -p 3306:3306 \ -e MYSQL_ROOT_PASSWORD=123456 \ mysql:8.0启动后，等十几秒再进入容器日志确认 MySQL 已经初始化完成，然后执行：
docker exec -it mysql-learn mysql -uroot -p密码输入环境变量里设置的123456即可。
如果你本机已经装好了 MySQL，直接登录自己本地实例也可以，不需要额外启动容器。这里唯一要注意的是：端口不能被占用，连接前确认服务状态是正常的。
2.2 建一张带 NULL 和空字符串的演示表
为了把条件查询讲透，我建一张用户表member，字段里故意混合 NULL、空字符串、默认值三种情况。
CREATE DATABASE IF NOT EXISTS sec_learn DEFAULT CHARACTER SET utf8mb4 DEFAULT COLLATE utf8mb4_general_ci; USE sec_learn; CREATE TABLE member ( id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY, name VARCHAR(50) NOT NULL COMMENT '姓名', phone VARCHAR(20) NULL COMMENT '手机号，数据库允许为空', email VARCHAR(100) NULL COMMENT '邮箱，数据库允许为空', status TINYINT NOT NULL DEFAULT 1 COMMENT '状态：1启用，0禁用', remark VARCHAR(255) NULL COMMENT '备注', created_at DATETIME NOT NULL COMMENT '创建时间' ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;插入几条测试数据。注意phone和email字段要故意制造差异化：
INSERT INTO member (id, name, phone, email, status, remark, created_at) VALUES (1, '张三', NULL, '', 1, '普通用户', '2025-06-01 10:00:00'), (2, '李四', '', NULL, 0, NULL, '2025-06-02 11:30:00'), (3, '王五', '13800000001', 'wangwu@test.com', 1, '', '2025-06-03 09:15:00'), (4, '赵六', '13900000002', NULL, 1, '待回访', '2025-06-04 20:45:00');这样，member表里同时包含了：
phone为 NULL 的数据，例如张三。phone为空字符串的数据，例如李四。email为 NULL 的数据，例如李四、赵六。email为空字符串的数据，例如张三。remark为 NULL 和空字符串的数据。
表结构本身不复杂，却能复现大多数空值判断问题。后续所有查询都围绕这张表做，能得到可预期的结果。
2.3 第一条“空值观察”查询
建表后不要急着一口气写各种条件，先看一次全量数据：
SELECT id, name, phone, email, status FROM member;然后执行这句：
SELECT id, name, phone, phone IS NULL AS phone_is_null, phone = '' AS phone_is_empty FROM member;注意看结果里phone_is_null和phone_is_empty这两列：
- 张三是 NULL，所以
phone IS NULL为 1，phone = ''不是 1，而是 NULL。 - 李四是空字符串，所以
phone IS NULL为 0，phone = ''为 1。 - 王五、赵六是正常手机号，两个判断都为 0。
这里已经能看到问题苗头：NULL 和空字符串在显示上看起来都像“没填”，但在 SQL 判断里完全是两回事。
3. 多条件组合查询：先用 AND、OR 和括号把逻辑锁死
3.1 AND 与 OR 的优先级：括号不能省
多条件查询最基础的是AND和OR。AND表示同时满足，OR表示满足其中一个即可。
需要注意，SQL 里AND的优先级高于OR。这个和许多编程语言里&&高于||一样。问题是，人写需求时习惯用自然语言描述，容易把优先级忽略掉。
比如想查“状态为启用，并且手机号没有填写的用户”，按语义应该写：
SELECT id, name, phone, status FROM member WHERE status = 1 AND (phone IS NULL OR phone = '');这里的括号非常关键。它把“手机号为空”这个整体作为一组，再和status = 1取交集。
如果漏掉括号：
SELECT id, name, phone, status FROM member WHERE status = 1 AND phone IS NULL OR phone = '';它的实际语义就变成：找出“状态启用且手机号为 NULL”的用户，再并上“所有手机号为空字符串”的用户。李四状态虽然是 0，但因为手机号是空字符串，也会被查出来。这已经不是预期结果了。
所以在多条件组合里，第一原则是：只要AND、OR混用，就用括号明确分组。不要指望自己和别人凭默认优先级去猜。
3.2 等值、范围、模糊条件组合的常见写法
除了=，条件查询还常用到范围、模糊匹配和集合判断。比如按照创建日期范围查：
SELECT id, name, created_at FROM member WHERE created_at >= '2025-06-01 00:00:00' AND created_at < '2025-06-10 00:00:00';按状态集合查：
SELECT id, name, status FROM member WHERE status IN (0, 1);按邮箱后缀做模糊查询：
SELECT id, name, email FROM member WHERE email LIKE '%test.com';模糊查询里的%表示任意长度字符。email LIKE ''不会匹配 NULL，email LIKE '%'会匹配空字符串，但同样不会匹配 NULL。这个差异也是很多查询结果和直觉不一致的来源。
组合使用时，重点不是背语法，而是保持清晰：
SELECT id, name, phone, email, status FROM member WHERE status = 1 AND (phone IS NOT NULL AND phone <> '') AND email LIKE '%test.com';这个查询表达的是：状态启用，手机号非空且不是空字符串，邮箱包含 test.com。像这种三个条件同时成立的需求，建议把每个条件单独写在括号里，可读性和正确性都会好很多。
3.3 条件复杂以后，排序和行数也要一起看
多条件筛选通常还会接ORDER BY和LIMIT。比如取最新创建的前 5 条：
SELECT id, name, created_at FROM member WHERE status = 1 ORDER BY created_at DESC LIMIT 5;这一步看起来简单，但空值排序经常被忽略。如果某列允许为空，不同数据库对 NULL 的默认排序规则可能不同。与其依赖数据库默认行为，不如自己写清楚。
假设想按email升序排列，并且希望正常邮箱排前面，NULL 和空字符串排后面：
SELECT id, name, email FROM member ORDER BY (email IS NULL OR email = '') ASC, email ASC;这里的排序分为两级：第一级先判断这一行是不是空，是空则值为 1，不是空则值为 0；第二级再对非空的数据按字母排序。这样就不会出现“空值突然插到最前面”的意外。
如果分页查询结果变少，不一定代码错了，也可能是条件本身筛掉的记录太多。排查时要把LIMIT去掉看一眼总行数，而不是只盯着页面上那几条数据。
4. 判断是否为空：NULL、空字符串、默认值要分开处理
4.1 为什么phone = NULL查不到任何数据
这是一个高频问题。
SELECT id, name, phone FROM member WHERE phone = NULL;执行后大概率结果是空。不是语法报错，而是从根上就查不到。
原因在于：NULL 在 MySQL 里不是一个具体值，它表示“不确定”“未知”“没填写”。一个未知的东西和另一个未知的东西用等号比较，结果还是未知，而不是真。
WHERE子句只保留条件为真的行。phone = NULL的结果是 NULL，不是真，所以没有行能通过判断。
因此，判断某列是否为 NULL，不能用等号，必须用IS NULL或IS NOT NULL。
4.2 IS NULL、IS NOT NULL、= '' 的真正区别
只查手机号为 NULL 的用户：
SELECT id, name, phone FROM member WHERE phone IS NULL;结果里明显只会有张三。李四的手机号不是 NULL，而是空字符串，所以不会被查出来。
只查手机号为空字符串的用户：
SELECT id, name, phone FROM member WHERE phone = '';结果只会看到李四，张三还是不会出现。
但如果业务需求是“查所有没有填写手机号的用户”，这里的“没有填写”往往指 NULL 和空字符串都要算。此时必须两个条件都写：
SELECT id, name, phone FROM member WHERE phone IS NULL OR phone = '';结果才会包含张三和李四。
这三个条件写法的区别，是判断为空的核心。以后遇到“查出来少一条”的问题，第一个想法不要是“工具坏了”，而是先确认这一列到底存的是 NULL 还是空字符串。
4.3 IFNULL、COALESCE、NULLIF：从“查空”到“显示默认值”
实际开发里，单纯查询不是终点，还要在结果输出、报表导出时显示默认值。
先看IFNULL。它接收两个参数，第一个是 NULL 时返回第二个，否则返回第一个：
SELECT id, name, IFNULL(email, '未填写') AS email_display FROM member;这个写法会把email为 NULL 的记录显示成“未填写”，但不会处理空字符串。李四的email是 NULL，显示为“未填写”；张三的email是空字符串，显示出来仍然是空的。
如果想把空字符串也当成“未填写”，需要配合NULLIF：
SELECT id, name, COALESCE(NULLIF(email, ''), '未填写') AS email_display FROM member;这段逻辑分两步：
NULLIF(email, '')：如果email等于空字符串，就把它转换为 NULL；如果email本来就是 NULL，结果也是 NULL；如果是正常邮箱，则保持原值。COALESCE从参数列表里从左到右找第一个非 NULL 的值返回。上一步得到 NULL 时，就返回“未填写”。
COALESCE和IFNULL的差别是：COALESCE可以接收多个参数，返回第一个非 NULL 值，适合多列取默认值；IFNULL只适合单列两参数。
4.4 COUNT、JOIN 场景下的空值陷阱
空值问题不只影响WHERE，还会影响统计结果。
比如统计用户总数，以及有多少人填了手机号：
SELECT COUNT(*) AS total_count, COUNT(phone) AS has_phone_count, COUNT(NULLIF(phone, '')) AS has_non_empty_phone_count FROM member;这里有个关键规则：
COUNT(*)统计所有行数。COUNT(phone)不统计 NULL，只统计非 NULL 记录。所以李四手机号是空字符串''，会被计为“有手机号”。COUNT(NULLIF(phone, ''))先把空字符串转换成 NULL，再统计，这时空字符串不会被计入“有手机号”。
如果不注意这个差异，统计报表里很可能多出几个“填写了手机号”但实际上只是空字符串的用户。
JOIN场景也类似。左连接时，右表没有匹配记录，右表字段会以 NULL 返回。此时如果要找“没有关联记录”的行，要用右表主键字段做IS NULL判断，不要错误地用= ''或者= NULL。
更稳妥的判断顺序是：先确认业务上“空”的定义，再看列里实际存的是什么，最后决定用IS NULL、= ''，还是两者组合。
4.5 空值判断场景速查表
下表可以直接保存下来当参考。
| 想查出的数据 | 推荐条件写法 |
|---|---|
| 某列是数据库 NULL | WHERE col IS NULL |
| 某列是空字符串 | WHERE col = '' |
| 某列未填写，NULL 和空串都算 | WHERE col IS NULL OR col = '' |
| 某列已填写，排除 NULL 和空串 | WHERE col IS NOT NULL AND col <> '' |
| 把空串统一转成 NULL 再判断 | WHERE NULLIF(col, '') IS NULL |
| 查询结果显示默认值，NULL 和空串都算未填写 | SELECT COALESCE(NULLIF(col, ''), '默认值') |
| 统计非空且非空串的数量 | COUNT(NULLIF(col, '')) |
你会发现很多条件其实是在同一个字段上反复比较。这也是为什么建表时最好约定统一的空值语义，不能让同一列一半存 NULL、一半存空字符串，否则每个查询都要写两段条件。
5. 进阶实战：不同条件查询背后的动态拼接问题
5.1 需求：用户不填就不查
条件查询最常见的一个实战形态是动态筛选。
假设页面有三个筛选项：姓名、手机号、状态。用户可能只填其中任意几个，也可能什么都不填。开发者需要根据参数是否为空来决定是否把这个条件拼进 SQL。
如果用一句话表达，就是“有值才过滤，没值不影响”。
这个需求直接涉及“判断为空”的理解。这里说的空，不只是WHERE里的字段为空，还包括接口传入的参数为空。
5.2 最容易出错的两种写法
第一种是直接把用户传进来的值拼进 SQL。
# 危险写法示例，仅用于说明，不要执行 sql = "SELECT * FROM member WHERE phone = '" + phone + "'"这个写法有两个问题。
一是语义问题：如果你的程序允许phone参数为空字符串，并且你没判断，SQL 就变成了查“手机号为空字符串”的记录。用户本来只是想看全部，结果却只看到了空手机号用户。
二是安全问题：用户输入一旦被直接接进 SQL，就不是简单的“条件不对”，而是有可能让整条 SQL 的逻辑被改写。这也是所有正规项目都会强调参数化查询的原因。
第二种是把“空字符串”和“不传”混为一谈。一个参数传了空字符串，其含义可能是用户清空了筛选条件，也可能是用户把页面默认值原样提交了。处理动态条件前，先要在应用层把数据清洗干净。
5.3 推荐做法：参数化 + 业务层统一空值语义
推荐的做法分两步。
第一步，在业务代码里接收参数后，先做去空格和规范化处理。比如把空字符串转成 None 或者 null。这样后续判断就统一了：参数是 null，表示不参与过滤；参数有值，才参与过滤。
第二步，动态构造 WHERE 时，只拼接固定的条件和占位符，不拼接用户输入的值。所有值通过数据库驱动传入。
下面是一段通用伪代码：
# 通用伪代码：不同语言的占位符会有差别，核心是参数化传递 where = ["status = %s"] args = [1] name = req.get("name", "").strip() if name: where.append("name LIKE %s") args.append("%" + name + "%") phone = req.get("phone", "").strip() if phone: where.append("phone = %s") args.append(phone) sql = "SELECT * FROM member WHERE " + " AND ".join(where) + " ORDER BY id DESC LIMIT 100" cursor.execute(sql, args)这段代码里，条件片段where是程序自己控制的，不会包含用户输入的值；用户输入的值全部放在args里交给数据库驱动处理。这样写既能实现动态条件，又不会把用户输入直接拼进 SQL。
条件片段本身也不要让用户随便传，比如排序字段最好做白名单限制，否则字段名拼接也会成为问题。
核心原则：条件片段可以拼，占位符可以拼，但用户传入的值永远不要直接接进 SQL。
5.4 一个适合练习的筛选、导出组合查询
现在回到member表，做一个实际练习。
需求：查状态为启用、手机号已填写、备注为空的用户。这里的“手机号已填写”要排除 NULL 和空字符串，“备注为空”要包含 NULL 和空字符串。
SELECT id, name, phone, remark FROM member WHERE status = 1 AND phone IS NOT NULL AND phone <> '' AND (remark IS NULL OR remark = '');在这份数据里，王五状态启用，手机号正常，备注是空字符串，符合条件；赵六状态启用，手机号正常，但备注是“待回访”，不符合条件。
这就是“不同条件组合”和“判断为空”同时出现的完整例子。能独立写出并解释这句 SQL，说明你已经掌握了前面大部分内容。
如果以后要做导出，需要进一步考虑空值显示、文件命名、大数据量分批读取等问题，但查询条件本身的逻辑是一致的。
6. 返回结果不对时，按这个链路排查
6.1 先问一句：空值在你的表里到底长什么样
查询结果不对，第一步不是怀疑 SQL 语法，而是确认数据本身。
打开表结构：
SHOW CREATE TABLE member;看字段设计里有没有NULL。如果有，说明这一列允许存数据库空值；如果业务代码插入数据时又把空字符串也写了进去，就会出现“同一列两种空状态”的情况。
然后再问一句：需求里的“为空”，到底是指数据库 NULL，还是业务上“没填”。这两个概念接近，但条件写法完全不同。
6.2 把 NULL、空字符串和真实数据一次看完整
很多时候你只执行SELECT *，看到空字符串和 NULL 区别不明显，因为空字符串在结果里显示成一个空白，NULL 也显示成一个空白。
推荐用下面这种方式把所有状态一起显示出来：
SELECT id, name, phone, phone IS NULL AS is_null, phone = '' AS is_empty, IFNULL(phone, '[NULL]') AS phone_display, LENGTH(phone) AS phone_length FROM member;LENGTH(phone)在 MySQL 里返回字节长度或字符数取决于版本和字符集，但用来区分 NULL、空字符串和正常值非常直观：
- NULL 的
LENGTH结果是 NULL。 - 空字符串的
LENGTH结果是 0。 - 正常手机号的结果是大于 0 的数字。
看到每一行真实的空值状态后，再回头检查WHERE，大概率能发现自己漏写了OR col = ''或者多写了一个空串判断。
6.3 再怀疑 SQL 逻辑和 JOIN 带来的行数变化
如果数据本身没问题，条件也没写错，就要看是否出现了行数变化。
JOIN 很容易造成两种现象：一是关联字段有重复值时，结果行数膨胀；二是关联字段为 NULL 时，内连接会把行丢掉；外层再叠加 where 条件，结果就更难判断。
排查时把 SQL 拆成最小单位，先用单表WHERE跑一遍，确认结果集合正确后，再逐步加 JOIN、加聚合、加排序、加分页。
如果发现COUNT(phone)的数量和直觉不符，要重新确认统计口径是“非 NULL”还是“非空且有内容”。空字符串会被部分统计函数计入，这点前面已经验证过。
6.4 性能和安全层面的通用建议
普通学习阶段，不需要一上来就研究复杂索引，但要有几个基本意识。
第一，尽量不在查询列上包函数。比如WHERE IFNULL(phone, '') = ''这种写法虽然能判断空，但可能让索引失效。要想兼顾，可以改写成：
WHERE phone IS NULL OR phone = '';第二，如果一个字段经常作为“是否填写”条件来筛选，最好在应用层约定统一值。最省心的方案是给字段设置默认值，比如 `NOT NULL DEFAULT
)