<p>JOIN 场景下 SELECT 会因多表同名列导致字段冲突报错，应显式指定表别名和列名；ORM 中全字段查询引发性能与缓存问题，需按需加载；ALTER 后字段顺序不可靠，须禁用索引取值；视图、子查询、WHERE 查询及归档脚本中均应禁用 SELECT 。</p>
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，下游所有解析逻辑都得重新对齐。这事没法靠监控发现，只能靠写死列名来锁死契约。
