SQL SELECT * 的生产危害与列名显式列举的最佳实践 checklist

join 场景下 select 会因多表同名列导致字段冲突报错，应显式指定表别名和列名；orm 中全字段查询引发性能与缓存问题，需按需加载；alter 后字段顺序不可靠，须禁用索引取值；视图、子查询、where 查询及归档脚本中均应禁用 select 。

SELECT * 在 JOIN 场景下会直接暴露字段冲突风险

一查就报错，比如 column 'id' in field list is ambiguous，不是语法问题，是语义混乱。JOIN 多表时，SELECT * 把所有列全捞出来，一旦两表都有 id、created_at 这类通用字段，结果集列名就撞车了——数据库不保证顺序，ORM 更可能直接 panic 或静默丢列。

实操建议：

• JOIN 时永远用表别名 + 显式列：写成 SELECT u.id, u.name, o.status FROM users u JOIN orders o ON u.id = o.user_id
• 如果真要快速看数据结构，先用 DESCRIBE table_name 或 PRAGMA table_info(table_name)（sqlite）查字段，再手敲列名
• 别信“开发环境跑得通”，postgresql 和 mysql 对 SELECT * 的列序处理逻辑不同，跨库迁移时极易出错

ORM 中 SELECT * 导致 N+1 和缓存失效的隐性开销

比如 django 的 Model.objects.all() 或 SQLAlchemy 的 session.query(Model) 默认就是全字段查。表面看代码干净，实际把 text、jsonb、blob 这类大字段也拖过来了，网络传输翻倍、内存占用飙升，还让 redis 缓存 key 变得极难设计——字段增减直接让旧缓存失效，且无法按需失效部分字段。

实操建议：

• Django 用 .values('id', 'name') 或 .only('id', 'name')；SQLAlchemy 用 load_only(Model.id, Model.name)
• 接口返回层必须和查询层对齐：不要在视图里取 obj.description 却没在 query 中加载它
• 加个 CI 检查项：grep -r “SELECT *” ./src/ —— 真有漏网之鱼，至少得加注释说明为什么破例

ALTER TABLE 增加列后 SELECT * 返回顺序不可靠

很多人以为 SELECT * 总是按建表顺序返回字段，其实不然。MySQL 8.0+、PostgreSQL 都允许 ALTER 添加列到任意位置（如 ADD COLUMN x int AFTER name），但 SELECT * 仍按物理存储顺序或 catalog 顺序返回，而客户端代码（尤其是用 index 取值的旧脚本）很可能硬编码了第 3 列是 email，一加字段就错位。

实操建议：

• 永远用列名取值，禁用 row[2] 这类索引访问；Python 用 row.email，Go 用 row.Scan(&u.ID, &u.Name) 显式绑定
• 数据库迁移脚本里，如果涉及字段顺序敏感逻辑（比如导出 CSV），必须显式写出全部列名，哪怕暂时和当前 schema 一致
• MySQL 的 SHOW COLUMNS FROM table 输出顺序 ≠ SELECT * 实际顺序，别依赖它做自动化生成

生产 SQL 审计 checklist：哪些地方必须砍掉 SELECT *

不是所有 SELECT * 都该被骂，但以下场景只要出现，就得立刻改——它们几乎 100% 引发线上问题：

• 出现在任何带 WHERE 条件的查询中（过滤了数据却拉全字段，浪费 IO）
• 出现在子查询里，尤其作为 IN 或 EXISTS 的右侧（MySQL 会物化整张中间表）
• 出现在视图定义中（CREATE VIEW v AS SELECT * FROM t —— 后续 t 加字段，v 就悄悄变重）
• 出现在备份或归档脚本的抽取语句里（字段膨胀会让每日导出时间从 2min 涨到 47min）

最麻烦的不是性能，是字段语义漂移：今天 SELECT * FROM logs 返回 8 列，明天加了个 trace_id，下游所有解析逻辑都得重新对齐。这事没法靠监控发现，只能靠写死列名来锁死契约。