SELECT * 在多表 JOIN 中会显著增加数据体积、触发回表、加重解析与传输开销，并削弱覆盖索引效果，导致数据库、网络和应用层三端冗余负载。
SELECT * 会让 JOIN 后的数据体积暴增
多表 JOIN 本身就会产生笛卡尔积效应，哪怕只是两个小表，SELECT * 也会把所有字段原样拼接。比如 users（10列）和 orders（15列）JOIN，结果集单行就是25列 —— 其中可能包含 users.avatar（BLOB）、orders.description（TEXT）这类大字段。这些字段根本不会被前端展示，却强制走完整条链路：磁盘读取 → 内存组装 → 网络序列化 → 应用反序列化。
覆盖索引在 JOIN 场景下彻底失效
当 JOIN 涉及多个表时，SELECT * 几乎必然触发回表。例如：SELECT * FROM users u JOIN orders o ON u.id = o.user_id WHERE u.status = 'active'，即使 users.status 有索引、orders.user_id 有索引，只要选了全部字段，优化器就无法仅靠索引树完成查询，必须回到主键索引里捞出所有列（包括 users.password_hash 这种敏感且体积大的字段）。而明确指定字段如 SELECT u.id, u.username, o.order_no, o.amount，就可能让联合索引或覆盖索引真正起效。
应用层解析和传输开销被严重低估
- 数据库返回的每行数据都要被 JDBC/ODBC 驱动逐字段解包，字段越多，CPU 时间越长
- JSON/XML 序列化时，
SELECT *导致字段名重复出现（如两个表都有id，就得处理别名冲突） - 网络传输不是按“行”而是按“字节”计费的，10万行 × 多传 2KB/行 = 多压 200MB 流量，TCP 缓冲区和 GC 压力同步上升
ORM 和中间件会放大 SELECT * 的危害
很多 ORM（如 MyBatis、Hibernate）默认把 SELECT * 映射成全字段对象，哪怕你只调用 user.getName()，整个 User 实例（含未使用的 address、profile_json）仍被加载进内存。更隐蔽的是某些分库分表中间件（如 ShardingSphere），对 SELECT * 的列推导不准确，可能误判需要广播查询所有分片。
最常被忽略的一点：SELECT * 在 JOIN 中不是“少写几个字”的懒问题，而是让数据库、网络、应用三端同时承担本可避免的冗余负载。哪怕表不大，只要 JOIN 次数 ≥ 2 或存在大字段，加速效果就立竿见影。
