你是不是写 SQL 时总爱用 SELECT *？

方便一时爽，事后火葬场！ 轻则性能暴跌，重则数据泄露！

下面7大七大隐藏陷阱分享完后，可别再跳了！

1. 🚀 性能杀手：你的数据库被它「榨干」了！

场景：你查个用户昵称，却把头像、日志等大字段全拖出来！

真相：

• 📉 网络爆炸：SELECT * 会返回表中所有列，包括未被使用的字段。如果表中包含 TEXT/BLOB 等大字段或列数较多，会显著增加网络传输和内存开销，尤其是当查询仅需要少量列时。
• 💔 **索引罢工**：如果查询可以通过覆盖索引（Covering Index）完成（即索引包含所有需要的列），使用 SELECT * 可能导致 MySQL 不得不回表查询实际数据，降低性能。明明有索引，却非要逼数据库「翻硬盘找数据」，查询速度直接打骨折！

正确姿势：

SELECT 昵称, 手机号 FROM 用户表;  -- 只拿刚需，快如闪电！  

2. 💣 新增一列竟让代码崩了？

列顺序或数量变化：

如果表结构后续新增或删除列，SELECT * 会返回不同的结果集，可能导致应用程序逻辑错误（例如通过列索引位置读取数据）。若表中新增了敏感字段（如 password），SELECT * 可能意外泄露数据。

保命法则：

• 永远按列名取数据，避免依赖隐式结构，别赌表结构不变！
• 敏感字段用 视图 或 **权限控制**，防止手滑暴雷！
  

3. 🤯 JOIN 修罗场：同名「id」引发数据尸横遍野！

其他人阅读代码时无法快速了解实际需要的列，尤其是在多表 JOIN 时。

经典翻车：

SELECT * FROM 用户表 JOIN 订单表...  -- 结果集惊现两个「id」！  

结局：代码按顺序读数据，用户 ID 和订单 ID 疯狂覆盖，财务报表直接变天书！

避坑神技：

SELECT 用户.id AS 用户ID, 订单.id AS 订单ID...  -- 加别名，世界和平！  

4. 💸 ORM 框架的「内存黑洞」：没用到的字段也在烧钱！

扎心真相：

你用 MyBatis 查 SELECT *，框架默默创建了包含所有字段的对象！

内存暴涨、GC 疯转，老板看着账单当场心梗！💔

省内存秘籍：

<select id="getUser">  
   SELECT 账号, 昵称 FROM 用户表  -- 只拿需要的，拒绝内存霸凌！  
</select>  

5. 📉 分页慢成狗？罪魁祸首竟是它！

性能对比：

• SELECT * 翻页 100 万数据：10 秒加载，用户怒关页面！
• SELECT 订单号 翻页：0.1 秒响应，老板夸你加鸡腿！🍗

加速奥义：

覆盖索引 + 精准查列，分页快到飞起！

6. 🕵️ 最冤种的 EXISTS：你以为省事，实际白干！

反直觉真相：

SELECT * FROM 用户 WHERE EXISTS (SELECT * FROM 订单...);  

优化器冷笑：SELECT * 有个卵用？我早帮你改成 SELECT 1 了！

优雅姿势：

SELECT * FROM 用户 WHERE EXISTS (SELECT 1 FROM 订单...);  -- 专业感拉满！  

7. 👻 同事追杀警告：代码写成天书，谁敢维护？

血泪控诉：

• 新人看到 SELECT *：这代码要查啥？我裂开了！
• 字段增减后：全局搜索 SELECT * 改到吐血，直接提离职！

职场保命：

列名写全，同事跪谢！代码即文档，升职加薪稳了！💰

🔥 文末总结：

1️⃣ 禁用 SELECT *，精准查列是尊严！

2️⃣ JOIN 必加别名，EXISTS 改用 SELECT 1！

3️⃣ 敏感字段上锁，索引设计要「覆盖」！

转发这份避坑指南，救救那个还在用 SELECT * 的冤种同事！ 👇

阅读原文：原文链接