MySQL學習筆記(一)——MySQL的一些基本知識
阿新 • • 發佈:2021-07-02
原文連結
https://juejin.cn/book/6844733769996304392
版權歸作者所有,如有侵權請聯絡我刪除!!
MySQL伺服器處理客戶端請求過程
連線管理
-
伺服器是一個執行緒處理一個客戶端連線
-
客戶端退出時會與伺服器斷開連線,伺服器不會立即銷燬該執行緒,
而是把它快取起來,在另起新連線時,把這個快取的執行緒分配給該新客戶端。
減少了執行緒的建立和銷燬,節省開銷。
如果執行緒分配的太多了會嚴重影響系統性能,所以也需要限制可以同時連線到伺服器的客戶端數量。 -
客戶端發起連線的時候,需要攜帶主機資訊、使用者名稱、密碼,伺服器會進行認證。
如果客戶端和伺服器不執行在一臺計算機上,可採用使用了SSL -
當連線建立後,與該客戶端關聯的伺服器執行緒會一直等待客戶端傳送過來的請求,MySQL伺服器接收到的請求只是一個文字訊息,該文字訊息還要經過各種處理。
解析與優化
- 主要是查詢快取、語法解析和查詢優化
查詢快取
- 語句必須在字元層面上完全一樣(空格、大小寫、註釋)
- 不同客戶端共享同一個快取
- 查詢中使用系統函式請求不會被快取
- 表結構和資料被修改過,快取中涉及這張表的查詢會被刪除
- 查詢有時可以提升效能,但也造成了一些開銷;從MySQL 5.7.20開始,不推薦使用查詢快取,並在MySQL 8.0中刪除。
- 查詢快取的另一個大問題是它受到單個互斥鎖的保護。在具有多個核心的伺服器上,大量查詢會導致大量的互斥鎖爭用;同時還不能保證快取命中率,所以無法估計效能。
- 查詢越複雜,掃描範圍越大,則查詢快取越受益。
- 現在可以利用查詢重寫外掛,在不更改應用程式的同時,插入優化器提示語句。另外,還有像ProxySQL這樣的第三方工具,它們可以充當中間快取。
語法解析
- 將文字轉換為引擎內部的一些資料結構
查詢優化
- 自動優化自己寫的語句,生成了一個執行計劃,可以提高執行效率
- 使用Explain 語句可以檢視執行計劃
儲存引擎
- 常用的 InnoDB 和 MyISAM
- 系統變數有GLOBAL和SESSION兩種
字符集和比較規則
一些字符集
- ASCII
- 一共128字元,一個位元組編碼
- ISO 8859-1
- 256字元,一個位元組編碼,多了128西歐字母
- GBK字符集
- GB2312字符集收錄了漢字以及拉丁字母、希臘字母、日文平假名及片假名字母、俄語西裡爾字母。其中收錄漢字6763個,其他文字元號682個。同時這種字符集又相容
ASCII
字符集,所以在編碼方式上顯得有些奇怪:- 如果該字元在
ASCII
字符集中,則採用1位元組編碼。 - 否則採用2位元組編碼。
- 如果該字元在
- GBK字符集只是在收錄字元範圍上對GB2312字符集作了擴充,編碼方式上相容GB2312。
- GB2312字符集收錄了漢字以及拉丁字母、希臘字母、日文平假名及片假名字母、俄語西裡爾字母。其中收錄漢字6763個,其他文字元號682個。同時這種字符集又相容
- utf-8字符集
- 收錄地球上能想到的所有字元,而且還在不斷擴充。這種字符集相容
ASCII
字符集,採用變長編碼方式,編碼一個字元需要使用1~4個位元組。 - utf8使用1~4個位元組編碼一個字元,utf16使用2個或4個位元組編碼一個字元,utf32使用4個位元組編碼一個字元。
- 收錄地球上能想到的所有字元,而且還在不斷擴充。這種字符集相容
MySQL相關
-
utf8mb3:閹割過的utf8字符集,只使用1~3個位元組表示字元,在MySQL中utf-8預設是指utf8mb3。
-
utf8mb4:正宗的utf8字符集,使用1~4個位元組表示字元。
-
utf8_general_ci是MySQL中utf8的預設比較規則
-
將服務端各系統變數的字符集設定成和客戶端一樣的語句:
- SET NAMES 字符集名;
-
比較規則可能影響排序操作的結果