mysql 如何查看每個連接中具體某個session 級別參數(shù)的值崇堵?

我們知道m(xù)ysql中參數(shù)變量分為session 會話級別和global 全局級別
如long_query_time 就是一個典型的會話級別參數(shù)辽狈。
set session long_query_time = 1.5; 設置后僅僅在當前會話中有效糊秆。重新打開一個會話仍然是默認值。session 可以省略
set global long_query_time =1.5 ;設置后重新打開一個會話勋锤,重新打開一個會話,值是1.5

注意:我們將一個會話級別的參數(shù)如long_query_time 的global 全局范圍值修改為新的值侥祭,那么以后新創(chuàng)建的會話會是這個新的值叁执。但是對于原來已經創(chuàng)建的連接,它們的參數(shù)值還是老樣子矮冬。很多線上修改話級別的參數(shù)不生效就是這個原因(需要set session一下才能影響到當前會話)谈宛。

通過這樣來查看當前會話和全局的參數(shù)值:
show session variables like '%long_query_time%';
show global variables like '%long_query_time %';

但是這樣的show session variables 只能查看自己會話的參數(shù)值,而別的會話的參數(shù)值是什么情況我們不知道呀胎署,所以5.7版本推出了一種方式來查詢:

(root@localhost) [performance_schema]>select * from performance_schema.variables_by_thread where variable_name='long_query_time';
+-----------+-----------------+----------------+
| THREAD_ID | VARIABLE_NAME   | VARIABLE_VALUE |
+-----------+-----------------+----------------+
|        29 | long_query_time | 10.000000      |
|        30 | long_query_time | 1.500000       |
|        31 | long_query_time | 10.000000      |
+-----------+-----------------+----------------+
3 rows in set (0.00 sec)

thread_id 為30的線程對應long_query_time值為1.5吆录,我們還想知道具體是哪個process 連接的值是1.5?
5.7提供了這個performance_schema.threads表琼牧,它保存了THREAD_ID和PROCESSLIST_ID還有THREAD_OS_ID的對應關系恢筝。

(root@localhost) [performance_schema]>select * from performance_schema.threads limit 1 \G
*************************** 1. row ***************************
          THREAD_ID: 1
               NAME: thread/sql/main
               TYPE: BACKGROUND
     PROCESSLIST_ID: NULL
   PROCESSLIST_USER: NULL
   PROCESSLIST_HOST: NULL
     PROCESSLIST_DB: NULL
PROCESSLIST_COMMAND: NULL
   PROCESSLIST_TIME: 22857
  PROCESSLIST_STATE: NULL
   PROCESSLIST_INFO: NULL
   PARENT_THREAD_ID: NULL
               ROLE: NULL
       INSTRUMENTED: YES
            HISTORY: YES
    CONNECTION_TYPE: NULL
       THREAD_OS_ID: 26446
1 row in set (0.00 sec)


那么我們查下THREAD_ID =30 的記錄

(root@localhost) [performance_schema]>select * from threads where THREAD_ID =30  limit 1 \G
*************************** 1. row ***************************
          THREAD_ID: 30
               NAME: thread/sql/one_connection
               TYPE: FOREGROUND
     PROCESSLIST_ID: 5
   PROCESSLIST_USER: root
   PROCESSLIST_HOST: localhost
     PROCESSLIST_DB: NULL
PROCESSLIST_COMMAND: Sleep
   PROCESSLIST_TIME: 333
  PROCESSLIST_STATE: NULL
   PROCESSLIST_INFO: set session long_query_time = 1.5
   PARENT_THREAD_ID: NULL
               ROLE: NULL
       INSTRUMENTED: YES
            HISTORY: YES
    CONNECTION_TYPE: Socket
       THREAD_OS_ID: 26480
1 row in set (0.00 sec)

得到了 THREAD_ID: 30對應的 PROCESSLIST_ID: 5

得出結論:那么show processlist 結果的第二條連接的long_query_time的值是1.5

(root@localhost) [performance_schema]>show processlist;
+----+------+-------------------+--------------------+---------+-------+----------+------------------+
| Id | User | Host              | db                 | Command | Time  | State    | Info             |
+----+------+-------------------+--------------------+---------+-------+----------+------------------+
|  4 | root | 192.168.6.1:20193 | mysql              | Sleep   | 17649 |          | NULL             |
|  5 | root | localhost         | NULL               | Sleep   |  2500 |          | NULL             |
|  6 | root | localhost         | performance_schema | Query   |     0 | starting | show processlist |
+----+------+-------------------+--------------------+---------+-------+----------+------------------+

processlistId 對應thread id哀卫,然后又對應操作系統(tǒng)進程的線程id thread_os_id

那么上面操作可以使用join來直接完成:

select a.processlist_id,
a.thread_id,
a.thread_os_id,
a.processlist_user,
a.processlist_host,
a.processlist_db,
a.processlist_command,
a.processlist_state,
a.processlist_info,
b.* from performance_schema.threads a ,performance_schema.variables_by_thread b where a.thread_id=b.thread_id and b.variable_name='long_query_time';

結果如下

(root@localhost) [performance_schema]>select a.processlist_id, a.thread_id, a.thread_os_id, a.processlist_user, a.processlist_host, a.processlist_db, a.processlist_command, a.processlist_state, a.processlist_info, b.* from performance_schema.threads a ,performance_schema.variables_by_thread b where a.thread_id=b.thread_id and b.variable_name='long_query_time' limit 1\G
*************************** 1. row ***************************
     processlist_id: 4
          thread_id: 29
       thread_os_id: 26605
   processlist_user: root
   processlist_host: 192.168.6.1
     processlist_db: mysql
processlist_command: Sleep
  processlist_state: NULL
   processlist_info: SELECT STATE AS `Status`, ROUND(SUM(DURATION),7) AS `Duration`, CONCAT(ROUND(SUM(DURATION)/0.003109*100,3), '') AS `Percentage` FROM INFORMATION_SCHEMA.PROFILING WHERE QUERY_ID=152 GROUP BY SEQ, STATE ORDER BY SEQ
          THREAD_ID: 29
      VARIABLE_NAME: long_query_time
     VARIABLE_VALUE: 10.000000
1 row in set (0.00 sec)

最后編輯于
?著作權歸作者所有,轉載或內容合作請聯(lián)系作者
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市滋恬,隨后出現(xiàn)的幾起案子聊训,更是在濱河造成了極大的恐慌,老刑警劉巖恢氯,帶你破解...
    沈念sama閱讀 222,183評論 6 516
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件带斑,死亡現(xiàn)場離奇詭異,居然都是意外死亡勋拟,警方通過查閱死者的電腦和手機勋磕,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 94,850評論 3 399
  • 文/潘曉璐 我一進店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來敢靡,“玉大人挂滓,你說我怎么就攤上這事⌒ル剩” “怎么了赶站?”我有些...
    開封第一講書人閱讀 168,766評論 0 361
  • 文/不壞的土叔 我叫張陵,是天一觀的道長纺念。 經常有香客問我贝椿,道長,這世上最難降的妖魔是什么陷谱? 我笑而不...
    開封第一講書人閱讀 59,854評論 1 299
  • 正文 為了忘掉前任烙博,我火速辦了婚禮,結果婚禮上烟逊,老公的妹妹穿的比我還像新娘渣窜。我一直安慰自己,他們只是感情好宪躯,可當我...
    茶點故事閱讀 68,871評論 6 398
  • 文/花漫 我一把揭開白布乔宿。 她就那樣靜靜地躺著,像睡著了一般访雪。 火紅的嫁衣襯著肌膚如雪予颤。 梳的紋絲不亂的頭發(fā)上,一...
    開封第一講書人閱讀 52,457評論 1 311
  • 那天冬阳,我揣著相機與錄音,去河邊找鬼党饮。 笑死肝陪,一個胖子當著我的面吹牛,可吹牛的內容都是我干的刑顺。 我是一名探鬼主播氯窍,決...
    沈念sama閱讀 40,999評論 3 422
  • 文/蒼蘭香墨 我猛地睜開眼饲常,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了狼讨?” 一聲冷哼從身側響起贝淤,我...
    開封第一講書人閱讀 39,914評論 0 277
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎政供,沒想到半個月后播聪,有當?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體,經...
    沈念sama閱讀 46,465評論 1 319
  • 正文 獨居荒郊野嶺守林人離奇死亡布隔,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內容為張勛視角 年9月15日...
    茶點故事閱讀 38,543評論 3 342
  • 正文 我和宋清朗相戀三年离陶,在試婚紗的時候發(fā)現(xiàn)自己被綠了。 大學時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片衅檀。...
    茶點故事閱讀 40,675評論 1 353
  • 序言:一個原本活蹦亂跳的男人離奇死亡招刨,死狀恐怖,靈堂內的尸體忽然破棺而出哀军,到底是詐尸還是另有隱情沉眶,我是刑警寧澤,帶...
    沈念sama閱讀 36,354評論 5 351
  • 正文 年R本政府宣布杉适,位于F島的核電站谎倔,受9級特大地震影響,放射性物質發(fā)生泄漏淘衙。R本人自食惡果不足惜传藏,卻給世界環(huán)境...
    茶點故事閱讀 42,029評論 3 335
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望彤守。 院中可真熱鬧毯侦,春花似錦、人聲如沸具垫。這莊子的主人今日做“春日...
    開封第一講書人閱讀 32,514評論 0 25
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽筝蚕。三九已至卦碾,卻和暖如春,著一層夾襖步出監(jiān)牢的瞬間起宽,已是汗流浹背洲胖。 一陣腳步聲響...
    開封第一講書人閱讀 33,616評論 1 274
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留坯沪,地道東北人绿映。 一個月前我還...
    沈念sama閱讀 49,091評論 3 378
  • 正文 我出身青樓,卻偏偏與公主長得像,于是被迫代替她去往敵國和親叉弦。 傳聞我的和親對象是個殘疾皇子丐一,可洞房花燭夜當晚...
    茶點故事閱讀 45,685評論 2 360

推薦閱讀更多精彩內容

  • https://www.bilibili.com/video/av19538278?p=2https://blog...
    指向遠方的燈塔閱讀 598評論 0 1
  • 1、搭建mysql服務器淹冰,并實現(xiàn)主主復制库车、半同步復制 存儲引擎: 表類型:也稱為“表類型”,表級別概念樱拴,不建議在同...
    stephe_c閱讀 432評論 0 0
  • 一柠衍、MySQL介紹 二、MySQL 安裝 1.安裝前注意事項 (1)確認SELinux 和 系統(tǒng)防火墻 iptab...
    L_Jing_b48d閱讀 270評論 0 0
  • 第十二章節(jié) MySQL 工具應用及全面優(yōu)化 一疹鳄、 PT(percona-toolkits)工具的應用: 1. pt...
    StandingBy_abc閱讀 584評論 0 0
  • 我的學習記錄拧略,可能有誤請諒解,也提供了一些源碼接口供有興趣的朋友調試瘪弓。源碼版本:percona 5.7.14 本文...
    重慶八怪閱讀 568評論 0 1