select * 应避免使用，因其导致性能下降、维护困难和安全风险；仅限临时排查、元数据查询或结构稳定的极简脚本中谨慎使用。
SELECT * 看似省事，实则常埋下性能、维护和安全三重隐患。它不是语法错误，但多数场景下是设计信号不良的标志。
拖慢查询速度：多读、多传、多算
数据库必须加载表中所有字段对应的数据页，即使你只关心其中一两个列。尤其当表含大字段（如 TEXT、BLOB、jsON）或宽表（50+ 列）时，I/O 和网络传输量剧增。执行计划里常看到“Columnstore Index Scan”或“Clustered Index Scan”范围扩大，CPU 解析开销也上升。
- 索引无法覆盖：若只查 id + name，而存在 (id, name) 覆盖索引，SELECT * 会强制回表或全表扫描
- 内存压力变大：结果集膨胀导致 Buffer Pool 挤占、排序/哈希操作更易落盘
- 应用层反序列化成本增加：ORM 将多余字段映射为对象属性，徒增 GC 压力
破坏代码可维护性：隐式耦合与意外变更
用 SELECT * 的应用，实际依赖了表的当前列顺序、名称和类型。一旦 dba 添加、重命名或删减字段（比如新增 deleted_at、调整 enum 字段），应用可能静默出错：字段错位、类型不匹配、空值注入等。
- ORM 自动生成实体类时，可能把新字段映射成非空属性，引发 NullPointerException
- 下游视图或物化视图依赖该查询结果，结构变动直接导致依赖失效
- sql 审计和慢日志分析困难：无法快速识别哪几个字段真正被业务使用
带来潜在安全风险：数据越权暴露
前端或 API 层若不做字段过滤，SELECT * 可能将密码哈希、身份证号、密钥等敏感字段一并吐出。即便应用层做了脱敏，也增加了漏处理的风险点。
- 调试时打印日志可能无意记录完整结果集，泄露敏感信息
- 数据库审计策略通常按语句拦截，SELECT * 难以精准识别意图，不如明确字段便于策略匹配
- 某些权限模型（如行级/列级权限）对 * 不生效，导致本应屏蔽的列被返回
什么情况下可以谨慎用 SELECT *
仅限临时排查、元数据查询、或已严格约束上下文的场景：
- 在数据库客户端里快速看两行样例：SELECT * FROM users LIMIT 5
- 查询系统表或 information_schema，且目标明确（如查所有索引名）
- 极简脚本用于一次性迁移，且表结构长期稳定、无敏感字段
生产 SQL、API 接口、报表任务、etl 流程中，一律显式列出所需字段，并按业务语义排序（如主键优先、常用字段靠前）。