SELECT *在生产环境必须避免，因其强制读取整行字段导致磁盘I/O增加、网络传输膨胀、内存压力翻倍，并必然破坏覆盖索引引发回表或全表扫描，同时带来字段变更兼容性风险和安全隐忧。
直接写 SELECT 指定列名，别用 * —— 这不是风格问题，是性能和维护风险问题。
为什么 SELECT * 在生产环境里要避免
数据库得把整行所有字段从磁盘读出来、解包、序列化再传给客户端，哪怕你只用其中 1 个字段。尤其当表里有 TEXT、JSON、BLOB 或宽字段（比如 50+ 列）时，I/O 和网络开销会明显上涨。更麻烦的是，如果后续有人在表里加了新列（比如审计字段 created_by），SELECT * 查询可能突然返回意外数据，导致前端解析失败或 ORM 映射错乱。
- MySQL 中
SELECT *无法利用覆盖索引（Covering Index），即使你要的字段全在索引里，它仍会回表 - PostgreSQL 对
*的解析开销略高，尤其配合LIMIT或ORDER BY时，优化器更难做计划剪枝 - 某些连接池或中间件（如 ProxySQL）会对
*做额外元数据查询，拖慢首包响应
SELECT 列名列表的写法要点
明确写出你需要的字段，顺序按业务逻辑排，别依赖建表顺序。如果字段名含特殊字符或关键字，用反引号（MySQL）或双引号（PostgreSQL）包裹。
- 别写
SELECT id, name, email FROM users然后在代码里靠下标取值（比如row[2]）——字段顺序一变就崩；改用字段名取值（row["email"]） - 多个表 JOIN 时，必须加表别名前缀，例如
u.id, o.status，否则字段名冲突会报错Column 'id' in field list is ambiguous - 聚合查询中，所有非聚合字段必须出现在
GROUP BY里，否则 MySQL 8.0+ 默认拒绝执行（sql_mode=ONLY_FULL_GROUP_BY）
大表分页查特定列时的性能陷阱
当你要查第 10000 条之后的数据（比如 OFFSET 10000 LIMIT 20），即使只取 3 个字段，数据库仍得跳过前 10000 行——每行都得扫描、过滤、计数。这不是“只拿列”的问题，是“怎么跳过”的问题。
- 用游标分页替代
OFFSET：记录上一页最后一条的id（或时间戳），下一页查WHERE id > last_id ORDER BY id LIMIT 20 - 如果必须用
OFFSET，确保ORDER BY字段有索引，且该索引能覆盖所有SELECT字段（即建成覆盖索引） - 避免在
SELECT里用函数或表达式（如UPPER(name)），这会让索引失效，除非你建了函数索引（PostgreSQL 支持，MySQL 8.0.13+ 也支持）
ORM 场景下怎么控制实际查哪些列
很多 ORM 默认生成 SELECT *，或者让你以为“只取 model 属性”就安全了，其实未必。
- Django 的
.values("name", "email")或.only("name", "email")才真限制字段；.values_list()返回元组，注意字段顺序 - SQLAlchemy 中
session.query(User.name, User.email)生成纯列查询；用load_only()可以在query()后追加字段限制 - MyBatis 的
<resultMap>里没配的字段，只要没设autoMapping=true，就不会被映射，但 SQL 本身仍可能是*—— 得检查<select>标签里的 SQL
真正关键的不是“能不能取”，而是“有没有意识去裁剪”。一个字段多查一次，单次影响小；但放大到日均百万次查询，就是可量化的资源浪费和延迟瓶颈。字段越少，缓存命中率越高，网络传输越快，出问题时排查路径也越短。
