<p>SELECT * 在生产环境危险，因它导致列数依赖表结构、引发数据错乱与性能下降；应显式指定所需字段并确保顺序匹配业务逻辑。</p>
为什么 SELECT * 在生产环境是危险操作
它会让查询结果列数完全依赖表结构，一旦后续加字段（比如新增 updated_at 或 is_deleted），所有调用方都可能意外收到多余数据——前端渲染错乱、API 响应膨胀、ORM 映射失败，甚至触发下游服务的字段校验异常。
更隐蔽的问题是：数据库优化器对 SELECT * 的执行计划判断更保守，可能放弃使用覆盖索引，导致额外回表；而明确指定字段后，如果全在索引里，就能走 index-only scan，性能差异能到 3–5 倍。
- 不要把
SELECT *当成“省事”，它是隐式耦合的源头 - 哪怕只差一个字段，也得显式写出来；别信“反正我只用前两列”这种侥幸
- Django/SQLAlchemy 等 ORM 默认生成
SELECT *，必须主动用.values()或.only()控制字段
如何安全地用字段列表替代 SELECT *
核心原则：只选真正需要的字段，且顺序与业务逻辑强相关。比如分页接口要排序，ORDER BY 字段必须出现在 SELECT 列表里（尤其 PostgreSQL 对此敏感）。
常见错误现象：ERROR: column "id" must appear in the GROUP BY clause or be used in an aggregate function —— 这往往是因为你写了 GROUP BY user_id 却还在 SELECT *，结果数据库不知道该拿哪个 id 出来。
- 先看业务代码里实际读了哪些字段，删掉没用的（比如
created_by仅用于审计日志，但当前接口根本不展示） - 用
EXPLAIN ANALYZE对比改写前后执行计划，确认是否命中覆盖索引 - 字段别名要一致：
SELECT user_id AS id比直接user_id更易维护，但注意别和已有字段名冲突
SELECT 字段过多时怎么避免手误漏写
手动列字段最怕复制粘贴出错，比如少写一个逗号导致语法报错，或者字段名拼错变成隐式 NULL（MySQL 允许未定义字段返回 NULL，PostgreSQL 直接报错 column "xxx" does not exist）。
推荐做法不是靠记忆，而是从元数据生成字段列表：
SELECT column_name FROM information_schema.columns WHERE table_name = 'orders' AND table_schema = 'public' ORDER BY ordinal_position;
再把结果复制进 SQL，删掉不需要的字段。比翻建表语句快，也比 IDE 自动补全更可控。
- 别用
SELECT * FROM orders LIMIT 0查字段——有些驱动不支持空结果集元数据获取 - 字段名含大小写或特殊字符（如
"user-id"）必须加双引号，否则解析失败 - 视图或 CTE 中字段名来自子查询别名，不能直接套用原表字段名
ORM 场景下绕不开 SELECT * 怎么办
很多 ORM 在做 model.save() 或关联查询时会默认拉全量字段，比如 Django 的 Order.objects.get(id=123) 就是 SELECT *。这不是懒，是框架设计使然——它要保证 model 实例所有字段可读可写。
但你可以干预：Django 用 .values('id', 'status') 返回字典，或 .only('id', 'status') 返回 model 实例（未取字段为 None）；SQLAlchemy 用 load_only('id', 'status')。
-
.only()和.defer()是惰性加载，字段没访问就不会触发二次查询，但要注意 N+1 问题 - 如果只是查统计或 ID 列表，用
.values_list('id', flat=True)，生成的是 Python list，不是 model 实例 - 别在
filter()里混用.only()和.annotate()，某些版本会忽略字段限制
字段列表不是越短越好，也不是越全越稳。关键在“刚好够用”——够当前逻辑跑通，又留得住扩展余地。最麻烦的从来不是写几个字段名，而是有人悄悄改了表结构，而你的 SELECT 还卡在三个月前的备份脚本里。
