show variables 默认查 session 级变量，等价于 show session variables，仅显示当前会话最终生效值（优先 session 修改值，否则继承 global 值），不混合也不叠加作用域。
show VARIABLES 默认查的是 session 级变量
执行 show VARIABLES 时不加任何修饰词，等价于 show SESSION VARIABLES，只显示当前连接正在生效的值。它不叠加、不混合 global 和 session，而是「当前会话最终采用的值」：如果该变量被当前会话显式修改过，就显示 session 值；否则显示从 global 继承来的初始值。
常见错误现象：SET GLOBAL max_connections = 2000 后立刻执行 show VARIABLES like 'max_connections'，发现值没变——因为这个命令查的是 session 层，而 max_connections 是「仅全局」变量（不支持 session 级设置），所以 session 值始终是继承自 global 的副本，但你不能在会话里改它。
- 判断一个变量是否支持 session 级修改，可查
information_schema.GLOBAL_VARIABLES或执行SELECT VARIABLE_NAME, VARIABLE_SCOPE FROM performance_schema.variables_info WHERE VARIABLE_NAME = 'xxx'; - 支持双作用域的变量（如
sql_mode）才能用SET SESSION修改；仅全局变量（如max_connections）设了SET SESSION会报错 -
show VARIABLES和show SESSION VARIABLES结果完全一致，别误以为前者是“混合视图”
用 @@global.xxx 和 @@session.xxx 显式读取更可靠
直接查系统变量值时，SELECT @@sql_mode 默认查 session 级，等价于 SELECT @@session.sql_mode；而 SELECT @@global.sql_mode 才真正拿到全局配置。这种写法比 show 命令更明确，也方便嵌入到 SQL 脚本或应用逻辑中做条件判断。
容易踩的坑：SELECT @@autocommit 在某些客户端（如旧版 MySQL Workbench）可能因连接初始化逻辑自动设为 1，掩盖了 @@global.autocommit 实际为 0 的事实，导致事务行为不一致。
批量分析录音转写，输出多维度拓客报告。触发词：录音分析、总结、音频总结、拜访记录总结。当用户提及「分析录音」「看看录音数据」「最近的录音」「通话记录」且意图为批量统计/分析时触发。仅出现「录音」或「拜访」时需结合上下文，若仅查看单条详情则不触发。
- 必须区分场景：排查连接行为看
@@session.xxx，检查实例统一配置看@@global.xxx -
@@xxx省略作用域时，优先匹配 session，找不到再 fallback 到 global —— 但这不是“合并”，只是查找顺序 - 某些变量（如
character_set_client）在会话建立后受握手参数影响，@@session值可能和@@global完全不同，且无法用SET SESSION回退到 global 值
SET 语句必须显式声明作用域才安全
SET sql_mode = 'STRICT_TRANS_TABLES' 是合法的，因为它默认作用于 session；但 SET autocommit = 0 这种写法有歧义风险——虽然实际执行的是 session 级，但开发者可能误以为改了全局，导致上线后其他连接仍用默认 auto-commit。
真实线上事故常见于：DBA 执行了 SET GLOBAL innodb_flush_log_at_trx_commit = 2 提升性能，但忘记通知应用层所有连接需重连才能感知变更，结果部分连接仍用 1，造成数据一致性隐患。
- 写脚本或自动化任务时，一律用
SET GLOBAL xxx = yyy或SET SESSION xxx = yyy，禁用无修饰的SET xxx = yyy - 全局修改后，已存在的连接不会自动更新对应 session 变量，必须手动
SET SESSION或重连 -
SET GLOBAL需要SUPER权限，普通应用账号通常没有，硬写会失败；而SET SESSION几乎总能成功
变量作用域不是对称的，三类变量必须分开看待
MySQL 的系统变量不是简单的“global / session 二分”，而是分为三类：仅全局（如 max_connections）、仅会话（如 last_insert_id）、两者都支持（如 sql_mode）。混淆类型会导致语法错误或静默失效。
比如尝试 SET SESSION time_zone = '+08:00' 成功，但 SET SESSION max_connections = 500 直接报错 ERROR 1238 (HY000): Variable 'max_connections' is a GLOBAL variable and should be set with SET GLOBAL —— 错误信息其实已经告诉你分类了。
- 查变量类型最快方式：
SELECT VARIABLE_NAME, VARIABLE_SCOPE FROM performance_schema.variables_info WHERE VARIABLE_NAME IN ('sql_mode', 'max_connections', 'tx_isolation'); - 仅会话变量无法通过
SET GLOBAL设置，也不出现在show GLOBAL VARIABLES结果里 - 很多文档说“大部分变量支持两种作用域”，这是过时认知；MySQL 8.0+ 新增变量（如
default_table_encryption）明确限定为 GLOBAL-only
VARIABLE_SCOPE，光靠经验猜，迟早掉进权限、生效范围、甚至数据一致性的坑。
