mysql優化注意點網上資料一大堆,不過個人建議還是先了解原理,然後再去看優化技巧,不僅能讓你更好地因地制宜的優化,也能讓你對mysql有一個新的認識高度,在此先淺談mysql的執行過程和sql緩存以及索引,後面再更新一下
/*************************************************************************************************************
MySQL整個查詢執行過程，總的來說分爲6個步驟：
1.客戶端向MySQL服務器發送一條查詢請求
2.服務器首先檢查查詢緩存，如果命中緩存，則立刻返回存儲在緩存中的結果。否則進入下一階段
3.服務器進行SQL解析、預處理、再由優化器生成對應的執行計劃
4.MySQL根據執行計劃，調用存儲引擎的API來執行查詢
5.將結果返回給客戶端，同時緩存查詢結果
*************************************************************************************************************/
所以檢索效率高低主要根據mysql的優化器選擇的執行計劃而定,所有的優化策略也是因此產生的
mysql優化點主要從以下幾點着重描述一下:
- sql緩存
- 索引
- 表結構
- mysql分層架構
- sql細節
- mysql連接
/*********************************************[sql緩存]******************************************************************
1.原理:sql緩存默認是開啓的,query_cache_type='ON' 則查詢都會走緩存的,在解析一個查詢語句前，如果查詢緩存是打開的，那麼MySQL會檢查這個查詢語句是否命中查詢緩存中的數據。如果當
前查詢恰好命中查詢緩存，在檢查一次用戶權限後直接返回緩存中的結果。這種情況下，查詢不會被解析，也不會生成執行計劃，更不會執行.
2.命中問題:MySQL將緩存存放在一個引用表（不要理解成table，可以認爲是類似於HashMap的數據結構），通過一個哈希值索引，這個哈希值通過查詢本身、當前要查詢的數據庫、客戶端協議版本號等一
些可能影響結果的信息計算得來。所以兩個查詢在任何字符上的不同（例如：空格、註釋），都會導致緩存不會命中。
3.失效的情況:如果查詢中包含任何用戶自定義函數、存儲函數、用戶變量、臨時表、mysql庫中的系統表，其查詢結果都不會被緩存。比如函數NOW()或者CURRENT_DATE()會因爲不同的查詢時間，返回不同的查詢結
果，再比如包含CURRENT_USER或者CONNECION_ID()的查詢語句會因爲不同的用戶而返回不同的結果，將這樣的查詢結果緩存起來沒有任何的意義
4.緩存的優缺點和注意事項:MySQL的查詢緩存系統會跟蹤查詢中涉及的每個表，如果這些表（數據或結構）發生變化，那麼和這張表相關的所有緩存數據都將失效。正因爲如此，在任何的寫操作時，MySQL必須將對應表的所有緩存都設
置爲失效。如果查詢緩存非常大或者碎片很多，這個操作就可能帶來很大的系統消耗，甚至導致系統僵死一會兒。而且查詢緩存對系統的額外消耗也不僅僅在寫操作，讀操作也不例外：
a.任何的查詢語句在開始之前都必須經過檢查，即使這條SQL語句永遠不會命中緩存
b.如果查詢結果可以被緩存，那麼執行完成後，會將結果存入緩存，也會帶來額外的系統消耗
基於此，我們要知道並不是什麼情況下查詢緩存都會提高系統性能，緩存和失效都會帶來額外消耗，只有當緩存帶來的資源節約大於其本身消耗的資源時，纔會給系統帶來性能提升。但要如何評估打開緩存
是否能夠帶來性能提升是一件非常困難的事情，也不在本文討論的範疇內。如果系統確實存在一些性能問題，可以嘗試打開查詢緩存，並在數據庫設計上做一些優化，比如：
a.用多個小表代替一個大表，注意不要過度設計
b.批量插入代替循環單條插入
c.合理控制緩存空間大小，一般來說其大小設置爲幾十兆比較合適
d.可以通過SQL_CACHE和SQL_NO_CACHE來控制某個查詢語句是否需要進行緩存
5.最好的用法:不要輕易打開查詢緩存，特別是寫密集型應用。如果你實在是忍不住，可以將query_cache_type設置爲DEMAND，這時只有加入SQL_CACHE的查詢纔會走緩存，其他查詢則不會，這樣可以非常自由地控制哪些查詢需要被緩存
*************************************************************************************************************/
-- 查看是否開啓緩存
SHOW VARIABLES LIKE '%query_cache%';
-- 設置緩存信息
SET GLOBAL QUERY_CACHE_TYPE='demand' ;
SET GLOBAL query_cache_size='600000';
-- 不走緩存的sql
SELECT SQL_NO_CACHE * FROM whelp_center_config;
-- 走緩存的sql
SELECT SQL_CACHE * FROM whelp_center_config WHERE tnt_inst_id='MYBKC1CN';
SHOW STATUS LIKE 'Qca%';
SHOW STATUS LIKE 'Com_sel%'; -- 緩存命中率 ,服務器執行了多少select語句
SHOW STATUS LIKE 'last_query_cost';
/***********************************************[索引]******************************************************************
索引類型大致分爲:普通索引,唯一索引,主鍵索引,組合索引,全文索引
其中:
普通索引:是最基本的索引,沒有任何的限制
唯一索引:索引列的值必須唯一,不過被索引的字段的值可以爲null
主鍵索引:特殊的唯一索引,不過列的值不可爲null,且一張表只能有一個主鍵索引
組合索引:值在多個字段上創建的索引,索引是否生效遵循斷點規則
全文索引:主要用來查找文本中的關鍵字，而不是直接與索引中的值相比較
組合索引注意事項:
生效原則:從前往後依次使用生效，如果中間某個索引沒有使用，那麼斷點前面的索引部分起作用，斷點後面的索引沒有起作用
（a,b,c） 三個列上加了聯合索引（是聯合索引 不是在每個列上單獨加索引）而是建立了a,(a,b),(a,b,c)三個索引，另外(a,b,c)
多列索引和 (a,c,b)是不一樣的,只跟索引順序有關係跟sql條件查詢的順序無關
全文索引注意事項:
1.MySQL自帶的全文索引只能用於數據庫引擎爲MyISAM的數據表，如果是其他數據引擎，則全文索引不會生效。此外，MySQL自帶
的全文索引只能對英文進行全文檢索，目前無法對中文進行全文檢索。如果需要對包含中文在內的文本數據進行全文檢索，我
們需要採用Sphinx(斯芬克斯)/Coreseek技術來處理中文。
2.目前，使用MySQL自帶的全文索引時，如果查詢字符串的長度過短將無法得到期望的搜索結果。MySQL全文索引所能找
到的詞的默認最小長度爲4個字符。另外，如果查詢的字符串包含停止詞，那麼該停止詞將會被忽略
3.如果可能，請儘量先創建表並插入所有數據後再創建全文索引，而不要在創建表時就直接創建全文索引，因爲前者比後者的全文索引效率要高
索引失效或則不適合的情況:
1.不適合重複數據太多的列(假如索引列TYPE有5個鍵值，如果有1萬條數據，那麼 WHERE TYPE = 1將訪問表中的2000個數據塊。再加上訪問索引塊，
一共要訪問大於2000個的數據塊.如果10條數據一個數據塊的話,全表掃描也才掃描1000個數據塊,索引的效果就達不到了)
2.前導模糊查詢不能利用索引(like '%XX'或者like '%XX%')
假如有這樣一列code的值爲'AAA','AAB','BAA','BAB' ,如果where code like '%AB'條件，由於前面是
模糊的，所以不能利用索引的順序，必須一個個去找，看是否滿足條件。這樣會導致全索引掃描或者全表掃
描。如果是這樣的條件where code like 'A % '，就可以查找CODE中A開頭的CODE的位置，當碰到B開頭的
數據時，就可以停止查找了.
3.如果條件中有or，即使其中有條件帶索引也不會使用(這也是爲什麼儘量少用or的原因)
要想使用or，又想讓索引生效，只能將or條件中的每個列都加上索引
4.對於多列索引，不是使用的第一部分，則不會使用索引
5.like查詢以%開頭
6.如果列類型是字符串，那一定要在條件中將數據使用引號引用起來,否則不使用索引
7.如果mysql估計使用全表掃描要比使用索引快,則不使用索引
8.儘量避免逆向查詢,逆向查詢索引出的列過多,mysql選擇執行計劃的時候考慮到內存損耗問題會直接全表查詢
9.is null不走索引 is not null走索引
10.儘量避免函數或則計算表達式,網上很多說函數表達式不走索引,這個得看表達式運用的地方,如果運用在靜態值的話是走的,運用在數據庫字段的話
是不走的
11.現在mysql已經優化,只要查詢結果過多,就算正常使用了索引,也不會走索引的
***********************************************************************************************************************/
-- 全文索引
ALTER TABLE student ADD FULLTEXT INDEX fulltext_name(student_name, course);
SELECT * FROM student WHERE MATCH(student_name,course) AGAINST('zhang'); -- 因爲是innodb,全文索引不生效
-- 組合索引[百分號]
EXPLAIN SELECT * FROM testA WHERE scene='ASK1' AND NAME LIKE'%cba';-- 百分號在前面無論內容是什麼都不走索引
EXPLAIN SELECT * FROM testA WHERE scene='ASK1' AND NAME LIKE'9999%'; -- 百分號在後面會走索引
EXPLAIN SELECT * FROM testA WHERE scene='ASK1' AND NAME LIKE'%9999%'; -- 前後百分號不走索引
EXPLAIN SELECT * FROM testA WHERE scene='ASK1' AND NAME LIKE'%9999';
-- 組合索引[join] 條件:兩邊都建立過索引且字段類型相同,且索引類型相同
EXPLAIN SELECT url
FROM testA t1
LEFT JOIN help_center_entry t2
ON t1.name=t2.name
AND t1.`scene`=t2.`scene`
WHERE t2.`scene`='ASK1' AND t2.`help_type`='HELP' AND t2.name='9999'
-- 組合索引or
EXPLAIN SELECT * FROM testA WHERE scene='ASK1' OR id=512 -- 不走索引
EXPLAIN SELECT * FROM testA WHERE scene='ASK1' AND NAME='9999' OR id=512 -- 全部組合索引字段加上自帶索引的id,走索引
-- 逆向查詢 注意了,逆向查詢不一定失效,只是大多數逆向查詢出的結果過多導致不走索引,如果逆向查詢的結果很少還是會的
EXPLAIN SELECT * FROM testA WHERE scene IN ('NEWTEST') -- 查詢結果不多,走索引
EXPLAIN SELECT * FROM testA WHERE scene IN ('ASK1') -- 查詢結果過多,不走索引
EXPLAIN SELECT * FROM testA WHERE scene NOT IN ('NEWTEST') -- 逆向結果過多 不走索引
EXPLAIN SELECT * FROM testA WHERE scene NOT IN ('ASK1') -- 逆向結果不多 走索引
EXPLAIN SELECT * FROM testA WHERE scene='ASK1'
AND NAME IN
(
SELECT NAME FROM help_center_entry WHERE NAME='相思無情9' -- in中查詢結果比較少,外層查詢走索引
)
EXPLAIN SELECT * FROM testA WHERE scene='ASK1'
AND NAME IN
(
SELECT NAME FROM help_center_entry -- in中查詢結果比較多,外層查詢不走索引
)
EXPLAIN SELECT * FROM testA WHERE scene !='NEWTEST' -- 包括不等於 <> not in not exists都是如此
-- 函數表達式是否走索引 函數表達式在=號右邊或則靜態的話就走索引,如果對字段操作函數的話就不走索引
EXPLAIN SELECT * FROM testA WHERE scene=CONCAT('ASK1','') AND NAME =CONCAT('簡單樣式','走一個') LIMIT 1 -- 走索引
EXPLAIN SELECT * FROM testA WHERE scene='ASK1' AND NAME ='簡單樣式走一個'
EXPLAIN SELECT * FROM testA WHERE scene='ASK1' AND NAME=LPAD('簡單樣式走一個哈哈',7,'') -- 走索引
EXPLAIN SELECT * FROM testA WHERE id=137+1; -- 走索引
EXPLAIN SELECT * FROM testA WHERE scene='ASK1' -- 搜索結果過多,不走索引
EXPLAIN SELECT * FROM testA WHERE scene=SUBSTR('NEWTEST',1,8) -- 走索引
EXPLAIN SELECT * FROM testA WHERE scene=SUBSTRING('NEWTEST123',1,7) -- 走索引
-- 運用在數據庫字段上,其他函數不一一列舉了
EXPLAIN SELECT * FROM testA WHERE SUBSTRING(scene,1,7)='NEWTEST' -- 不走索引
EXPLAIN SELECT * FROM testA WHERE id+1=128 -- 不走索引
EXPLAIN SELECT * FROM testA WHERE id=127; -- 走索引
EXPLAIN SELECT * FROM testA WHERE CONCAT(NAME,'1')='樂相思又恨相思1'; -- 不走索引
EXPLAIN SELECT * FROM testA WHERE LPAD(NAME,8,'')='樂相思又恨相思1'; -- 不走索引
EXPLAIN SELECT * FROM testA WHERE NAME >='樂相思又恨相思' AND NAME <='樂相思又恨相思M' -- 替代模糊查詢like的優化
/*********************************************[表結構優化]********************************************************
1.在查詢時，MYSQL只能使用一個索引，如果建立的是多個單列的普通索引，在查詢時會根據查詢的索引字段，從中選擇一個
限制最嚴格的單例索引進行查詢。別的索引都不會生效。所以在創建表的時候,想要多個索引都生效的話用組合索引
2.永遠爲每張表設置一個ID主鍵
3.使用ENUM而不是VARCHAR(原理:小的字段類型,偏移量就會小,效率會高很多)
ENUM 類型是非常快和緊湊的。在實際上，其保存的是 TINYINT，但其外表上顯示爲字符串。這樣一來，用這個字段來做一些
選項列表變得相當的完美。 如果我們有一個字段，比如“性別”，“國家”，“民族”，“狀態”或“部門”，我們知道這些字段的取
值是有限而且固定的，那麼，我們應該使用 ENUM 而不是 VARCHAR
4.固定長度的表會更快
如果表中的所有字段都是“固定長度”的，整個表會被認爲是 “static” 或 “fixed-length”。 例如，表中沒有如下類型的字段：
VARCHAR，TEXT，BLOB。只要我們包括了其中一個這些字段，那麼這個表就不是“固定長度靜態表”了，這樣，MySQL 引擎會用
另一種方法來處理。 固定長度的表會提高性能，因爲MySQL搜尋得會更快一些，因爲這些固定的長度是很容易計算下一個數
據的偏移量的，所以讀取的自然也會很快。而如果字段不是定長的，那麼，每一次要找下一條的話，需要程序找到主鍵。 並
且，固定長度的表也更容易被緩存和重建。不過，唯一的副作用是，固定長度的字段會浪費一些空間，因爲定長的字段無論
我們用不用，他都是要分配那麼多的空間。另外在取出值的時候要使用trim去除空格
5.垂直分割
“垂直分割”是一種把數據庫中的表按列變成幾張表的方法，這樣可以降低表的複雜度和字段的數目，從而達到優化的目的。
6.越小的列會越快
對於大多數的數據庫引擎來說，硬盤操作可能是最重大的瓶頸。所以，把我們的數據變得緊湊會對這種情況非常有幫助，因
爲這減少了對硬盤的訪問。 參看 MySQL 的文檔 Storage Requirements 查看所有的數據類型。 如果一個表只會有幾列罷了
（比如說字典表，配置表），那麼，我們就沒有理由使用 INT 來做主鍵，使用 MEDIUMINT, SMALLINT 或是更小的 TINYINT
會更經濟一些。如果我們不需要記錄時間，使用 DATE 要比 DATETIME 好得多
**************************************************************************************************************/
-- 查看索引
SHOW INDEX FROM testA;
SHOW KEYS FROM testA;
/*************************************[數據庫存儲引擎選擇方面]*************************************************
在MYSQL中有兩個存儲引擎MyISAM和InnoDB,每個引擎都有利有弊。
MyISAM不支持事務,不支持數據行鎖定,不支持外鍵約束,支持數據表鎖定,表空間相對較小,支持全文索引,擅長搜索性能
InnoDB不支持全文索引,支持事務,支持數據行鎖定,支持外鍵約束,支持表鎖定,擅長事務安全性,查詢性能偏低(阿里的
mysql服務默認用的InnoDB)
**************************************************************************************************************/
/*******************************************[數據庫分層架構]***************************************************
通常一個大型應用的數據倉庫分爲三層架構:基礎表->中間表->應用表,由於數據的敏感性,基礎表一般禁止直接查詢,想要實現上
層應用的即席查詢或則預定於報表的效果,就需要從中間表進行彙總查詢分析.那麼接下來主要討論下數據倉庫爲什麼存在,有什麼
用,以及其特性
這種分層架構主要用在企業數據分析上,其實就是數據倉庫,數據倉庫就是爲支持企業決策而特別設計和建立的數據集合。
企業建立數據倉庫是爲了填補現有數據存儲形式已經不能滿足信息分析的需要。數據倉庫理論中的一個核心理念就是：
事務型數據和決策支持型數據的處理性能不同
廣義的說，基於數據倉庫的決策支持系統由三個部件組成:
數據倉庫技術，聯機分析處理技術和數據挖掘技術，其中數據倉庫技術是系統的核心，目前市場上比較流行的是阿里的odps在線流數據處理服務以及傳統的TERADATA,EXDATA一體機的oracle服務
數據倉庫通常處理邏輯:
1)收集和分析業務需求
數據倉庫價值曲線
2)建立數據模型和數據倉庫的物理設計
3)定義數據源
4)選擇數據倉庫技術和平臺
5)從操作型數據庫中抽取、淨化、和轉換數據到數據倉庫
6)選擇訪問和報表工具
7)選擇數據庫連接軟件
8)選擇數據分析和數據展示軟件
9)更新數據倉庫
數據倉庫特點:
1、數據倉庫是面向主題的；操作型數據庫的數據組織面向事務處理任務，而數據倉庫中的數據是按照一定的主題域進行組織。主題是指用戶使用數據倉庫進行決策時所關心的重點方面，一個主題通常與多個操作型信息系統相關。
2、數據倉庫是集成的，數據倉庫的數據有來自於分散的操作型數據，將所需數據從原來的數據中抽取出來，進行加工與集成，統一與綜合之後才能進入數據倉庫；
數據倉庫中的數據是在對原有分散的數據庫數據抽取、清理的基礎上經過系統加工、彙總和整理得到的，必須消除源數據中的不一致性，以保證數據倉庫內的信息是關於整個企業的一致的全局信息。
數據倉庫的數據主要供企業決策分析之用，所涉及的數據操作主要是數據查詢，一旦某個數據進入數據倉庫以後，一般情況下將被長期保留，也就是數據倉庫中一般有大量的查詢操作，但修改和刪除操作很少，通常只需要定期的加載、刷新。
數據倉庫中的數據通常包含歷史信息，系統記錄了企業從過去某一時點(如開始應用數據倉庫的時點)到當前的各個階段的信息，通過這些信息，可以對企業的發展歷程和未來趨勢做出定量分析和預測。
3、數據倉庫是不可更新的，數據倉庫主要是爲決策分析提供數據，所涉及的操作主要是數據的查詢；
4、數據倉庫是隨時間而變化的，傳統的關係數據庫系統比較適合處理格式化的數據，能夠較好的滿足商業商務處理的需求。穩定的數據以只讀格式保存，且不隨時間改變。
5、彙總的。操作性數據映射成決策可用的格式。
6、大容量。時間序列數據集合通常都非常大。
7、非規範化的。Dw數據可以是而且經常是冗餘的。
8、元數據。將描述數據的數據保存起來。
9、數據源。數據來自內部的和外部的非集成操作系統
10.效率足夠高,數據倉庫的分析數據一般分爲日、周、月、季、年等，可以看出，日爲週期的數據要求的效率最高，要求24小時甚至12小時內，客戶能看到昨天的數據分析。由於有的企業每日的數據量很大，設計不好
的數據倉庫經常會出問題，延遲1-3日才能給出數據，顯然不行的
11.數據質量。數據倉庫所提供的各種信息，肯定要準確的數據，但由於數據倉庫流程通常分爲多個步驟，包括數據清洗，裝載，查詢，展現等等，複雜的架構會更多層次，
那麼由於數據源有髒數據或者代碼不嚴謹，都可以導致數據失真，客戶看到錯誤的信息就可能導致分析出錯誤的決策，造成損失，而不是效益
12.擴展性。之所以有的大型數據倉庫系統架構設計複雜，是因爲考慮到了未來3-5年的擴展性，這樣的話，未來不用太快花錢去重建數據倉庫系統，就能很穩定運行。主要體現在數據建模的合理性，
數據倉庫方案中多出一些中間層，使海量數據流有足夠的緩衝，不至於數據量大很多，就運行不起來了
**************************************************************************************************************/
/*********************************************[sql優化]********************************************************
1.不要使用ORDER BY RAND()
MySQL會不得不去執行RAND()函數（很耗CPU時間），而且這是爲了每一行記錄去記行，然後再對其排序
2.避免使用SELECT *
客戶端用一個單獨的數據包將查詢請求發送給服務器，所以當查詢語句很長的時候，需要設置max_allowed_packet參數。
但是需要注意的是，如果查詢實在是太大，服務端會拒絕接收更多數據並拋出異常。與之相反的是，服務器響應給用戶
的數據通常會很多，由多個數據包組成。但是當服務器響應客戶端請求時，客戶端必須完整的接收整個返回結果，而不
能簡單的只取前面幾條結果，然後讓服務器停止發送。因而在實際開發中，儘量保持查詢簡單且只返回必需的數據，減
小通信間數據包的大小和數量是一個非常好的習慣，這也是查詢中儘量避免使用SELECT *以及加上LIMIT限制的原因之一
sql優化其實主要就圍繞着索引和緩存以及系統損耗的方向去思考即可
**************************************************************************************************************/
-- 分頁優化(當limit的數據達到數千萬條的時候,查詢百萬頁的數據效率問題)
SELECT COUNT(*) FROM student;
SELECT * FROM student LIMIT 4224560,10;-- 不優化的分頁
INSERT INTO student(course) SELECT course FROM student LIMIT 0,2000000
SELECT id,student_name,sex,course FROM student WHERE id >= ( SELECT id FROM student LIMIT 4224560,1) LIMIT 0,10;-- 優化後的分頁,利用了id的索引快速定位到要開始分頁的那條數據
-- sql同時刪除多張表的數據
DELETE help_center_entry,whelp_center_config,help_template
FROM help_center_entry
LEFT JOIN help_template
ON help_center_entry.tnt_inst_id=help_template.tnt_inst_id
LEFT JOIN whelp_center_config
ON help_center_entry.tnt_inst_id=whelp_center_config.tnt_inst_id
WHERE help_center_entry.tnt_inst_id='YVXNVICN';
-- 利用LIMIT 1取得唯一行,有時，當你要查詢一張表是，你知道自己只需要看一行。你可能會去的一條十分獨特的記錄，
-- 或者只是剛好檢查了任何存在的記錄數，他們都滿足了你的WHERE子句。
-- 在這種情況下，增加一個LIMIT 1會令你的查詢更加有效。這樣數據庫引擎發現只有1後將停止掃描，而不是去掃描整個表或索引。
SELECT * FROM student WHERE course='計算機科學與技術1111' -- 0.004s
SELECT * FROM student WHERE course='計算機科學與技術1111' LIMIT 1 -- 7.5s
/*****************************************[數據庫連接方面]*****************************************************
max_connections是指MySQL服務實例能夠同時接受的的最大併發連接數。MySQL實際上支持最大連接數加一的算法，保障當連接
數用完的時候，超級管理員依然可以和服務端建立連接，進行管理。
max_user_connections設置指定賬號的最大併發連接數。
max_connect_errors 當某臺非法主機惡意連接MySQL服務端，遭到的錯誤達到設置值後，MySQL會解決來自該主機的所有連接。
但執行flush hosts後會清零。
Connection_errors_max_connections 當MySQL的最大併發數大於系統變量（show variables）中max_connections的最大併發數，
因此而被拒絕的次數，將會記錄在這個變量裏。如果Connection_error_max_connections值比較大，則說明當前系統併發比較高，
要考慮調大max_connections的值。
Connections表示MySQL從啓動至今，成功建立連接的連接數，這個值是不斷累加的。
Max_used_connections表示MySQL從啓動至今，同一時刻併發的連接數，取得是最大值。如果這個值大於 max_connections則表明
系統經常處於高併發的狀態，應該考慮調大最大併發連接數。
thread_cache_size 設置連接線程緩存的數目。這個緩存相當於MySQL線程的緩存池（thread cache pool）,將空閒的連接線程放
入連接池中緩存起來，而非立即銷燬。當有新的連接請求時，如果連接池中有空閒的連接，則直接使用。否則要重新創建線程。
創建線程是一個不小的系統開銷。MySQL的這部分線程處理和Nginx 的線程處理有異曲同工之妙，以後介紹Nginx的線程處理時，會拿來做對比。
thread_handling 默認值是： one-thread-per-connection 表示爲每個連接提供或者創建一個線程來處理請求，直至請求完畢，
連接銷燬或者存入緩存池。當值是no-threads 時，表示在始終只提供一個線程來處理連接，一般是單機做測試使用的。
thread_stack stack 是堆的意思，由PHP 進程詳解這篇博客，知道進程和線程都是有唯一的ID的，進程的ID系統會維護，二線
程的ID,則由具體的線程庫區維護，當進程或者線程休眠的時候，進程的上下文信息要在內存中開闢出一塊區域，保存進程的上
下文信息，以便於迅速喚醒程序。默認爲MySQL的每個線程設置的堆棧大小爲：262144/1024=256k
Thread_cached 當前線程池的線程數
Thread_connected 當前的連接數
Thread_created: 當前連接線程創建數, 如果這個值過高，可以調整threadcachesize 也就是調整線程緩存池的大小。
Thred_running: 當前活躍的線程數。
**************************************************************************************************************/
SHOW VARIABLES LIKE '%connect%'; -- 連接參數
SHOW STATUS LIKE '%connections%'; -- 連接狀態
SHOW VARIABLES LIKE 'thread%'; -- 連接線程參數
SHOW STATUS LIKE 'Thread%'; -- 查看線程狀態信息
轉載來源:https://blog.csdn.net/weixin_38907570/article/details/80684961