搞懂這三個命令的區別，核心是 變量作用域（全局 / 會話），你的部分理解需要修正 ——show VARIABLES 並非 “疊加”，而是默認顯示「當前會話生效的變量」；session 和 global 變量也並非數量一致，而是有 “僅全局”“僅會話”“兩者都有” 三類情況。下面分步驟講清楚：
三者的本質差異是 查詢的變量作用域不同，且 show VARIABLES 有默認行為，具體對比如下：
- 不是 “疊加”：
show VARIABLES 只顯示「當前會話生效的變量」，而非同時顯示 global 和 session。
其值的來源是：如果當前會話修改過某個變量，就顯示修改後的 session 值；如果沒修改過，就顯示繼承自 global 的默認值。
例：global 的 sql_mode 是 ''，當前會話執行 SET SESSION sql_mode = 'STRICT_TRANS_TABLES' 後，show VARIABLES like 'sql_mode' 會顯示修改後的 session 值，而非同時顯示兩個值。
假設場景：
- 全局變量
sql_mode 為 ''（寬鬆模式）；
- 你當前會話執行
SET SESSION sql_mode = 'STRICT_TRANS_TABLES'（嚴格模式）；
此時查詢結果：
結論：同一變量，session 優先級 > global（當前會話優先用自己的配置，沒有則繼承 global）。
你的第二個問題：“session 變量允許有哪些？是不是和 global 一樣多？”
答案：不一樣多。MySQL 的變量分為三類，決定了兩者的範圍差異：
這類變量是數據庫實例的 “基礎配置”，無法在會話級別修改，只能全局設置。
- 例子：
datadir（數據存儲目錄）、port（監聽端口）、max_connections（最大連接數）、innodb_buffer_pool_size（InnoDB 緩衝池大小）。
- 特點：
show SESSION VARIABLES 查不到這些變量，只能通過 show GLOBAL VARIABLES 查看。
這類變量和 “當前連接的操作狀態” 相關，僅存在於會話中，不影響全局。
- 例子：
insert_id（手動指定的下一個自增 ID）、last_insert_id（當前會話最後插入的自增 ID）、sql_safe_updates（當前會話的安全更新模式）。
- 特點：
show GLOBAL VARIABLES 查不到這些變量，只能通過 show SESSION VARIABLES 查看。
這類變量有全局默認值，每個會話會繼承初始值，但可以在會話中單獨修改（不影響全局）。
- 例子：
sql_mode（SQL 模式）、wait_timeout（連接超時時間）、character_set_client（客户端字符集）、max_join_size（關聯查詢的最大行數限制）。
- 特點：
show GLOBAL 和 show SESSION 都能查到，但值可能不同（會話修改後）。
session 變量總數 ≠ global 變量總數，兩者有重疊（第三類），但各有獨有的變量（第一、二類）。
- 全局變量修改後，已存在的會話不生效，只有新連接會繼承新的全局值；
- 有些變量即使是 “既全局又會話”，修改 session 級也可能無效（比如
innodb_buffer_pool_size，雖然能查 session 值，但修改後不生效，因為是共享資源，只能全局配置）；
- 權限要求：修改 global 變量需要
SUPER 權限（或 MySQL 8.0+ 的 SYSTEM_VARIABLES_ADMIN 權限），修改 session 變量一般不需要特殊權限；
- 簡寫：
show LOCAL VARIABLES 等價於 show SESSION VARIABLES（LOCAL 是 SESSION 的別名）。
show GLOBAL VARIABLES：查實例級全局配置，影響所有新連接；show SESSION VARIABLES：查當前連接的專屬配置，僅影響當前連接；show VARIABLES：默認查 SESSION 變量，即當前會話正在使用的配置（優先用自己的，沒有則繼承 global）；- session 和 global 變量數量不同，有 “僅全局”“僅會話”“兩者都有” 三類，同名變量的會話值會覆蓋全局值（僅當前連接）。
如何得知 當前session 有修改過哪些變量？ 難道只能一個個的比對嗎
不需要一個個手動比對！MySQL 提供了 系統表查詢 + 變量來源追蹤 的高效方法，能直接篩選出當前會話中被修改過的變量（即「會話值≠全局默認值」的變量）。以下是兩種最實用的方案，適配不同 MySQL 版本：
會話變量的初始值默認繼承自全局變量，只有「手動修改過」或「連接時自動適配」的變量，才會和全局值不一致。因此，找出「會話值≠全局值」且「變量同時存在於全局和會話」的記錄，就是當前會話修改過的變量（排除會話獨有變量）。
利用 information_schema 中的 GLOBAL_VARIABLES 和 SESSION_VARIABLES 兩張系統表，直接關聯比對同名變量的值，差異結果就是修改過的變量。
- 結果會列出所有「會話值≠全局值」的變量，這些變量要麼是你手動
SET SESSION 修改的，要麼是連接時 MySQL 自動適配的（比如字符集相關變量，若客户端和全局默認字符集不同）。
- 排除了「僅全局變量」（如
datadir）和「僅會話變量」（如 last_insert_id），只聚焦於「可修改且有全局默認值」的變量（正是你關心的 “可能被修改” 的變量）。
MySQL 8.0.11 及以上版本，新增了 performance_schema.variables_info 表，其中 VARIABLE_SOURCE 字段直接記錄了「會話變量值的來源」，無需比對，直接篩選來源為 SESSION 的變量即可，更精準高效。
- 無需關聯兩張表，查詢速度更快；
- 能精準區分「手動修改」（來源
SESSION）和「自動適配 / 繼承」（來源 GLOBAL），避免誤判（比如字符集變量可能因客户端配置自動變化，並非手動修改，方案一會列出，方案二可排除）。
-
變量類型比對問題：
部分變量的全局值和會話值類型可能不同（比如
max_connections 是數字，
sql_mode 是字符串），方案一中用
CAST(xxx AS CHAR) 統一轉成字符串比對，避免因類型差異導致的 “假陽性”（比如
123 和
'123' 本應相等，卻因類型不同被判為不同）。
-
會話獨有變量的處理：
方案一用
INNER JOIN 只保留「既有全局又有會話」的變量，自動排除了
last_insert_id 這類「僅會話變量」（它們不存在全局值，自然不屬於 “修改自全局” 的範疇），無需額外過濾。
-
權限要求：
兩種方案都需要
SELECT 權限（對
information_schema 或
performance_schema），普通用户默認擁有（除非管理員特意限制），無需
SUPER 權限。
-
修改後不生效的變量：
有些變量（比如
innodb_buffer_pool_size）雖然能
SET SESSION 修改，但實際不生效（因為是全局共享資源），但這兩個方案依然會列出它們（只要會話值≠全局值或來源為
SESSION），需注意這類變量的 “修改” 僅為表面值，未實際生效。
- 若使用 MySQL 8.0.11+，優先用 方案二（精準、高效，直接定位手動修改的變量）；
- 若使用 MySQL 5.7 及以下，用 方案一（兼容所有版本，能找出所有與全局值不同的變量）；
- 兩種方案都無需手動比對，直接運行 SQL 即可得到結果，高效解決你的問題。
我是否可以理解為，當啓動一個mysql 會話即session的時候， 會創建MySQL的一個session實例，然後 會自動從global實例中繼承一些變量（是繼承全部嗎），然後按需對其中某些變量進行修改，（哪些是可以修改、哪些不能修改的呢？）如不修改， 那麼直接去global的變量？
你的理解大體方向正確，但有幾個關鍵細節需要修正和補充，核心結論先明確：
- 會話（session）啓動時不會繼承全部 global 變量，只繼承「既全局又會話的變量」的初始值；
- 不修改會話變量時，用的是「啓動時繼承的全局初始值」（而非實時讀取 global 變量）；
- 變量能否修改，取決於它的「類型」和「MySQL 的設計規則」（不是所有變量都能改會話級）。
下面分步驟把邏輯講透，貼合你的 MySQL 5.7.11 版本：
你説的 “session 實例啓動時繼承 global 變量”，本質是 會話變量的初始化過程，但繼承範圍有限，具體分 3 類（沿用之前的變量分類，保持一致）：
- 不是 “繼承全部 global 變量”：僅第 3 類變量會被會話 “複製初始值”，第 1 類僅全局變量會話根本沒有，談不到繼承；
- 不是 “實時讀取 global 變量”：會話啓動後，第 3 類變量的初始值就和 global 變量 “脱鈎” 了 —— 之後哪怕修改了 global 變量，已存在的會話也不會同步（新會話才會用新的 global 值當初始值）。
舉個直觀例子：
- 全局變量
wait_timeout = 86400（默認 24 小時）；
- 你啓動一個新會話（session A），會話的
wait_timeout 初始值 = 86400（複製當時的 global 值）；
- 之後管理員修改全局變量
SET GLOBAL wait_timeout = 3600（1 小時）；
- 會話 A 的
wait_timeout 依然是 86400（不受 global 修改影響），只有新啓動的會話 B，才會以 3600 作為初始值。
變量能否修改，核心看「變量類型」和「MySQL 的設計限制」，按 “修改範圍”（會話級 / 全局級）分類如下：
- 對應變量類型：第 1 類（僅全局變量）；
- 特點：和數據庫實例的 “基礎配置 / 共享資源” 相關，必須全局統一，不能按會話自定義；
- 例子：
datadir（數據目錄）、port（端口）、max_connections（最大連接數）、innodb_buffer_pool_size（InnoDB 緩衝池）；
- 説明：
show SESSION VARIABLES 查不到這些變量，只能用 SET GLOBAL xxx 修改（需 SUPER 權限），且新會話才生效。
- 對應變量類型：第 2 類（僅會話變量）+ 部分第 3 類（既全局又會話，但全局級不允許改）；
- 特點：和當前會話的 “操作狀態” 相關，僅影響當前連接，不涉及全局資源；
- 例子：
- 僅會話變量：
last_insert_id（只能通過插入數據或 SET SESSION last_insert_id = xxx 修改）、sql_safe_updates（僅會話級生效，控制是否允許無 WHERE 的 UPDATE/DELETE）；
- 第 3 類但僅能改會話級：
character_set_results（客户端字符集返回格式，全局改意義不大，通常改會話級）；
- 説明：修改無需特殊權限，
SET SESSION xxx 即可，斷開連接後失效。
- 對應變量類型：大部分第 3 類（既全局又會話的變量）；
- 特點：有全局默認值，也支持會話自定義，滿足 “全局統一 + 局部靈活” 的需求；
- 例子：
sql_mode（SQL 模式，全局寬鬆 + 會話嚴格）、wait_timeout（連接超時，全局 24 小時 + 會話 1 小時）、max_join_size（關聯查詢最大行數限制）、sort_buffer_size（排序緩衝區大小）；
- 説明：
- 改全局：
SET GLOBAL xxx（需 SUPER 權限），新會話生效；
- 改會話：
SET SESSION xxx（普通權限），僅當前會話生效，不影響全局。
有些第 3 類變量（既全局又會話），雖然能執行 SET SESSION xxx，但修改後實際不生效 —— 因為它們是 “全局共享資源”，會話級修改被 MySQL 忽略；
- 例子：
innodb_buffer_pool_size（緩衝池大小）、key_buffer_size（MyISAM 索引緩衝區）；
- 説明：這些變量的會話值只是 “顯示用”，實際生效的還是全局值，改會話級沒用。
你問 “如不修改，那麼直接去 global 的變量？”—— 這個理解不準確，正確邏輯是：
- 對於第 3 類變量（既全局又會話）：不修改的話，用的是「會話啓動時複製的 global 初始值」（不是實時去讀 global）；
- 對於第 2 類變量（僅會話變量）：不修改的話，用的是「MySQL 的會話默認值」（和 global 無關）；
- 對於第 1 類變量（僅全局變量）：會話中根本查不到，不存在 “取值” 一説。
再舉個例子驗證：
- 全局
sql_mode = ''（寬鬆模式）；
- 啓動會話 A，會話 A 的
sql_mode 初始值 = ''（複製當時的 global 值）；
- 管理員修改全局
sql_mode = STRICT_TRANS_TABLES（嚴格模式）；
- 會話 A 不修改自己的
sql_mode，此時查詢 show VARIABLES like 'sql_mode'，結果還是 ''（不是實時讀新的 global 值）；
- 新啓動會話 B，其
sql_mode 初始值 = STRICT_TRANS_TABLES（複製新的 global 值）。
- 會話啓動時，僅「既全局又會話的變量」會複製當前 global 值作為初始值，僅全局變量不繼承，僅會話變量自動創建；
- 不修改會話變量時，用的是 “初始值”（第 3 類 = 複製的 global 初始值，第 2 類 = 會話默認值），和後續 global 變量的修改無關；
- 變量能否修改：
- 僅全局變量：只能改 global（需權限，新會話生效）；
- 僅會話變量：只能改 session（無權限限制，當前會話生效）；
- 既全局又會話的變量：大部分能改兩者，少數改 session 不生效；
- 你的核心理解 “會話繼承部分 global 變量，按需修改，不修改則用初始值” 是對的，只是要注意 “繼承範圍” 和 “初始值不實時同步 global” 這兩個細節。
如果想快速判斷某個變量能否改會話級，直接執行 SET SESSION 變量名 = 新值，若報錯 Variable 'xxx' is a GLOBAL variable and should be set with SET GLOBAL，説明該變量只能改 global；若不報錯，且查詢 show VARIABLES like 'xxx' 是新值，説明改 session 級有效～
MySQL 中 STATUS 怎麼理解，和 variables 是關係區別？
要理解 MySQL 中
STATUS 和
variables 的關係與區別，核心一句話就能拎清：
variables 是「配置項」（靜態規則），
STATUS 是「運行狀態 / 監控數據」（動態結果） —— 配置項決定 MySQL 如何運行，運行狀態反映 MySQL 實際運行的效果，兩者是 “因” 與 “果” 的關聯，但本質完全不同。
variables 是你之前一直關注的 “配置”，核心是「提前設定好的規則」，告訴 MySQL 該用什麼字符集、允許多少連接、超時多久斷開等。
常見例子（既全局又會話的核心變量）：
sql_mode：SQL 模式（規則），決定是否允許零日期、是否嚴格校驗數據；wait_timeout：連接超時時間（規則），決定客户端閒置多久斷開；character_set_client：客户端字符集（規則），決定 MySQL 如何解析客户端發送的字符；max_connections：最大連接數（規則），決定 MySQL 最多能同時接受多少連接。
查詢示例（你之前用過的）：
STATUS 是 MySQL 運行過程中「自動統計的數據」，記錄規則執行後的實際效果，比如 “按 max_connections 規則，當前有多少連接在使用”“按 query_cache_type 規則，緩存命中了多少次”。
常見例子（按場景分類）：
查詢示例（適配你的 5.7.11）：
variables 和 STATUS 不是孤立的，而是 “因” 與 “果” 的關係 —— 你修改了配置（variables），最終會體現在狀態（STATUS）上；通過狀態（STATUS），也能反推配置（variables）是否合理。
舉 2 個直觀關聯例子：
- 配置
max_connections（variables）= 100 → 狀態 Threads_connected（STATUS）的最大值不會超過 100（如果超過，會出現 “連接數滿” 錯誤）；
- 配置
sql_mode（variables）= STRICT_TRANS_TABLES（嚴格模式）→ 狀態 Com_insert（STATUS）中，因數據不符合規則導致的插入失敗數會增加（可結合錯誤日誌查看）；
- 配置
wait_timeout（variables）= 3600 → 狀態 Threads_connected（STATUS）中，閒置超過 1 小時的連接會被自動斷開，連接數會減少。
-
作用域一致性≠含義一致：
兩者都支持
GLOBAL 和
SESSION，但含義不同：
show SESSION VARIABLES like 'wait_timeout'：當前連接的超時規則（比如 3600 秒）；show SESSION STATUS like 'Threads_connected'：當前連接的活躍狀態（固定為 1，因為是當前連接自己）。
-
STATUS 是 “累計值”，不是 “實時快照”：
比如
Queries 是從實例 / 連接啓動後開始累計的，不是 “當前正在執行的查詢數”（當前執行數看
Threads_running）。
-
部分 STATUS 變量名和 variables 類似，但完全不同：
比如
version（STATUS）是 MySQL 版本號（狀態），
version_comment（variables）是版本註釋（配置），名稱接近但含義無關。
- 想「改規則、調配置」→ 用
variables（比如修改字符集、調整超時時間、開啓嚴格模式）；
- 想「看狀態、查問題」→ 用
STATUS（比如排查連接數滿、找慢查詢、監控緩存效果）；
- 核心邏輯：用 variables 定規則，用 STATUS 看規則的執行效果，兩者配合才能完整掌控 MySQL 的運行。
比如你之前想知道 “會話修改了哪些變量”，用 variables 對比；現在想知道 “修改後連接數是否下降”，就用 STATUS 查 Threads_connected —— 這就是兩者的實際配合場景。
如下的區別？ show GLOBAL STATUS; show SESSION STATUS; show STATUS;
這三個命令的核心區別和 variables 系列完全一致 ——默認行為 + 統計數據的作用域（全局 / 會話），結合你熟悉的 MySQL 5.7.11 版本，用 “統計範圍 + 實際用途” 就能講透，還能直接對應到你的運維場景：
show STATUS 沒有 “疊加”，默認只看「當前會話」的統計；- 全局狀態是 “全實例彙總”，會話狀態是 “當前連接單獨統計”，互不干擾；
- 數據都是 累計值（從實例 / 連接啓動時開始算），不是實時 “快照”（比如
Queries 是累計執行的 SQL 總數，不是當前正在執行的數量）。
假設場景：你的 MySQL 實例已運行 1000 秒，當前有 3 個活躍連接，你當前連接剛執行了 5 條 SQL，其中 1 條是慢查詢。
show GLOBAL STATUS like 'Uptime';
show SESSION STATUS like 'Uptime';
show STATUS like 'Queries';
- 全局狀態是 “集體數據”，反映整個數據庫的負載；
- 會話狀態是 “個人數據”，只反映你當前連接的操作；
show STATUS 就是偷懶寫法，默認看 “個人數據”。
-
部分狀態變量只有 “全局版”，沒有會話版：
比如
Uptime（實例運行時長）、
Com_show_databases（全實例累計執行
show databases 的次數），執行
show SESSION STATUS like 'Uptime' 也能查到，但值是「當前連接的存活時長」（不是實例時長），用途不同。
-
會話狀態的生命週期：
會話狀態數據從連接建立時開始累計，斷開連接後數據會重置（下次重連重新從 0 開始算）；而全局狀態數據從實例啓動時開始累計，重啓實例才會重置。
-
別把 “累計值” 當 “實時值”：
- 想查 “當前正在執行的 SQL 數”→ 用
show GLOBAL STATUS like 'Threads_running'（全局），不是 Queries（累計總數）；
- 想查 “當前活躍連接數”→ 用
show GLOBAL STATUS like 'Threads_connected'（全局），不是 Threads_running（正在執行的連接數）。
-
權限要求：
普通用户默認能查
SESSION STATUS；查
GLOBAL STATUS 可能需要
PROCESS 權限（如果報錯 “Access denied”，讓管理員授予
GRANT PROCESS ON *.* TO '你的用户名'@'localhost';）。
