SELECT列过多会显著增加网络传输量、磁盘IO、内存占用、CPU开销及客户端解析负担。例如查1000行含大字段的用户表，传输量可达几MB，而只选关键字段不足100KB；JOIN宽表更易触发内存溢出或磁盘临时表。
SELECT列过多直接增加网络传输字节数
数据库返回给客户端的数据，是按行序列化后通过 TCP 协议传输的。每多一个字段，就多传一份该字段的值（含长度前缀、NULL 标记等协议开销）。比如 SELECT * 从一张含 avatar_url（VARCHAR(512)）、bio（TEXT）和 settings_json（JSON）的用户表查 1000 行，实际传输量可能达几 MB；而只选 id, username, email，往往不到 100 KB。
大字段（BLOB/TEXT/VARCHAR 超长）会触发额外 IO 和内存拷贝
MySQL InnoDB 中，当单字段长度超过 728 字节时，数据会被外置存储（off-page），查询时需额外一次磁盘 IO 读取；同时服务端需在内存中拼装完整记录再发给客户端，这会拉高 CPU 和 buffer pool 压力。
-
TEXT或BLOB字段哪怕没被业务使用，只要出现在SELECT列表里，就会被加载 - ORM 框架默认
SELECT *时，极易把日志字段、审计字段、冗余 JSON 字段全拖出来 - 即使 DB 和应用部署在同一台机器，走的仍是本地 loopback TCP，仍有协议栈开销和上下文切换成本
客户端解析与反序列化负担同步上升
接收方（如 Python 的 mysql-connector、Java 的 JDBC）要为每个字段分配内存、做类型转换、填充对象属性。字段越多，GC 压力越大，尤其在高并发小查询场景下，这种开销会被显著放大。
- Go 的
database/sql驱动对宽结果集的列缓存初始化更慢 - Node.js 的
mysql2在处理 50+ 列的结果集时，rows.map()明显变卡 - 前端通过 API 获取 JSON 数据时，后端若未裁剪字段，会导致移动端带宽浪费和解析延迟
JOIN 场景下字段爆炸会快速击穿内存限制
两个各含 20 列的表 JOIN，SELECT * 结果集理论宽度是 40 列；若其中一张表有 payload（TEXT），另一张有 thumbnail（MEDIUMBLOB），单行可能超 1MB —— 查 100 行就占 100MB 内存，MySQL 可能直接报 ERROR 1105 (HY000): Out of memory 或退化为磁盘临时表（Using temporary; Using filesort）。
- 优化器不会自动帮你“跳过”被驱动表里不需要的列，必须显式写
u.id, u.name, o.order_no - 子查询预过滤比 JOIN 后
SELECT控制更有效：(SELECT order_id, status FROM orders WHERE user_id IN (...)) - 用
EXPLAIN看rows和Extra：如果出现Using temporary，大概率是宽字段 + 全量列导致的
SELECT * 在高并发下仍会成为瓶颈——因为压垮系统的从来不是带宽，而是单位时间内的请求吞吐能力。 
