01_查询所有列（解析）

1 题目

查询所有列

2 答案

# 只适合自己看一眼，实际开发中效率低（因为需要将* 转化为每一个列名）
# select * from user_profile;

select id, device_id, gender, age, university, province
from user_profile;

3 select * 和 select 具体列名 的区别

3.1 执行效果（结果集）

数据内容完全一致，只要表结构不变，两者查出的数据行、数值都相同。

3.2 核心差异（重点）

3.1 性能层面

1. SELECT *

   • 数据库需要先解析表结构、查询数据字典，找出全表所有列名，再生成执行计划，多一步元数据查询开销。
   • 会查询所有字段，包含大字段（文本、Blob、长字符串），增加磁盘 IO、网络传输、内存占用，数据量大时明显变慢。

2. SELECT 具体列名

   • 直接指定字段，跳过元数据解析，执行效率更高。
   • 只读取需要列，减少 IO 和网络流量。

分数据量、字段类型、索引三种场景说，结论很直白：

小表 / 数据量很少（几十～几百行）

几乎无差距

数据库解析元数据、多传几个字段的开销可以忽略，两种写法速度感受不到区别。

日常临时查数据，用 SELECT * 完全没问题。

普通表、中等数据量（几千～几万行，无大字段）

差距小幅显现

• SELECT * 多读取、传输无用字段，网络 / IO 略有增加；
• 若有覆盖索引：指定列能走覆盖索引、不回表；SELECT * 基本不走覆盖索引，性能拉开一截。

大表 / 含大字段（TEXT、BLOB、长文本、千万级数据）

差距非常明显

• 大字段会大幅增加磁盘 IO、内存、网络流量，SELECT * 会拖慢查询、挤占数据库资源；
• 全表扫描场景下，列越多，读取的数据页越多，耗时成倍上升。

补充两个关键细节

1. 元数据开销

   SELECT * 需要查表结构字典，单条 SQL 微乎其微；但高频循环执行（接口、循环查询）时，累积开销会变大。

2. 缓存影响

   数据库缓存、应用缓存会按结果集缓存，SELECT * 缓存体积更大，缓存命中率更低。

3.2 维护与兼容性

1. SELECT * 隐患极大

   • 表新增/删除列后，查询结果字段顺序、数量会自动变化，依赖字段顺序的程序（如按索引取值、第三方解析）会直接报错。
   • 视图、存储过程、应用代码难以排查字段来源。

2. SELECT 列名

   • 字段固定，表结构小幅变更不影响现有查询，代码更稳定、易维护。

3.3 索引利用

• 如果查询列全部包含在联合索引/覆盖索引中：
  SELECT 列名 可以走覆盖索引，无需回表，速度极快。
• SELECT * 大概率无法使用覆盖索引，必须回表读取整行数据，性能下降。

3.4 可读性与规范

• SELECT 列名 一目了然，别人能直接看懂查询了哪些字段，符合工程规范。
• SELECT * 语义模糊，生产环境不推荐使用。

3.3 使用场景建议

1. 禁止在生产业务代码使用 SELECT *

   业务查询、接口、报表一律写明确列名。

2. SELECT * 仅适合临时场景

   本地调试、快速查看表数据、临时测试。

3.4 总结

• 结果一样，性能、稳定性、可维护性差距很大。
• 开发规范：业务 SQL 优先写具体列名，拒绝 SELECT *。

针对「查询表所有数据」这个需求：

• 纯临时查看、小表：随便用 SELECT *，性能没影响；
• 业务代码、接口、定时任务、大表：哪怕你确实需要所有列，也建议手写全列名
  • 规避表结构变更带来的 BUG；
  • 保留覆盖索引优化空间；
  • 符合工程规范。