应明确列出所需字段而非用 *，并合理使用 AS 别名：字段需精准选取以避免性能与安全风险；别名应在多表 JOIN、聚合函数及字段歧义时强制使用，且须注意其仅在 SELECT 和 ORDER BY 中生效。
SELECT 里怎么只取需要的字段，而不是写 *
用 * 看似省事，实际埋雷：查出多余字段会拖慢网络传输、增加内存占用、干扰后续逻辑（比如 ORM 映射失败或 JSON 序列化字段冲突）。更关键的是，一旦表结构变动（比如加了大文本字段或敏感列），* 会无声无息把不该带的东西全捞出来。
实操建议：
- 明确列出所需字段，例如
SELECT user_id, username, created_at，别依赖* - 如果字段名和业务语义不一致（比如数据库里叫
usr_nm），立刻用别名对齐，而不是在代码里做映射转换 - 避免在
SELECT中混用别名和原始名（如SELECT id AS user_id, username, created_at AS time是 OK 的；但SELECT id AS user_id, username, created_at和后续ORDER BY created_at没问题，而ORDER BY time就会报错——别名在ORDER BY可用，但在WHERE或GROUP BY中不可用，这是常见误解点）
AS 别名该不该加，加在哪种场景下最必要
别名不是装饰，是契约。它让 SQL 输出结构可预期、可维护，尤其在多表 JOIN 或子查询时，字段名容易重名或模糊。
实操建议：
- 只要字段来自不同表且名字相同（比如
orders.user_id和users.id），就必须用别名区分，否则SELECT *或直接引用会报Column 'id' in field list is ambiguous - 聚合函数必须用别名，否则结果集列名是类似
count(*)这样的表达式，多数客户端无法识别为合法字段名 - 别名尽量用下划线命名（
total_amount），避免空格或特殊字符；如果非要用带空格的别名（如"Full Name"），记得用反引号（MySQL）或双引号（PostgreSQL）包裹，否则语法报错
别名在 WHERE / GROUP BY / HAVING 中为什么不能直接用
SQL 执行顺序决定了别名生效时机：FROM → WHERE → GROUP BY → HAVING → SELECT → ORDER BY。而 AS 是在 SELECT 阶段才定义的，所以 WHERE 和 GROUP BY 看不到它。
常见错误现象：SELECT price * 1.1 AS final_price FROM products WHERE final_price > 100 —— 报错 Unknown column 'final_price'。
实操建议：
-
WHERE中重复写表达式：WHERE price * 1.1 > 100 - 或者用子查询 /CTE 提前算好别名，再在外层过滤：
SELECT * FROM (SELECT price * 1.1 AS final_price FROM products) t WHERE t.final_price > 100 -
GROUP BY同理，不能写GROUP BY user_name（如果user_name是别名），得写原始字段或位置序号（如GROUP BY 2），但后者可读性差，不推荐
不同数据库对别名大小写和引号的处理差异
MySQL 默认忽略别名大小写，但开启 ANSI_QUOTES 模式后，双引号就变成标识符引用符；PostgreSQL 对大小写极度敏感，SELECT name AS UserName 输出列名就是 UserName，但用 WHERE username = 'x' 会查不到——因为小写 username 被当成未加引号的标识符，自动转成小写匹配，而别名是驼峰，不匹配。
实操建议：
- 统一用小写下划线风格别名（
user_name），兼容性最高 - 如果必须用大小写混合或特殊字符，MySQL 用反引号
`User Name`，PostgreSQL 用双引号"User Name"，SQLite 两者都支持，但别混用 - 应用层读取结果时，别硬编码字段名，优先用列索引或 case-insensitive 字段查找（如 Python 的
row['user_name']而不是row['UserName']）
事情说清了就结束。字段选择和别名看着简单，但跨数据库、跨语言、跨执行阶段的细节，一个没对齐就容易在上线后突然崩掉。
