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 * 可能将密码哈希、身份证号、密钥等敏感字段一并吐出。即便应用层做了脱敏，也增加了漏处理的风险点。 php版微信js-sdk支付接口类 php版微信js-sdk支付接口类 下载 调试时打印日志可能无意记录完整结果集，泄露敏感信息 数据库审计策略通常按语句拦截，SELECT * 难以精准识别意图，不如明确字段便于策略匹配 某些权限模型（如行级/列级权限）对 * 不生效，导致本应屏蔽的列被返回 什么情况下可以谨慎用 SELECT * 仅限临时排查、元数据查询、或已严格约束上下文的场景： 在数据库客户端里快速看两行样例： SELECT * FROM users LIMIT 5 查询系统表或 information_schema，且目标明确（如查所有索引名） 极简脚本用于一次性迁移，且表结构长期稳定、无敏感字段 生产 SQL、API 接口、报表任务、ETL 流程中，一律显式列出所需字段，并按业务语义排序（如主键优先、常用字段靠前）。SQL 查询中 SELECT * 的真实代价
•
👁 0人浏览过