SELECT字段列表决定结果集结构，影响列名、顺序、空值性与类型推导；显式写字段比*更安全；别名需用AS定义且不可在WHERE中引用；表达式计算、函数索引、隐式转换、ORDER BY陷阱均需谨慎处理。
SELECT 字段列表写法直接影响查询结果结构
字段投影不是简单“写啥查啥”，而是决定结果集列名、顺序、是否可空、类型推导的关键。MySQL 不会自动帮你补全别名或类型，写错就直接暴露底层行为。
- 用
*时，列顺序和表定义顺序一致，但跨 JOIN 时可能混杂同名列（如两个表都有id），客户端读取容易出错 - 显式列出字段更安全，尤其涉及
NULL值处理：比如COALESCE(price, 0)投影后列名是COALESCE(price, 0)，除非加AS price - 别名里不能含空格或特殊字符，否则必须用反引号包裹，例如
`user name`；但更推荐用下划线命名避免麻烦
表达式计算在 SELECT 中不支持 WHERE 直接引用别名
这是新手掉进最多的一类坑：以为 SELECT price * 1.1 AS final_price WHERE final_price > 100 能跑通——实际会报错 Unknown column 'final_price' in 'where clause'。
- WHERE 执行在 SELECT 投影之前，所有表达式还没计算，自然看不到别名
- 解决办法只有两个：重复写表达式（
WHERE price * 1.1 > 100），或改用子查询 / CTE 包一层 - 注意函数调用开销：像
UPPER(name)在 WHERE 里用，无法走索引；若想查大写匹配，最好提前存规范值，或建函数索引（MySQL 8.0+ 支持）
字符串拼接、条件判断这些表达式要小心隐式类型转换
MySQL 对表达式容忍度高，但也因此埋了兼容性雷。比如 CONCAT(id, '_item')，当 id 是 INT 且为 NULL 时，整个结果变 NULL，不是你想的 '_item'。
-
CONCAT()遇到任意参数为NULL就返回NULL；需要安全拼接用CONCAT_WS('_', IFNULL(id, ''), 'item') -
CASE WHEN表达式中各分支返回类型不一致时，MySQL 会强制转成兼容类型，比如混合VARCHAR和INT，可能截断或补零，建议显式CAST(... AS CHAR) - 日期计算别依赖字符串隐式转：写
order_date + INTERVAL 7 DAY没问题，但写order_date + '7'会触发奇怪的数值解析逻辑，不同版本行为还不一致
ORDER BY 里允许用别名或位置序号，但有陷阱
虽然 SELECT name, age FROM user ORDER BY 2 看起来省事，但它脆弱得离谱——只要前面字段顺序一调，排序就错乱，而且没法被 IDE 或 SQL 审计工具识别。
- 用别名最稳妥，但注意：别名必须是 SELECT 列表中真实存在的，不能是未定义的变量或注释里的名字
- 位置序号（如
ORDER BY 1）在带 UNION 的查询里会失效，因为每个子句的列数可能不同 - 对表达式排序时，如果表达式复杂（如嵌套函数），MySQL 可能放弃使用索引，即使该字段本身有索引；这时要考虑冗余字段或生成列（GENERATED COLUMN）+ 索引
事情说清了就结束
