从SQL6入门到进阶：SELECT查询、索引失效与SQL注入防御

不管你是刚打开数据库学习网站的新人，还是写了好几年业务代码、SQL 却总靠临时查资料续命的开发者，牛客网 SQL6 这道“查找学校是北大的学生信息”，大概率是你接触到的第一道 SELECT 入门题。它看起来就是一句话的事：从学生表里筛出学校等于北京大学的记录。可真要把这道题吃透，背后串着表设计、字符串比较、索引失效、SQL 注入防御一整条知识链。这篇文章就拿它当引子，把带新人时反复讲的点一次说清楚：题目怎么拆、代码怎么写才规范、围绕这个场景还会踩哪些坑、哪些面试常问的 SQL 基本功需要补。适合刚入门 SQL 的朋友，也适合写了好几年 SQL 但总感觉知识点是一团散沙的人。

1. 题目拆解：先搞清楚这题到底在考什么

1.1 表结构是最容易被忽略的第一步

这类题目一般会给你一张 student 表，字段通常是 id、name、age、school 四件套。以 MySQL 为例，建表语句大概是这个样子：

CREATE TABLE student ( id INT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(50) NOT NULL, age INT, school VARCHAR(100) );

表结构看起来平平无奇，但 school 字段为什么是 VARCHAR(100) 而不是 VARCHAR(20)，其实藏着一个真实业务取舍：学校全称有长有短，字段太短存不下，太长又浪费空间。别小看这个细节，很多系统里学校名是关键主数据，常见做法是单独建一张学校字典表，学生表只存 school_id，查询时再关联出学校名称。但作为入门题，直接存字符串更直观，我们先按这个简单结构来。

题目要的是“学校是北大”，那么问题来了：表里存的是“北京大学”还是“北大”？这直接影响查询条件怎么写。如果表里是“北京大学”，你写 WHERE school = '北大' 就查不到数据；反过来也一样。现实业务中，数据录入往往不受控，用户可能输入“北京大学”，也可能输入“北大”“北京大学本部”，甚至末尾多一个空格。作为开发人员，你不能假设数据一定干净，所以第一步永远是先看数据长什么样，别急着写查询。

1.2 考点拆解：SELECT、WHERE 与字符串等值比较

这道题稳过的方法很简单：

SELECT id, name, age, school FROM student WHERE school = '北京大学';

这段代码里其实有四个基础考点：SELECT 子句用来确定查哪些列；FROM 确定查哪张表；WHERE 负责过滤行；“北京大学”是字符串字面量，单引号不能丢。这些点看着基础，但很多人面试被问“SELECT 的执行顺序”就懵了。实际执行顺序是先 FROM，再 WHERE，再 SELECT，和书写顺序正好相反。这也是为什么你能在 ORDER BY 里使用别名，却不能在 WHERE 里使用 SELECT 中定义的别名——WHERE 的执行早于 SELECT。

SQL 里大小写规则比很多编程语言宽松：关键字大小写无所谓，表名在 Linux 下 MySQL 区分大小写、Windows 下通常不区分；字符串值比较是否区分大小写，取决于排序规则。MySQL 常用的 utf8mb4_0900_ai_ci 或 utf8_general_ci 不区分英文大小写，但中文没有大小写概念，所以这个坑通常出现在英文数据上。刷题平台一般不强制写分号，但标准 SQL 语句以分号结尾，这个习惯会影响你之后迁移到 SQL Server、Oracle 时的写法，建议从一开始就养成。

2. 从能跑通到写得规范：这道题的五种写法

2.1 最基础的答案与它的隐患

大多数人提交的答案就是：

SELECT * FROM student WHERE school = '北京大学';

能过，没问题。但我建议尽早戒掉 SELECT * 的习惯。三个理由：第一，可读性差。三个月后回来看这段代码，你根本不知道表里有哪些字段。第二，容易泄露数据。如果 student 表后来加了 phone、id_card 这类敏感字段，SELECT * 无形中就把它们全部带出去了，排查数据泄露时这就是隐患。第三，SELECT * 在部分场景下会破坏覆盖索引，导致额外回表。单表单次查询可能不明显，多表 JOIN 时差距会被放大。

有人会反驳：“业务里为了赶进度，先 SELECT * 看看数据没问题啊。”我的观点是，可以临时用 SELECT * 做数据探查，但提交到代码评审里的查询，最好显式列出字段。这其实就是最小权限原则在 SQL 里的投影。你不需要的列，就不应该出现在查询结果里。

2.2 规范写法与查询习惯

如果让我写，我一般会写成这样，字段名竖着排开：

SELECT id, name, age, school FROM student WHERE school = '北京大学';

字段名没有特殊字符时不需要加引号；如果字段名和关键字撞车，MySQL 用反引号包起来，SQL Server 用方括号包起来。养成“显式列出字段 + 关键字大写 + 换行对齐”的习惯之后，写复杂查询会清爽很多。另一个容易忽视的问题是排序。除非题目明确要求按某种顺序返回，否则不要假设数据库会按你插入的顺序返回数据。关系数据库的结果集本质上是一个集合，集合是无序的。如果你期望稳定输出，必须加 ORDER BY id；不加 ORDER BY 时，同样的 SQL 两次执行，返回顺序可能不同。这个点很多工作两三年的开发者也说不清楚。

2.3 简单却高频的扩展：去重、去空、看数据

查出结果之后，大家马上会想到另一类问题：表里如果有多条“北京大学”，怎么只显示一次？这就轮到 DISTINCT 出场：

SELECT DISTINCT school FROM student;

注意 DISTINCT 是“整行去重”，不是“只对这一列去重”。如果同时查 name 和 school，只要两个字段组合不完全一样，两行都会保留。这是最容易误解的点之一。

如果担心 school 字段存了空格，可以用 TRIM 清洗后比较：

SELECT id, name, age, school FROM student WHERE TRIM(school) = '北京大学';

但这种写法有代价：对列做函数处理后，school 上的索引就失效了，数据量大时会退化成全表扫描，后面第 3 章会展开讲。还有空值处理。“学校字段为空的学生”怎么查？标准写法是 WHERE school IS NULL，而不是 = NULL。NULL 代表未知，和空字符串完全是两回事。更微妙的是，任何包含 NULL 的算术表达式，结果也是 NULL。这些概念刚学的时候容易混，但面试题特别爱考。

3. 题目之外：字符串查询背后的性能与安全真相

3.1 为什么等号匹配也会慢：索引与选择性

先做个生活化类比：全表扫描相当于你在一个没有分类标签的大仓库里，挨个箱子翻开找“北京大学”的学生档案；索引相当于仓库门口的检索目录，直接告诉你“北京大学”的档案在第几排第几格。几百行数据时，全表扫描毫无感觉；一旦到了百万行级别，差别就是毫秒与秒级的距离。

给 school 建索引很简单：

CREATE INDEX idx_school ON student(school);

但建了索引不一定有用。如果整张表 80% 的学生都来自北京大学，优化器会判断“走索引再回表”不如直接全表扫描，因为需要回表读取的数据太多。这就是“选择性”的概念：越能区分数据行的字段，越适合建索引。学号、身份证号这种唯一字段选择性最高；性别、是否删除这种低区分度字段，即使建了索引，优化器也大概率忽略。真实表设计里，学校名通常只作为筛选条件之一，单独为它建索引未必划算，更常见的是和年级、专业组成复合索引。

3.2 字符集和排序规则：查不到数先别怀疑 SQL

有经验的同事经常遇到这种故障：同一个 SQL，本地库查得到，测试库查不到；代码里写死了“北京大学”，数据库里肉眼也能看到“北京大学”，但 WHERE 就是匹配不上。这种时候第一反应应该是看字符集和排序规则，而不是怀疑 SQL 写错。

MySQL 建表时不指定字符集，就会继承库的默认字符集。如果客户端连接用的是 utf8mb4，而表字段是 latin1，中文字符在写入时可能已经被转换，你在 Navicat 里看到的“正常中文”只是客户端显示做了转换，实际存储的字节已经不对了。排查方法很简单：执行 SHOW CREATE TABLE student; 看字段的 CHARACTER SET；或者把查询条件改成 HEX(school) 看存储的十六进制值，和预期是否一致。

另外，排序规则里 _ci 结尾代表不区分大小写，_bin 代表二进制比较。初学阶段不用背全这些后缀，但要形成意识：字符串比较结果不是天然确定的，它受环境配置影响。出问题时，先把环境对齐，再怀疑 SQL。

3.3 慢查询分析第一步：EXPLAIN

如果你真的遇到“学校是北大”这种查询变慢的情况，正确姿势是先看执行计划：

EXPLAIN SELECT id, name, age, school FROM student WHERE school = '北京大学';

重点看 type 列。常见的几种取值：ALL 是全表扫描；index 是扫描全部索引；range 是范围扫描；ref 是命中普通非唯一索引；const 是唯一索引等值匹配。从性能看，const 最好，依次是 ref、range、index，ALL 最差。如果看到 ALL，说明这条查询没吃到索引；看到 ref，说明 idx_school 生效了；还要顺便看 Extra 列，有没有 Using filesort 或 Using temporary，这两个通常意味着额外开销。

还有一个细节：WHERE school = '北京大学' 这种等值匹配，不加索引时是 ALL，加上普通索引后会变成 ref。但如果像前面那样写成 TRIM(school) = '北京大学'，索引就会失效，执行计划直接变回 ALL。这就是为什么我前面特意强调“函数包裹列”的代价。

3.4 分组与窗口函数：入门题的进阶路径

如果题目变成“按学校统计学生人数”，SQL 就升级成了：

SELECT school, COUNT(*) AS student_count FROM student GROUP BY school;

这就是分组聚合的雏形。再往后，如果你想取“每个学校年龄最小的学生”，又不想因为 GROUP BY 把其他字段丢掉，就会用到窗口函数：

SELECT id, name, age, school, ROW_NUMBER() OVER (PARTITION BY school ORDER BY age) AS rn FROM student;

窗口函数和 GROUP BY 的核心区别是：GROUP BY 会把多行压成一行，窗口函数则在保留所有行的同时，额外计算分组统计结果。刷题平台上有大量这类题目，本质都是“WHERE 过滤 + 分组 + 排序”的组合。把 SQL6 这类等值查询理解透了，后面这些进阶语法都会顺很多。

4. 安全视角：一个看似无害的 WHERE 条件如何变成攻击入口

4.1 拼接字符串的后果

前面讲了这么多 WHERE school = '北京大学'，但真实项目里，“学校”这个值通常不是写死的，而是来自网页搜索框、接口参数。于是最容易写错的就是下面这种代码，以 Java 为例：

String sql = "SELECT id, name, age, school FROM student WHERE school = '" + schoolParam + "'"; Statement stmt = conn.createStatement(); ResultSet rs = stmt.executeQuery(sql);

当 schoolParam 的值是正常“北京大学”时，一切正常。但如果这个参数里包含了单引号和其他 SQL 特殊字符，原本闭合的字符串边界就被破坏了，SQL 语句的语义也随之改变。这就是注入类问题的核心原理：服务端把用户的输入当成 SQL 代码的一部分执行，而不是当纯数据看待。这个原理与具体数据库无关，MySQL、SQL Server、Oracle 都适用。我不打算在这里演示任何绕过语句，因为理解“外部输入不能作为 SQL 结构的一部分”就够了，具体攻击手法再翻新，都离不开这个本质。

4.2 参数化查询是职业底线

正确的写法是参数化查询：

String sql = "SELECT id, name, age, school FROM student WHERE school = ?"; PreparedStatement ps = conn.prepareStatement(sql); ps.setString(1, schoolParam); ResultSet rs = ps.executeQuery();

参数化之后，数据库先把 SQL 语句结构编译好，再把参数作为纯数据传入，参数里的任何特殊字符都不会改变语句结构。这是从根本上解决问题，而不是靠转义。常见的误区是想用字符串替换来“过滤单引号”，那只是临时补丁，遇到编码转换或数据库特性差异时依然可能出问题。

同样的事情在其他语言里也一样：Python 的 pymysql 用 %s 占位符，sqlite3 用 ? 占位符；Node.js 的 mysql2 用 ? 占位符。你不需要背每一种 API，只要记住一条原则：凡是构造 SQL 的地方，参数一律走占位符。这条原则比 SQL 语法本身更值得刻在脑子里。查询类接口往往被认为不像登录接口那么危险，于是不少人只在写入时做参数化，查询条件里却直接拼接，这恰恰是问题高发点。

5. 实操心得：建表、导数据、工具避坑

5.1 用 MyBatis-Plus 实体类生成建表 SQL

如果是 Java 项目，现在很多团队用 MyBatis-Plus。经常有人问：能不能根据实体类自动生成创建表的 SQL？先给结论：MyBatis-Plus 本身没有内置自动建表能力，它的 @TableName、@TableField 等注解是为了映射关系，不能直接变成 DDL。常见做法是先用实体类定义字段，再手动写建表 SQL：

@Data @TableName("student") public class Student { @TableId(type = IdType.AUTO) private Long id; private String name; private Integer age; private String school; }

对应的 DDL 可以写成：

CREATE TABLE student ( id BIGINT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(50) NOT NULL, age INT, school VARCHAR(100) );

为什么不能全自动照搬实体类？因为实体类表达不了索引、唯一约束、字段长度这些设计决策。真正的项目里，表结构变更一般交给 Flyway 或 Liquibase 这类迁移工具管理，每个版本的 DDL 都有记录、可回滚，而不是依赖插件在启动时自动建表。自己练习时，手写 DDL 反而更扎实。

5.2 Navicat 执行和导入 SQL 脚本的踩坑记录

练习时常用 Navicat 导入 SQL 文件。最简单的方法是打开 .sql 文件直接运行，但有几个坑我基本每次带新人都会遇到一次。

第一，编码不对会导致查不到中文。很多从网上下载的 SQL 文件是 GBK 编码，而你的数据库是 utf8mb4，导入后中文全变成问号，或者看起来正常但 WHERE 就是查不到。这个“看起来正常但查不到”的情况极其隐蔽，排查方法也简单：用文本编辑器把 SQL 文件另存为 UTF-8，再重新导入。

第二，导入之前一定要确认当前连的是哪个库。在 Navicat 里，如果你连接的是 mysql 这个系统库，直接运行建表脚本，表就会建到系统库里，后面连数据都找不到。

第三，大数据量 SQL 文件不要用复制粘贴到查询窗口执行，Navicat 对超长脚本的响应会很慢，建议用“运行 SQL 文件”功能，并留意错误日志。中途报错时，大多是脚本中有特殊字符、DELIMITER 没有正确处理，或者字段字符集冲突。错误信息里出现 1366 Incorrect string value 时，基本可以锁定是字符集问题。

5.3 SQL Server 安装与连接问题速查

虽然 SQL6 在 MySQL 上就能做，但不少公司用的是 SQL Server，于是很多新手的第一道坎变成了环境搭建。和这道题相关的典型问题有两类：安装时报“SQL 安装失败”，以及登录时报“已成功与服务器建立连接，但是在登录前”。下面是我整理的排查顺序速查表：

这些问题的共同点是：SQL 本身写对还不够，环境配置不一致会让结果完全不一样。这也是为什么我在前面反复强调字符集和排序规则——这类问题在 SQL Server 里同样存在，只是表现方式变成了“登录失败”或者“中文乱码”。

如果你还在刷入门题，我建议别急着做完就走。拿 SQL6 当引子，把表设计、去重、索引、注入防御、工具操作串一遍，再回头看，收获会比盲刷二十题大很多。我自己的习惯是，遇到“学校字段查不出数据”这种问题，排查顺序永远是：先看数据里有没有空格，再看字符集和排序规则，最后才考虑索引和 SQL 写法。这个排查顺序分享给你，能少走不少弯路。