set session 语句仅对当前连接有效，断开后失效，不影响其他连接；等价于不加作用域的 set，但推荐显式书写以避免混淆；仅动态系统变量支持会话级修改，连接池中需通过 connectioninitsql 或 jdbc url 参数确保生效。
SET SESSION 语句只对当前连接有效
执行 SET SESSION variable_name = value 后，该变量值仅在当前客户端连接中生效，断开重连就恢复默认值或继承全局值。它不会影响其他任何连接，也不需要高权限（如 SYSTEM_VARIABLES_ADMIN），普通用户也能用。
- 常见误操作：在应用里执行一次
SET SESSION，以为后续所有请求都自动继承——其实每个新连接都要单独设置 - 典型场景：长事务中临时调大
sort_buffer_size或降低wait_timeout防止空闲断连 - 验证是否生效：必须用
SELECT @@session.variable_name查，SHOW VARIABLES LIKE 'xxx'默认查的就是 session 级别，但显式写@@session.更稳妥
SET SESSION 和 SET 不加作用域的区别
不加 SESSION 关键字的 SET variable_name = value，在 MySQL 中**等价于 SET SESSION**，两者行为完全一致。但这种简写容易引发混淆，尤其当变量名和系统变量重名时（比如 sort_buffer_size）。
- 推荐始终显式写
SET SESSION，避免和用户变量（@var）或全局变量（SET GLOBAL）语法混在一起 - 错误示例：
SET @sort_buffer_size = 1048576—— 这创建的是用户变量，对查询性能毫无影响 - 正确写法：
SET SESSION sort_buffer_size = 1048576或SET @@session.sort_buffer_size = 1048576
哪些变量支持会话级动态修改
不是所有系统变量都能在会话层修改。MySQL 把变量分为「动态」和「静态」两类，只有动态变量才允许运行时调整。比如 join_buffer_size、net_read_timeout、sql_mode 可以；而 innodb_log_file_size、max_connections（注意：这个是全局动态变量，但会话级无对应副本）就不行。
- 查一个变量是否可会话级修改：
SELECT VARIABLE_NAME, VARIABLE_SCOPE FROM INFORMATION_SCHEMA.SESSION_VARIABLES WHERE VARIABLE_NAME = 'xxx';—— 若返回空，说明不支持 - 常见可设会话变量：
autocommit、character_set_client、time_zone、sql_select_limit - 性能敏感变量如
tmp_table_size设太高可能触发磁盘临时表，设太低又易 OOM，建议结合SHOW STATUS LIKE 'Created_tmp%'观察效果
SET SESSION 在连接池环境下的坑
用连接池（如 HikariCP、Druid）时，SET SESSION 的效果极不稳定。因为连接池可能复用旧连接，也可能新建连接，而你无法控制哪次查询走哪个连接。
- 最常踩的坑：应用启动时执行一次
SET SESSION sql_mode = 'STRICT_TRANS_TABLES'，结果部分请求仍用默认模式——因为那些请求拿到的是未执行过 SET 的空闲连接 - 安全做法：在连接池配置里加
connectionInitSql（HikariCP）或connectionInitSqls（Druid），确保每次从池中取出连接前都执行一遍 - 替代方案：直接在 JDBC URL 里加参数，例如
?sessionVariables=sql_mode='STRICT_TRANS_TABLES'，由驱动自动注入，更可靠
