MySQL临时变量赋值中，SET @var=(SELECT...)要求子查询单行单列，否则报错；SELECT @var:=col FROM tbl逐行赋值仅保留最后一行结果；无FROM的SELECT @var:=...最安全；WHERE/ORDER BY中引用变量因求值顺序不确定而不可靠。
MySQL 临时变量怎么赋值：SET 和 SELECT 的区别在哪
MySQL 临时变量（用户变量，以 @ 开头）不是声明出来的，而是首次赋值时自动创建。但 SET 和 SELECT 赋值行为差异很大，直接决定变量是否能拿到预期值。
-
SET @var = (SELECT ...)：子查询必须返回单行单列，否则报错Subquery returns more than 1 row -
SELECT @var := col FROM tbl：逐行执行，只保留最后一行的赋值结果；如果表为空，@var保持原值（或为NULL，取决于上下文） - 用
SELECT @var := ...在无FROM子句时（如SELECT @var := 1 + 2），会返回一行结果，同时完成赋值 —— 这是最安全的“计算并存值”写法
为什么在 WHERE 或 ORDER BY 里用 @var 会出错
因为 MySQL 对 WHERE、ORDER BY、HAVING 中的表达式求值顺序不保证与 SELECT 列一致，尤其当变量在 SELECT 中被修改、又在 WHERE 中被读取时，行为不可靠。
- 常见错误现象：
SELECT @row := @row + 1 AS rownum, id FROM t1, (SELECT @row := 0) r WHERE @row ——@row在WHERE中的值可能滞后于SELECT中的更新 - 正确做法：把变量逻辑全收进
SELECT列或子查询中，避免跨子句依赖。例如生成序号，优先用ROW_NUMBER()（8.0+）或派生表包裹 - 兼容性影响：5.7 及以前版本中，这类写法看似“能跑”，实则依赖执行计划，升级后容易崩
临时变量在存储过程和函数里能不能用
能用，但要分清“用户变量”（@var）和“局部变量”（DECLARE var INT）—— 它们生命周期、作用域、语法完全不互通。
kashen-mysql DDLtoExcel
下载
解析 MySQL 8.0 的 DDL 脚本，并将表结构导出为 Excel 格式。适用于用户需将 MySQL 的 `CREATE TABLE` 语句转换为结构化的 Excel 文件场景，导出内容包含字段名、数据类型、长度及精度等信息。支持多张表的批量处理，每张表对应 Excel 中的一个独立工作表。适用于数据库文档编写、数据字典生成及模式分析等任务。
- 用户变量
@var在会话级有效，跨语句、跨存储过程都可见；局部变量只在BEGIN...END块内有效，且必须DECLARE显式定义 - 别在存储过程中混用：比如
SET @x = 1;然后试图SELECT x FROM t WHERE y = @x—— 看似没问题，但如果该过程被并发调用，@x会被覆盖 - 性能提示：用户变量不走查询缓存，也不参与优化器估算；局部变量更轻量，推荐优先用
DECLARE+SET组合做中间计算
MySQL 8.0 后还有必要用 @var 实现排序/分组计数吗
基本没必要。窗口函数已覆盖绝大多数场景，且语义清晰、可预测、支持索引下推。
- 替代
@rank := IF(@prev = score, @rank, @rank + 1)这类手工排名：直接用ROW_NUMBER() OVER (ORDER BY score DESC) - 替代“每组取前 N 条”的变量 hack：用
ROW_NUMBER() OVER (PARTITION BY category ORDER BY price)+ 外层WHERE rn - 例外情况：极老环境（@var 仍有存在价值，但务必加注释说明副作用
变量赋值看着简单，但 MySQL 不保证执行顺序，也不校验类型。真正难的不是写出来，是写出来之后敢不敢在生产里长期留着。
