【MySQL】查询数据（关键字：SELECT）——SELECT * 的优缺点及使用建议

我是一名立志把细节都说清楚的博主，欢迎关注🎉 ~
原创不易，如果有帮助，还请鼓励个【赞】哦~ ❥(^_-)~

查询单个列

最基础的查询格式：

# 查询 字段名 从 表名
SELECT 字段名 FROM 表名; 

示例：

# 查询 名称 从 学生表
SELECT name FROM student;

SQL语句结尾：

• 多条SQL语句必须以分号结尾（ ; ）。
• 单条SQL语句虽然不强制要求以分号结尾，但是推荐平时也以分号结尾，养成良好的小习惯，不容易产生错误。

SQL语句大小写：

• SQL语句默认不区分大小写。修改MySQL配置可以区分大小写。
• 推荐习惯：SQL关键词大写，表名、列名小写。这么做的好处：
  1. 易于阅读、调试。
  2. 符合开发规范。（下方有引用）
  开发规范要求表名、列名为小写，我们查询的SQL语句尽量也与其保持一致使用小写，即使出现MySQL调整过配置，设置为严格区分大小写的情况，我们也能保证数据正常查询。

格式优化：

• SQL语句中的多余空格会被忽略。
• SQL语句可以是一行，也可以使用回车将其分为多行。
• 推荐灵活的使用上面两个机制，可以将复杂的SQL语句拆分成多行，更容易阅读、调试。

开发规范参考：《Java开发手册2022》（黄山版）五、MySQL数据库（一）建表规约 第2条

2.【强制】表名、字段名必须使用小写字母或数字，禁止出现数字开头禁止两个下划线中间只出现数字。数据库字段名的修改代价很大，因为无法进行预发布，所以字段名称需要慎重考虑。
说明：MySQL 在 Windows 下不区分大小写，但在 Linux 下默认是区分大小写。因此，数据库名、表名、字段名，都不允许出现任何大写字母，避免节外生枝。
正例：aliyun_admin，rdc_config，level3_name
反例：AliyunAdmin，rdcConfig，level_3_name

---

查询多个列

# 查询 ID、名称、年龄、班级 从 学生表
SELECT id, name, age, grade FROM student;

• 列名与列名之间必须使用英文逗号（ , ）分割，中文逗号不行。
• 最后一个列名后面不能再连接符号，否则会报错。

---

查询所有列（星号通配符：* ）—— SELECT * 优缺点及使用建议

# 查询 所有列 从 学生表
SELECT * FROM student;

星号通配符编写SQL语句简单快捷，但是不推荐在工作的生产环境使用。主要是因为使用 select * 的缺点大于优点。具体分析如下：

优点总结：简单、快捷、省力。

1. 无须拼写列名，减少代码工作量。
2. 直接避免拼写错误，免去核对拼写。
3. 提高代码复用率。表数据模型变更，无须核对修改 SQL。

缺点总结：过度查询，浪费性能，增加耗时，安全隐患，不利维护。

1. 查询全部列数据，有些列数据并不会用到，增加查询分析器解析成本，造成查询性能浪费。
2. 对于无用的大字段，如：text等类型字段，会增加磁盘IO开销。
3. 过多无用的信息传输过程，也必会加重网络时延负担。
4. select * 会走全表扫描，无法使用覆盖索引，导致查询效率非常低。
5. 可能会拖慢JOIN连接查询。
6. 由于 select * 查询全部列数据，缺少对列数据的筛选的过程，如果数据表中包含（或后期增加）敏感信息列，直接使用 select * 查询语句，有写场景可能会造成敏感数据泄露。
7. 数据库表模型变更， select * 直接查询返回，可能会导致查询结果与resultMap匹配不一致。

开发规范参考：《Java开发手册2022》（黄山版）五、MySQL数据库（四）ORM映射 第1条

1.【强制】在表查询中，一律不要使用 * 作为查询的字段列表，需要哪些字段必须明确写明。
说明：
1）增加查询分析器解析成本。
2）增减字段容易与 resultMap 配置不一致。
3）无用字段增加网络消耗，尤其是 text 类型的字段。

适用场景

我个人感觉有些场景还是可以考虑使用：

• 临时查询使用。
• 自己学习演练需要快速开发使用（时间充足还是应该按规范来，养成良好的习惯也很重要，看情况取舍吧）。
• 在不知道表列名的情况，偶尔需要快速查询出所有的列数据。
• 敏捷开发早期阶段，阶段目标是：从无到有，开发工作时间紧，任务重，并且经常变动数据库模型。
  • 按多个具体列名查询，维护成本过高（这个阶段数据库模型可能会经常变动，一变动就需要去纠正、核对代码、模型），造成时间精力的浪费，对开发带来一定压力负担。
  • 这个时候可以作为一个临时应急处理方案，但这仅仅只是临时应急处理方案。在上正式生产环境前，还是要尽可能的完成代码规范优化工作
  • 如果实在不行，也要注意在版本迭代中实现从有到优的基本理念。

总之，大的原则就是：在工作的正式代码环境坚决不用。其次能不用就不用，如果要用，也尽量是少用、临时应急一下用。

---

弥补SELECT * 缺陷的优化方案

在纯SQL层面，似乎没有比较合适的替代方案。
但是我们在实际开发过程中，我们可以在DAO层面，对xml文件中的SQL编写进行优化：

我们可以根据场景需要，对于部分需要重复查询的列，可以抽取出公共用列，进行复用，从而减少一定工作量，同时也提升了一定的易维护性。

定义不同的场景使用的公共用列：

<!-- 根据具体场景，抽取查询需要的公共用列（一定程度上可以减少工作量） -->
<sql id="baseInfo">
    <![CDATA[
		id,
		student_id
		student_name,
		age,
		grade,
		address,
		parent_name,
		parent_telephone_number,
	]]>
</sql>

<sql id="homeInfo">
    <![CDATA[
		id,
		student_id
		address,
		parent_name,
		parent_telephone_number,
	]]>
</sql>

下面是复用示例：

<!-- 查询全部学生的基础信息 -->
<select id="selectAllStudent" resultMap="studentResultMap">
	SELECT 
	<include refid="baseInfo" />
	FROM student
</select>

<!-- 根据ID查询学生的基础信息 -->
<select id="selectStudentById" resultMap="studentResultMap">
	SELECT 
	<include refid="baseInfo" />
	FROM student
	WHERE student_id = #{studentId}
</select>

我是一名立志把细节都说清楚的博主，欢迎关注🎉 ~
原创不易，如果有帮助，还请鼓励个【赞】哦~ ❥(^_-)~