SELECT * 会放大别名混淆风险，因多表JOIN时同名列（如id）无前缀导致歧义，PostgreSQL报“column reference is ambiguous”，MySQL行为不可靠；子查询、视图、GROUP BY中引用更易出错。
为什么 SELECT * 会放大别名混淆风险
不写表前缀时，SELECT * 在多表 JOIN 中极易触发“列名重复”错误（如 PostgreSQL 报 ERROR: column reference "id" is ambiguous），MySQL 虽可能默认取右表值，但行为不可靠。本质是 SQL 解析器无法区分同名列来自哪张表，尤其在子查询、视图或后续 GROUP BY/ORDER BY 中引用时直接报错。
实操建议：
- 永远禁用
SELECT *，哪怕只是临时调试 - 对每张参与 JOIN 的表，提前用
DESCRIBE table_name或PRAGMA table_info(table_name)（SQLite）确认字段名，避免凭记忆手写 - 在复杂查询中，先写好所有表的别名（如
FROM users u JOIN orders o ON ...），再逐字段补全前缀，比事后排查快得多
如何用工具强制校验字段前缀（非语法层面）
SQL 标准本身不提供“必须带前缀”的语法开关，只能靠外部约束。真正有效的做法是把校验嵌入开发流程：
实操建议：
- 在 IDE（如 DataGrip、DBeaver）中启用「SQL 检查规则」，勾选 “Require table alias for ambiguous columns” 类选项
- 用
sqlfluff配置.sqlfluff文件，添加规则：[rules] L027 = True # Enforce table alias usage
，然后运行sqlfluff lint query.sql - CI 流程中加入检查：对所有
*.sql文件执行grep -n "SELECT.*," query.sql | grep -v "\."快速定位漏写前缀的行（需配合人工复核）
LEFT JOIN 场景下 NULL 字段的前缀不能省略
当使用 LEFT JOIN 时，右表字段可能为 NULL，但前缀依然必须保留——否则 WHERE o.status = 'paid' 会意外过滤掉左表记录（因 o.status 为 NULL 时不满足等值条件），而写成 WHERE o.status IS NOT NULL AND o.status = 'paid' 才语义清晰。
常见错误现象：
- 误写
WHERE status = 'paid'→ 实际匹配的是左表的status字段，而非右表订单状态 - 在
SELECT中漏写前缀，导致GROUP BY id被解析为左表users.id，但HAVING COUNT(o.id) > 1却依赖右表，逻辑断裂 - MySQL 8.0+ 开启
ONLY_FULL_GROUP_BY后，漏前缀的GROUP BY直接报错：Expression #1 of SELECT list is not in GROUP BY clause
视图和 CTE 中前缀遗漏更难发现
视图定义里没加前缀，调用方即使写了前缀也无效；CTE 中字段若未显式命名（如 SELECT u.name, o.amount FROM ...），外部查询引用 name 时仍会歧义。
实操建议：
- 创建视图时，所有字段必须用
AS显式重命名并带来源标识，例如：CREATE VIEW user_order_summary AS SELECT u.id AS user_id, u.name AS user_name, o.id AS order_id, o.total AS order_total FROM users u LEFT JOIN orders o ON u.id = o.user_id;
- CTE 中禁止裸
SELECT *，必须展开并重命名：WITH ranked_orders AS (SELECT o.id AS order_id, ROW_NUMBER() OVER (...) AS rn FROM orders o) - 用
EXPLAIN VERBOSE（PostgreSQL）或EXPLAIN FORMAT=TREE（MySQL 8.0+）查看执行计划，确认字段引用是否解析到预期表
最麻烦的情况不是语法报错，而是逻辑静默错误：字段前缀错配导致 JOIN 条件失效、聚合结果偏移、甚至线上数据导出错列——这些往往要等业务侧反馈异常才暴露，排查成本远高于写 SQL 当下多敲几个字母。
