MySQL中列别名不强制用AS，但推荐始终显式使用AS并用反引号包裹含空格、中文等非标准字符的别名，以避免解析歧义、作用域失效及语法错误。
MySQL中列别名必须用AS吗？
不用。MySQL允许省略AS关键字，直接在列名后加空格再写别名，比如SELECT name nickname FROM user是合法的。但省略AS会降低可读性，尤其当别名含空格、特殊字符或函数表达式时，容易引发歧义或语法错误。
常见错误现象：SELECT COUNT(*) count from user看似正常，但如果后续加ORDER BY count，某些旧版本MySQL（如5.6）可能报Unknown column 'count' in 'order clause'——因为没加AS时，别名作用域解析不稳定。
- 推荐始终显式使用
AS，尤其在复杂查询或团队协作中 - 函数、表达式、常量值作为列时，
AS几乎不可省略，例如SELECT NOW() AS create_time，不加AS会报错 - 别名含空格（如
full name）或保留字（如order）时，必须用反引号包裹，且AS更易定位问题，例如SELECT name AS `full name`
别名里有空格或中文怎么处理？
MySQL要求带空格、中文、连字符、数字开头等非标准标识符的别名，必须用反引号`包裹，否则解析失败。空格本身不是分隔符，而是别名字符串的一部分。
典型错误：SELECT name full name FROM user会被解析成三部分：name、full、name，直接报Unknown column 'full' in 'field list'。
- 正确写法：
SELECT name AS `full name`或SELECT name `full name`（后者虽可行但不推荐） - 中文别名同理：
SELECT age AS `年龄`，反引号不可省略 - 如果漏了反引号又含空格，MySQL不会自动截断或警告，而是直接报语法错误，定位成本高
AS和空格混用导致ORDER BY或GROUP BY失效？
是的，尤其在子查询或视图中。MySQL对无AS的别名绑定时机较晚，ORDER BY和GROUP BY可能无法识别列别名，转而尝试匹配原始列名或报错。
示例：SELECT id, COUNT(*) cnt FROM log GROUP BY id ORDER BY cnt DESC在部分配置下会报Unknown column 'cnt' in 'order clause'，因为cnt未被明确声明为别名。
- 根本原因：MySQL解析顺序是
FROM → WHERE → GROUP BY → HAVING → SELECT → ORDER BY → LIMIT，别名在SELECT阶段才生成，但ORDER BY虽在之后，某些版本对无AS别名的支持不一致 - 安全做法：所有用于
ORDER BY/GROUP BY/HAVING的别名，都显式写AS，并确保反引号包裹（如有必要） - 临时规避：改用位置序号，如
ORDER BY 2 DESC，但可维护性差，不推荐长期使用
别名在JOIN和子查询中的可见性边界
列别名只在当前查询层级有效，不会透传到外层。子查询中定义的别名，在外部查询里不可直接引用；同样，JOIN中ON条件也不能用SELECT里的别名。
错误示例：SELECT u.name AS username FROM user u JOIN order o ON o.user_id = username——username是SELECT列表别名，ON子句此时还不可见，会报Unknown column 'username'。
-
ON、WHERE、HAVING只能引用原始列、表别名、或聚合函数（在GROUP BY存在时） - 子查询若需暴露别名给外层，必须在子查询
SELECT中明确定义，且外层要通过子查询别名访问，如(SELECT id AS uid FROM user) t WHERE t.uid > 10 - 别名不参与索引优化，只是结果集显示名，不影响执行计划
实际写SQL时，最常被忽略的是别名作用域的“单层封闭性”——它不像变量一样能跨作用域继承，也不像CTE那样可命名复用。一旦嵌套两层以上或混用UNION，漏掉AS或反引号，错误信息往往指向错位的行号，排查起来比修复本身更耗时。
