⌕
🛒项目实战📦资料包🛠测试神器AIAI路线CV简历测评🧭入行测评🧪测开测评🎯训练营🏆案例❤赞赏我

2. SQL 基础查询面试怎么准备？

SQL 基础查询是数据库测试的基本功。很多同学准备数据库面试时喜欢背概念，比如 select 怎么写、where 怎么用、order by 是排序、limit 是分页。但真正面试时，面试官更关心的是：你能不能把 SQL 用到测试场景里，能不能通过 SQL 校验页面和接口背后的真实数据，能不能在出现问题时用 SQL 快速定位原因。

所以准备 SQL 基础查询，不应该只是背语法，而应该按照“业务动作 -> 数据变化 -> SQL 验证”的方式训练。例如用户注册后应该查用户表；下单后应该查订单表；支付后应该查订单状态和支付流水；删除后应该查逻辑删除标记；列表查询后应该用 SQL 验证筛选条件、排序和分页。这样准备出来的 SQL，才是测试工程师面试中真正有价值的 SQL。

一、SQL 基础查询到底要掌握什么

测试岗位不要求你一开始就写复杂存储过程，也不要求你像 DBA 一样调优数据库。但最常用的基础查询必须熟练。

1. select 查询字段

select 用来指定你要看哪些字段。测试时不要总是 select *，尤其是表字段很多时，建议只查你关心的字段。

select id, username, mobile, status, create_time
from t_user
where mobile = '13800000000';

这样查出来的结果更清晰，也方便截图给开发定位问题。

2. where 条件过滤

where 是测试查数据最常用的条件。你可以根据手机号、订单号、用户 ID、状态、时间范围过滤。

select order_no, user_id, status, total_amount, create_time
from t_order
where order_no = 'NO202604300001';

测试时要注意条件是否唯一。如果用姓名查用户，可能查出多条；用手机号或订单号通常更准确。

3. and / or 组合条件

业务查询经常需要多个条件组合。比如查某个用户今天创建的待支付订单：

select order_no, status, total_amount, create_time
from t_order
where user_id = 1001
  and status = 'WAIT_PAY'
  and create_time >= '2026-04-30 00:00:00'
  and create_time < '2026-05-01 00:00:00';

注意 and 和 or 混用时要加括号，否则结果可能和你想的不一样。

4. like 模糊查询

like 常用于搜索功能测试。例如页面支持按商品名搜索“自动化”，你可以用 SQL 验证数据库里符合条件的数据：

select id, product_name, status
from t_product
where product_name like '%自动化%';

但要知道，前后都加 % 的模糊查询通常不容易命中普通索引，大数据量时可能慢。面试时如果能顺带提到这一点，会显得你不只是会写语法，也懂性能风险。

5. in 和 not in

当你要查询多个状态或多个 ID 时，in 很常用。

select order_no, status
from t_order
where status in ('WAIT_PAY', 'PAID', 'CANCELLED');

测试列表筛选时，状态多选就经常会对应 in 条件。

6. between 时间范围

时间范围查询非常常见，比如查今天订单、最近 7 天支付记录、某个活动周期报名数据。

select order_no, pay_amount, pay_time
from t_pay_record
where pay_time between '2026-04-30 00:00:00' and '2026-04-30 23:59:59';

实际项目中更推荐使用左闭右开：

where pay_time >= '2026-04-30 00:00:00'
  and pay_time < '2026-05-01 00:00:00'

这样可以避免毫秒精度导致的数据遗漏。

7. order by 排序

列表测试经常要验证排序。比如订单列表按创建时间倒序：

select order_no, create_time
from t_order
where user_id = 1001
order by create_time desc;

asc 是升序，desc 是降序。默认通常是升序，但面试回答时不要只说默认，最好说清楚实际测试会看需求要求。

8. limit 分页

分页查询常见于列表页。MySQL 中常见写法：

select order_no, create_time
from t_order
order by create_time desc
limit 0, 10;

第一页 10 条是 limit 0,10，第二页是 limit 10,10。测试分页时要验证总数、每页数量、翻页后数据是否重复或遗漏。

9. count 统计数量

count 常用于验证列表总数、报表数量、报名人数、订单数。

select count(*)
from t_order
where status = 'PAID';

面试可能追问 count(*)、count(1)、count(字段) 区别。简单理解：count(*) 和 count(1) 都是统计行数，具体性能差异不要乱说；count(字段) 只统计该字段非 null 的行。

10. distinct 去重

去重常用于统计唯一用户、唯一订单、唯一手机号。

select count(distinct user_id)
from t_order
where create_time >= '2026-04-01 00:00:00';

如果报表统计“下单用户数”，通常不能直接 count(*)，而要统计去重用户数。

二、基础查询在测试中的典型使用场景

1. 注册和登录场景

用户注册后，可以根据手机号查用户表：

select id, mobile, status, create_time
from t_user
where mobile = '13800000000';

关注点包括：是否生成用户记录、手机号是否正确、状态是否启用、创建时间是否正确、默认角色是否绑定。如果系统有账号表和用户表，还需要继续查关联表。

2. 订单创建场景

下单后根据订单号查订单：

select order_no, user_id, status, total_amount, create_time
from t_order
where order_no = 'NO202604300001';

如果只是创建订单，状态应该是待支付；如果金额字段和页面不一致，就要继续查订单明细表。

3. 支付场景

支付成功后至少查订单状态和支付流水：

select order_no, status, pay_status, pay_time
from t_order
where order_no = 'NO202604300001';

select pay_no, order_no, pay_amount, pay_status
from t_pay_record
where order_no = 'NO202604300001';

如果订单已支付但流水不存在，这是严重一致性问题。

4. 删除场景

删除后要看是真删除还是逻辑删除：

select id, title, is_deleted, update_time
from t_article
where id = 2001;

如果需求是逻辑删除，那么记录应该还在，只是 is_deleted 变成 1。如果需求是真删除，查询应该无结果。

5. 列表查询场景

比如后台订单列表按状态、时间、手机号筛选，你可以用 SQL 复核：

select order_no, status, create_time
from t_order
where status = 'PAID'
  and create_time >= '2026-04-01 00:00:00'
  and create_time < '2026-05-01 00:00:00'
order by create_time desc
limit 0, 20;

这类 SQL 能验证筛选条件、排序、分页是否正确。

三、面试中容易被追问的基础点

1. where 和 having 有什么区别？

where 是分组前过滤原始数据，having 是分组聚合后过滤结果。比如筛选已支付订单用 where status='PAID'；统计每个用户订单数后，只看订单数大于 3 的用户，就用 having count(*) > 3。

2. order by 默认升序还是降序？

默认升序，也就是 asc。但测试时不要依赖默认值，最好 SQL 中明确写 asc 或 desc。

3. limit 怎么做分页？

MySQL 中 limit offset, size，第一页 offset 是 0，第二页 offset 是 pageSize，第 N 页 offset 是 (pageNo - 1) * pageSize。

4. count(*) 和 count(字段) 区别？

count(*) 统计行数，包含字段为 null 的行；count(字段) 只统计该字段不为 null 的行。测试报表时要根据业务含义选择。

5. like '%关键字%' 有什么问题？

能做模糊搜索，但大数据量时可能慢，因为前置 % 通常不利于普通索引使用。搜索类功能如果数据量大，可能需要全文索引或搜索引擎。

四、面试回答模板

如果面试官问“你 SQL 基础怎么样，平时怎么用 SQL 做测试”，可以这样答：

我平时主要用 SQL 做数据校验和问题定位。基础查询方面，常用 select、where、order by、limit、count、like、in 这些语法。比如测试注册功能时，我会根据手机号查用户表确认是否落库；测试订单功能时，会根据订单号查订单状态、金额和创建时间；测试列表页时，会用 SQL 复核筛选条件、排序、分页和总数。对于统计类页面，我会用 count 或 sum 进行复算。我的理解是 SQL 不是单纯背语法，而是要和业务动作绑定，确认页面和接口背后的数据是否正确。

五、一个完整的测试案例：订单列表筛选

假设需求是：后台订单列表支持按订单状态、手机号、时间范围筛选，并按创建时间倒序展示，每页 10 条。

测试步骤可以这样设计：

  1. 准备不同状态订单，包括待支付、已支付、已取消；
  2. 准备不同用户手机号订单；
  3. 准备不同创建时间订单；
  4. 页面选择状态为“已支付”；
  5. 输入手机号；
  6. 选择时间范围；
  7. 验证页面列表数据；
  8. 用 SQL 复核。

SQL 示例：

select order_no, mobile, status, create_time
from t_order
where status = 'PAID'
  and mobile = '13800000000'
  and create_time >= '2026-04-01 00:00:00'
  and create_time < '2026-05-01 00:00:00'
order by create_time desc
limit 0, 10;

还要查总数：

select count(*)
from t_order
where status = 'PAID'
  and mobile = '13800000000'
  and create_time >= '2026-04-01 00:00:00'
  and create_time < '2026-05-01 00:00:00';

这样你就能验证页面列表和分页总数是否一致。

六、常见错误和避坑

1. 查错环境

很多测试事故不是 SQL 写错，而是连错数据库。测试环境、预发环境、生产环境要确认清楚。

2. 条件不唯一

用姓名、昵称查数据容易查出多条。尽量用手机号、订单号、ID、唯一流水号。

3. 时间范围漏数据

使用 23:59:59 可能遗漏毫秒数据。建议左闭右开。

4. 忘记状态条件

很多表有逻辑删除、状态字段。如果忘记 is_deleted=0 或状态过滤，查出来的数据可能和页面不一致。

5. 不理解业务字段

字段名叫 status 不代表你知道它含义。要结合字典表、接口文档或开发说明确认状态枚举。

七、练习清单

建议你至少能独立写出下面这些 SQL：

  1. 根据手机号查询用户；
  2. 查询今天创建的订单；
  3. 查询待支付订单并按创建时间倒序；
  4. 查询某用户最近 10 条订单；
  5. 统计已支付订单数量；
  6. 统计某活动报名人数；
  7. 查询商品名包含“自动化”的商品；
  8. 查询状态在多个值中的工单；
  9. 查询逻辑删除数据；
  10. 查询某天 0 点到第二天 0 点的数据。

SQL 基础查询不是难点，难点是把它用到业务测试里。你准备面试时，每个语法都要配一个真实测试场景，这样回答才不会像背书。

配套刷题：

相关推荐

下一步可以看这些

面试通关软件测试面试通关系列精华文章

把面试题、项目、简历和训练营串成一套求职准备路径。

入行路线零基础入行软件测试专题路径

从测评、学习路线、项目、简历到面试，按顺序入行。

进阶路线初中级测试进阶高级专题路径

接口自动化、性能测试、CI/CD、复杂业务质量保障进阶路线。

AI 方向AI 测试学习路线专题页

大模型评测、RAG 测试、Agent 测试和 AI 自动化路线。

求职结果Offer 案例 / 学员案例展示

看看真实学员 Offer 案例，判断目标和学习投入是否匹配。

资料 / 交流群添加小牛微信

备注：资料、简历、AI 或找工作，领取对应资料或进交流群。

添加小牛微信