mysql用户变量不能直接用于where条件过滤，因优化器可能重排执行顺序导致where先于赋值执行；安全做法是set初始化后在select/join中引用，避免where或on中使用。
MySQL用户变量不能直接用于WHERE条件过滤
用户变量（如 @user_id）在SELECT中赋值后，**不能保证在WHERE子句中被正确求值**——因为MySQL优化器可能重排执行顺序，导致WHERE先于变量赋值执行，结果为空或错乱。
常见错误现象：SELECT @uid := 123, name FROM users WHERE id = @uid 看似合理，但实际可能返回空集，尤其在有索引、JOIN或ORDER BY时更不稳定。
- 真正安全的做法是：用SET显式初始化变量，再在后续查询中引用，且确保变量只出现在SELECT/ORDER BY/HAVING中，不参与WHERE或ON条件
- 如果必须动态过滤，优先用参数化查询（应用层传参），而非依赖用户变量做逻辑判断
- Session变量本身无权限隔离，
@xxx对当前连接可见，但不会跨连接污染；不过若连接被复用（如连接池），需在每次使用前重置
用SET + SELECT组合实现“安全过滤”的典型写法
核心思路是把过滤逻辑拆成两步：先用SET确定参数值，再用SELECT读取并关联，避免WHERE里直接引用未定义变量。
例如按角色动态查用户：
SET @role_filter = 'admin'; SELECT u.id, u.name FROM users u JOIN (SELECT @role_filter AS role) r ON u.role = r.role;
这个写法能绕过优化器对变量的误判，因为@role_filter在子查询中被显式绑定为常量列。
- 注意：子查询必须用JOIN方式关联，不能写成
WHERE u.role = (SELECT @role_filter)，后者仍可能触发延迟求值 - 如果需要多条件，可SET多个变量：
SET @min_age = 18, @status = 'active'; - 该方法在MySQL 5.7+稳定，但8.0+中仍不推荐替代预处理语句，仅适用于简单脚本或运维临时查询
SESSION变量 vs 用户变量：别混淆@var和@@session.var
@xxx 是会话级用户变量，无需声明，首次赋值即存在；而@@session.xxx 是系统变量，只能修改已存在的配置项（如@@session.sql_mode），不能随便定义。
试图执行 SET @@session.my_flag = 1 会报错：Unknown system variable 'my_flag'。
- 用户变量命名无限制，但建议加业务前缀（如
@filter_user_id）避免冲突 - 用户变量区分大小写（
@ID≠@id），但系统变量不区分 - 变量值始终是字符串类型，数值比较时隐式转换可能导致意外结果，比如
@num = '01' = 1为true
为什么不用PREPARE + EXECUTE？它其实更安全但有代价
用预处理语句模拟动态过滤确实最可靠：SET @sql = CONCAT('SELECT * FROM users WHERE role = ''', @role_filter, ''''); → PREPARE stmt FROM @sql; EXECUTE stmt;。
但它有明显副作用：
- SQL注入风险：如果
@role_filter来自不可信输入且没转义，直接拼接会出事 - 无法利用查询缓存（MySQL 8.0已移除，但5.7仍受影响）
- 每次EXECUTE都重新解析语法树，高并发下性能不如固定语句
- 错误信息更难定位，堆栈里只显示
EXECUTE stmt，不显示真实SQL
所以除非真要拼接表名或列名（用户变量做不到），否则别为了“动态”硬上PREPARE。
真正容易被忽略的是：变量生命周期只到连接关闭。如果用连接池，上一个请求设的@xxx可能还在，下个请求不显式SET就直接用，结果错得无声无息。
