夜雨聆风💬前言
不会写SQL，只能等着开发帮忙查数据，工作效率极低 接口返回数据不对，不会核对数据库底层数据，定位不了bug 造测试数据太慢，不会批量插入，加班造数据成为常态 一不小心写错删改语句，差点删库跑路，心慌一整天
📌一、测试先须知：数据库基础+测试操作红线
1. 测试常用核心名词
数据库：独立业务库，比如订单库、用户库、支付库 数据表：拆分业务数据，用户表、订单表、流水表 字段：表内具体数据，用户名、手机号、订单状态、创建时间 主键：数据唯一标识，精准定位单条测试数据 事务：下单、支付联动业务，测试数据回滚、异常场景必备
2. 测试SQL操作红线
绝对禁止线上执行以下语句： 1. DELETE / UPDATE 不带WHERE条件（全表清空/全表修改，线上重大事故） 2. 线上随意执行TRUNCATE清空整张数据表 3. 大表不加LIMIT全表查询，直接拖垮数据库，接口全部超时 通用规范：改数据前，先用SELECT查询核对数据，无误再执行更新/删除 |
🗂️二、DDL库表操作：测试临时建表、改表结构
sql-- 查看所有数据库SHOW DATABASES;-- 切换业务库（所有SQL执行前必写）USE order_db;-- 查看库内所有数据表SHOW TABLES;-- 查看表结构（日常高频：核对字段类型、长度、是否允许为空）DESC user_info;-- 快速复制表结构+数据（备份线上数据到测试库）CREATE TABLE user_info_bak AS SELECT * FROM user_info;-- 只复制表结构，不复制数据CREATE TABLE user_info_temp LIKE user_info;-- 新增字段（验证接口新增字段兼容）ALTER TABLE user_info ADD email VARCHAR(100) COMMENT '邮箱'; |
🔍三、DML核心增删改查（测试90%工作都用这里）
1. SELECT 查询语句（测试最最最高频！数据核对、bug排查）
✅ 基础查询
sql-- 指定字段查询（工作规范，禁止无脑SELECT *）SELECT id,user_name,phone,status FROM user_info;-- 结果去重（排查重复注册、重复订单bug）SELECT DISTINCT phone FROM user_info;-- 分页查询（防止查询数据过多卡死工具）SELECT * FROM user_info LIMIT 100; |
✅ WHERE条件过滤（精准定位异常数据）
sql-- 查询指定手机号用户SELECT * FROM user_info WHERE phone = '13800138000';-- 多条件：正常状态 + 成年用户SELECT * FROM user_info WHERE status=1 AND age >= 18;-- 模糊查询：查询所有测试账号SELECT * FROM user_info WHERE user_name LIKE '测试%';-- 查询手机号为空的异常数据（注意：空值不能用=NULL）SELECT * FROM user_info WHERE phone IS NULL; |
✅ 排序 + 聚合统计（对账、报表接口测试）
sql-- 查询最新100条订单，倒序查看SELECT * FROM order_info ORDER BY create_time DESC LIMIT 100;-- 聚合函数：统计用户总数、订单总金额SELECT COUNT(*) 用户总数 FROM user_info;SELECT SUM(order_amount) 订单总金额 FROM order_info;-- 分组统计：按天统计每日下单量（对账刚需）SELECT DATE(create_time) 下单日期,COUNT(order_id) 订单数量FROM order_infoGROUP BY DATE(create_time)ORDER BY 下单日期 DESC; |
✅ 联表查询（测试高阶必备：排查整条业务链路bug）
sql-- 左联三表：查询用户-订单-支付完整链路，找出漏支付异常订单SELECT u.user_name,o.order_id,p.pay_statusFROM user_info uLEFT JOIN order_info o ON u.id = o.user_idLEFT JOIN pay_record p ON o.order_id = p.order_idWHERE DATE(o.create_time) = CURDATE(); |
2. INSERT 插入数据（批量造测试数据）
sql-- 单条插入测试用户INSERT INTO user_info(user_name,phone,age) VALUES('测试001','13800011111',22);-- 【测试神器】批量插入，一键造多条测试数据INSERT INTO user_info(user_name,phone,age)VALUES('测试002','13800011112',23),('测试003','13800011113',24),('测试004','13800011114',25); |
3. UPDATE 更新数据（修改订单状态、重置测试账号）
核心提醒：UPDATE必须加WHERE！！！ |
sql-- 修改指定用户手机号UPDATE user_info SET phone='13900022222' WHERE id=1001;-- 批量修改所有测试账号为禁用状态UPDATE user_info SET status=0 WHERE user_name LIKE '测试%' LIMIT 200; |
4. DELETE 删除数据（清理测试环境脏数据）
sql-- 删除单条异常数据DELETE FROM user_info WHERE id=9999;-- 批量清理7天前过期测试数据DELETE FROM order_info WHERE create_time < DATE_SUB(NOW(),INTERVAL 7 DAY) LIMIT 1000; |
🧰四、测试高频内置函数
1. 时间函数（使用率最高，时间段查询必备）
sql-- 查询今日所有订单SELECT * FROM order_info WHERE DATE(create_time) = CURDATE();-- 查询近7天订单数据SELECT * FROM order_info WHERE create_time >= DATE_SUB(NOW(),INTERVAL 7 DAY); |
2. 状态转换函数（数字状态转文字，对账一目了然）
sql-- 订单状态数字转中文，不用对照文档看懂状态SELECT order_id,CASE order_statusWHEN 0 THEN '待下单'WHEN 1 THEN '待支付'WHEN 2 THEN '已支付'WHEN 3 THEN '已取消'ELSE '异常订单' END AS 订单状态FROM order_info; |
🔎五、测试专属实战SQL模板
模板1：排查已下单但是未支付的漏单bug（高频）
sqlSELECT o.order_id,o.user_id,o.create_timeFROM order_info oLEFT JOIN pay_record p ON o.order_id = p.order_idWHERE p.id IS NULL; |
模板2：每日订单对账统计
sqlSELECT DATE(create_time) 日期,COUNT(order_id) 订单数,SUM(order_amount) 交易总额FROM order_infoGROUP BY DATE(create_time)ORDER BY 日期 DESC; |
模板3：批量重置所有测试账号状态
sqlUPDATE user_info SET status=1 WHERE user_name LIKE '测试%' LIMIT 500; |
模板4：查询接口超时的大数量脏数据
sqlSELECT * FROM order_info WHERE create_time < DATE_SUB(NOW(),INTERVAL 15 DAY); |
📊六、MySQL/Oracle/SQLServer语法差异（多数据库项目必看）
功能 | MySQL（测试最常用） | Oracle | SQLServer |
获取当前时间 | NOW() | SYSDATE | GETDATE() |
分页查询 | LIMIT | ROWNUM | OFFSET FETCH |
自增主键 | AUTO_INCREMENT | 序列SEQUENCE | IDENTITY |
❌ 七、测试写SQL避坑10条清单（拒绝删库跑路）
UPDATE、DELETE 永远不要省略WHERE条件 线上环境严禁使用TRUNCATE清空数据表 大表查询必须加LIMIT，避免全表扫描压垮服务 判断空值只能用IS NULL，禁止 = NULL 尽量不用前后模糊查询%xxx%，不会走索引，接口容易超时 批量更新、删除一定要加LIMIT分批操作，防止锁表 时间查询不要用函数包裹索引字段，会导致索引失效 改数据前先SELECT校验条件，确认无误再执行 测试环境可以随意操作，线上仅允许只读查询 复杂修改语句，优先让开发review之后再执行