SELECT * 在 JOIN 中危险，因引发额外 IO、拖慢排序分组、撑爆内存；需显式指定字段、子查询预过滤、分离大字段、ORM 精确控制列加载。
为什么SELECT * 在 JOIN 查询里特别危险
它不只是多传几个字段的事。数据库要读取所有列对应的数据页，可能触发额外 IO；如果涉及 TEXT、BLOB 或宽字段（比如含 JSON 的 payload），还会让排序、分组、临时表操作更慢；更糟的是，某些 ORM 默认 SELECT *，连 orders 表的全部字段都拖进来，哪怕你只用其中一两个。
- 执行计划里一旦出现
Using temporary，往往就是宽字段 + 全量列导致内存撑爆 - MySQL 8.0+ 对子查询内联优化较好，但前提是子查询本身不带冗余列
- PostgreSQL 会为每列分配 slot，字段越多，tuple 头部开销越大，尤其在大结果集下明显
如何精准裁剪 JOIN 后的字段列表
核心原则：JOIN 前先收敛列，而不是 JOIN 后再 SELECT 控制——因为优化器通常不会帮你“倒推”裁剪被驱动表的列。
- 显式写出需要的字段，用表别名避免歧义：
SELECT u.id, u.name, o.order_no, o.amount FROM users u JOIN orders o ON u.id = o.user_id - 对被驱动表（如
orders）做子查询预过滤：SELECT u.id, u.name, o_trimmed.order_no FROM users u JOIN (SELECT order_id, order_no FROM orders WHERE status = 'paid') AS o_trimmed ON u.id = o_trimmed.order_id - 确认
EXPLAIN中的rows和Extra字段：若o_trimmed子查询显示rows=100，而全量orders是 100 万行，说明裁剪生效 - 避免无意引入重复字段：两张表都有
created_at，又没指定别名，会导致结果集字段冲突或冗余
大字段（TEXT/BLOB）必须单独处理
它们不参与业务逻辑计算，却严重拖慢 JOIN 流程。数据库必须把整块内容从磁盘读入内存，哪怕你最后根本不用它。
- 用
SUBSTRING(content, 1, 200)截断预览，而非读取完整TEXT字段 - 把大字段拆到独立关联表，例如
article_contents(article_id, full_text)，主表只留id和摘要字段 - 异步加载：应用层先查主 JOIN 结果，再按需发起第二条 SQL 查大字段，避免阻塞主流程
- ClickHouse 等 OLAP 场景中，直接排除大字段列，改用
materialized列或外部文件存储
ORM 场景下怎么避免自动 SELECT *
很多框架默认 eager-load 所有字段，尤其是配置了 @OneToOne 或 @OneToMany 关系后，容易忽略底层 SQL 实际拉了什么。
- JPA/Hibernate：用
@EntityGraph显式定义 fetch graph，或写原生@Query并指定字段列表 - MyBatis：禁用
autoMappingBehavior=FULL，改用autoMappingBehavior=PARTIAL，并始终配<resultmap></resultmap>指定列 - Django ORM：用
.values('id', 'name')或.only('id', 'name')，避免.all()触发全字段加载 - 检查生成的 SQL 日志，确认是否真出现了
SELECT users.*, orders.*—— 这是性能拐点信号
真正卡住性能的，往往不是 JOIN 本身，而是你根本没意识到自己正把 50 个字段、含 3 个 JSON 列的整张表拖进内存。裁剪列不是“省几个字节”，是切断 IO 放大链的第一环。
