MySQL學習筆記小結

MySQL學習筆記小結。本站提示廣大學習愛好者：（MySQL學習筆記小結）文章只能為提供參考，不一定能成為您想要的結果。以下是MySQL學習筆記小結正文

慢速SQL：執行時間超越給定時間范圍的查詢就稱為慢速查詢。
在MySQL中如何記載慢速SQL？
答：可以在my.cnf中設置如下信息：

[mysqld]
; enable the slow query log, default 10 seconds
log-slow-queries
; log queries taking longer than 5 seconds
long_query_time = 5
; log queries that don't use indexes even if they take less than long_query_time
; MySQL 4.1 and newer only
log-queries-not-using-indexes

這三個設置的意思是可以記載執行時間超越5 秒和沒有運用索引的查詢.
MySQL中日志分類：
1. error log mysql錯誤記載日志
2. bin log 記載修正數據時分發生的quer並用二進制的方式停止存儲
3. mysql-bin.index 記載是記載一切Binary Log 的相對途徑，保證MySQL 各種線程可以順利的依據它找到一切需求的Binary Log 文件。
4. slow query log 記載慢速SQL，是一個復雜的文本格式，可以經過各種文本編輯器檢查其中的內容。其中記載了語句執行的時辰，執行所耗費的時間，執行用戶。
5. innodb redo log 記載Innodb 所做的一切物理變卦和事務信息，保證事務平安性。

SQL架構可分為：SQL 層 與 Storage Engine層
SQL Layer 中包括了多個子模塊：
1、初始化模塊
顧名思議，初始化模塊就是在MySQL Server 啟動的時分，對整個零碎做各種各樣的初始化操作，比方各種buffer，cache 構造的初始化和內存空間的請求，各種零碎變量的初始化設定，各種存儲引擎的初始化設置，等等。
2、中心API
中心API 模塊次要是為了提供一些需求十分高效的底層操作功用的優化完成，包括各種底層數據構造的完成，特殊算法的完成，字符串處置，數字處置等，小文件I/O，格式化輸入，以及最重要的內存管理局部。中心API 模塊的一切源代碼都集中在mysys 和strings文件夾上面，有興味的讀者可以研討研討。
3、網絡交互模塊
底層網絡交互模塊籠統出底層網絡交互所運用的接口api，完成底層網絡數據的接納與發送，以方便其他各個模塊調用，以及對這一局部的維護。一切源碼都在vio 文件夾上面。
4、Client & Server 交互協議模塊
任何C/S 構造的軟件零碎，都一定會有自己獨有的信息交互協議，MySQL 也不例外。MySQL的Client & Server 交互協議模塊局部，完成了客戶端與MySQL 交互進程中的一切協議。當然這些協議都是樹立在現有的OS 和網絡協議之上的，如TCP/IP 以及Unix Socket。
5、用戶模塊
用戶模塊所完成的功用，次要包括用戶的登錄銜接權限控制和用戶的受權管理。他好像MySQL 的大門守衛一樣，決議能否給來訪者“開門”。
6、訪問控制模塊
造訪主人進門了就可以想干嘛就干嘛麼？為了平安思索，一定不能如此隨意。這時分就需求訪問控制模塊實時監控主人的每一個舉措，給不同的主人以不同的權限。訪問控制模塊完成的功用就是依據用戶模塊中各用戶的受權信息，以及數據庫本身特有的各種約束，來控制用戶對數據的訪問。用戶模塊和訪問控制模塊兩者結合起來，組成了MySQL 整個數據庫零碎的權限平安管理的功用。
7、銜接管理、銜接線程和線程管理
銜接管理模塊擔任監聽對MySQL Server 的各種懇求，接納銜接懇求，轉發一切銜接懇求到線程管理模塊。每一個銜接上MySQL Server 的客戶端懇求都會被分配（或創立）一個銜接線程為其獨自服務。而銜接線程的次要任務就是擔任MySQL Server 與客戶端的通訊，承受客戶端的命令懇求，傳遞Server 端的後果信息等。線程管理模塊則擔任管理維護這些銜接線程。包括線程的創立，線程的cache 等。
8、Query 解析和轉發模塊
在MySQL 中我們習氣將一切Client 端發送給Server 端的命令都稱為query，在MySQLServer 外面，銜接線程接納到客戶端的一個Query 後，會直接將該query 傳遞給專門擔任將各種Query 停止分類然後轉發給各個對應的處置模塊，這個模塊就是query 解析和轉發模塊。其次要任務就是將query 語句停止語義和語法的剖析，然後依照不同的操作類型停止分類，然後做出針對性的轉發。
9、Query Cache 模塊
Query Cache 模塊在MySQL 中是一個十分重要的模塊，他的次要功用是將客戶端提交給MySQL 的Select 類query 懇求的前往後果集cache 到內存中，與該query 的一個hash 值做一個對應。該Query 所取數據的基表發作任何數據的變化之後，MySQL 會自動使該query 的Cache 生效。在讀寫比例十分高的使用零碎中，Query Cache 對功能的進步是十分明顯的。當然它對內存的耗費也是十分大的。
10、Query 優化器模塊
Query 優化器，望文生義，就是優化客戶端懇求的query，依據客戶端懇求的query 語句，和數據庫中的一些統計信息，在一系列算法的根底上停止剖析，得出一個最優的戰略，通知前面的順序如何獲得這個query 語句的後果。
11、表變卦管理模塊
表變卦管理模塊次要是擔任完成一些DML 和DDL 的query，如：update，delte，insert，create table，alter table 等語句的處置。
12、表維護模塊
表的形態反省，錯誤修復，以及優化和剖析等任務都是表維護模塊需求做的事情。
13、零碎形態管理模塊
零碎形態管理模塊擔任在客戶端懇求零碎形態的時分，將各種形態數據前往給用戶，像DBA 常用的各種show status 命令，show variables 命令等，所失掉的後果都是由這個模塊前往的。
14、表管理器
這個模塊從名字上看來很容易和下面的表變卦和表維護模塊相混雜，但是其功用與變卦及維護模塊卻完全不同。大家知道，每一個MySQL 的表都有一個表的定義文件，也就是*.frm文件。表管理器的任務次要就是維護這些文件，以及一個cache，該cache 中的次要內容是各個表的構造信息。此外它還維護table 級別的鎖管理。
15、日志記載模塊
日志記載模塊次要擔任整個零碎級別的邏輯層的日志的記載，包括error log，binarylog，slow query log 等。
16、復制模塊
復制模塊又可分為Master 模塊和Slave 模塊兩局部， Master 模塊次要擔任在Replication 環境中讀取Master 端的binary 日志，以及與Slave 端的I/O 線程交互等任務。Slave 模塊比Master 模塊所要做的事情稍多一些，在零碎中次要表現在兩個線程下面。一個是擔任從Master 懇求和承受binary 日志，並寫入本地relay log 中的I/O 線程。另外一個是擔任從relay log 中讀取相關日志事情，然後解析成可以在Slave 端正確執行並失掉和Master 端完全相反的後果的命令並再交給Slave 執行的SQL 線程。
17、存儲引擎接口模塊
存儲引擎接口模塊可以說是MySQL 數據庫中最有特征的一點了。目前各種數據庫產品
中，根本上只要MySQL 可以完成其底層數據存儲引擎的插件式管理。這個模塊實踐上只是一個籠統類，但正是由於它成功地將各種數據處置高度籠統化，才成就了明天MySQL 可插拔存儲引擎的特征。

MySQL功能調優之監控辦法：

1. set profiling=1 開啟功能監控，此命令在某些版本的mysql中無法運用
2. 然後執行SQL
3. show profiless，檢查零碎執行SQL的時間
4. show profile cpu, block io for query 數字ID （此ID為show profiles中的功能輸入日志序號）

 MySQL 各存儲引擎運用了三品種型（級別）的鎖定機制：行級鎖定，頁級鎖定和表級鎖定。
在MySQL 數據庫中，運用表級鎖定的次要是MyISAM，Memory，CSV 等一些非事務性存儲引擎，而運用行級鎖定的次要是Innodb 存儲引擎和NDB Cluster 存儲引擎，頁級鎖定次要是BerkeleyDB 存儲引擎的鎖定方式。
 
MyISAM讀懇求和寫等候隊列中的寫鎖懇求的優先級規則次要為以下規則決議：
1. 除了READ_HIGH_PRIORITY 的讀鎖定之外，Pending write-lock queue 中的WRITE 寫鎖定可以阻塞一切其他的讀鎖定；
2. READ_HIGH_PRIORITY 讀鎖定的懇求可以阻塞一切Pending write-lock queue 中的寫鎖定；
3. 除了WRITE 寫鎖定之外，Pending write-lock queue 中的其他任何寫鎖定都比讀鎖定的優先級低。

MyISAM寫鎖定呈現在Current write-lock queue 之後，會阻塞除了以下狀況下的一切其他鎖定的懇求：
1. 在某些存儲引擎的允許下，可以允許一個WRITE_CONCURRENT_INSERT 寫鎖定懇求
2. 寫鎖定為WRITE_ALLOW_WRITE 的時分，允許除了WRITE_ONLY 之外的一切讀和寫鎖定懇求
3. 寫鎖定為WRITE_ALLOW_READ 的時分，允許除了READ_NO_INSERT 之外的一切讀鎖定懇求
4. 寫鎖定為WRITE_DELAYED 的時分，允許除了READ_NO_INSERT 之外的一切讀鎖定懇求
5. 寫鎖定為WRITE_CONCURRENT_INSERT 的時分，允許除了READ_NO_INSERT 之外的一切讀鎖定懇求
 
Innodb 的行級鎖定留意事項：
a) 盡能夠讓一切的數據檢索都經過索引來完成，從而防止Innodb 由於無法經過索引鍵加鎖而晉級為表級鎖定；
b) 合理設計索引，讓Innodb 在索引鍵下面加鎖的時分盡能夠精確，盡能夠的減少鎖定范圍，防止形成不用要的鎖定而影響其他Query 的執行；
c) 盡能夠增加基於范圍的數據檢索過濾條件，防止由於間隙鎖帶來的負面影響而鎖定了不該鎖定的記載；
d) 盡量控制事務的大小，增加鎖定的資源量和鎖定時間長度；
e) 在業務環境允許的狀況下，盡量運用較低級別的事務隔離，以增加MySQL 由於完成事務隔離級別所帶來的附加本錢；
如何檢查MyISAM中表級鎖定信息：
答：show status like '%table_locks%'
     table_locks_immediate:顯示的數字就是鎖定的次數。
     table_locks_waited:顯示的數字是呈現表級鎖定爭用而發作等候的次數
 
如何檢查Innodb中行級鎖定信息：
答： show status like '%Innodb_rows%'
Innodb 的行級鎖定形態變量不只記載了鎖定等候次數，還記載了鎖定總時長，每次均勻時長，以及最大時長，此外還有一個非累積形態量顯示了以後正在等候鎖定的等候數量。對各個形態量的闡明如下：
● Innodb_row_lock_current_waits：以後正在等候鎖定的數量；
● Innodb_row_lock_time：從零碎啟動到如今鎖定總時間長度；
● Innodb_row_lock_time_avg：每次等候所花均勻時間；
● Innodb_row_lock_time_max：從零碎啟動到如今等候最常的一次所花的時間；
● Innodb_row_lock_waits：零碎啟動後到如今總共等候的次數；
 
mysqlslap是一個mysql官方提供的壓力測試工具。以下是比擬重要的參數：
–defaults-file，配置文件寄存地位
–concurrency，並發數
–engines，引擎
–iterations，迭代的實驗次數
–socket，socket文件地位
自動測試：
–auto-generate-sql，自動發生測試SQL
–auto-generate-sql-load-type，測試SQL的類型。類型有mixed，update，write，key，read。
–number-of-queries，執行的SQL總數量
–number-int-cols，表內int列的數量
–number-char-cols，表內char列的數量
例如：
shell>mysqlslap –defaults-file=/u01/mysql1/mysql/my.cnf –concurrency=50,100 –iterations=1 –number-int-cols=4 –auto-generate-sql –auto-generate-sql-load-type=write –engine=myisam –number-of-queries=200 -S/tmp/mysql1.sock
Benchmark
Running for engine myisam
Average number of seconds to run all queries: 0.016 seconds
Minimum number of seconds to run all queries: 0.016 seconds
Maximum number of seconds to run all queries: 0.016 seconds
Number of clients running queries: 50
Average number of queries per client: 4
Benchmark
Running for engine myisam
Average number of seconds to run all queries: 0.265 seconds
Minimum number of seconds to run all queries: 0.265 seconds
Maximum number of seconds to run all queries: 0.265 seconds
Number of clients running queries: 100
Average number of queries per client: 2
指定數據庫的測試：
–create-schema，指定數據庫稱號
–query，指定SQL語句，可以定位到某個包括SQL的文件
例如：
shell>mysqlslap –defaults-file=/u01/mysql1/mysql/my.cnf –concurrency=25,50 –iterations=1 –create-schema=test –query=/u01/test.sql -S/tmp/mysql1.sock
Benchmark
Average number of seconds to run all queries: 0.018 seconds
Minimum number of seconds to run all queries: 0.018 seconds
Maximum number of seconds to run all queries: 0.018 seconds
Number of clients running queries: 25
Average number of queries per client: 1
Benchmark
Average number of seconds to run all queries: 0.011 seconds
Minimum number of seconds to run all queries: 0.011 seconds
Maximum number of seconds to run all queries: 0.011 seconds
Number of clients running queries: 50
Average number of queries per client: 1
 
MySQL 中索引運用相關的限制:
1. MyISAM 存儲引擎索引鍵長度總和不能超越1000 字節；
2. BLOB 和TEXT 類型的列只能創立前綴索引；
3. MySQL 目前不支持函數索引；
4. 運用不等於（!= 或許<>）的時分MySQL 無法運用索引；
5. 過濾字段運用了函數運算後（如abs(column)），MySQL 無法運用索引；
6. Join 語句中Join 條件字段類型不分歧的時分MySQL 無法運用索引；
7. 運用LIKE 操作的時分假如條件以通配符開端（ '%abc...'）MySQL 無法運用索引；
8. 運用非等值查詢的時分MySQL 無法運用Hash 索引；
MySQL 目前可以經過兩種算法來完成數據的排序操作:
1. 取出滿足過濾條件的用於排序條件的字段以及可以直接定位到行數據的行指針信息，在SortBuffer 中停止實踐的排序操作，然後應用排好序之後的數據依據行指針信息前往表中獲得客戶端懇求的其他字段的數據，再前往給客戶端；
2. 依據過濾條件一次取出排序字段以及客戶端懇求的一切其他字段的數據，並將不需求排序的字段寄存在一塊內存區域中，然後在Sort Buffer 中將排序字段和行指針信息停止排序，最後再應用排序後的行指針與寄存在內存區域中和其他字段一同的行指針信息停止婚配兼並後果集，再依照順序前往給客戶端。
 
MySQL Explain 功用中給我們展現的各種信息的解釋：
◆ ID：Query Optimizer 所選定的執行方案中查詢的序列號；
◆ Select_type：所運用的查詢類型，次要有以下這幾種查詢類型
◇ DEPENDENT SUBQUERY：子查詢中內層的第一個SELECT，依賴於內部查詢的後果集；
◇ DEPENDENT UNION：子查詢中的UNION，且為UNION 中從第二個SELECT 開端的前面一切SELECT，異樣依賴於內部查詢的後果集；
◇ PRIMARY：子查詢中的最外層查詢，留意並不是主鍵查詢；
◇ SIMPLE：除子查詢或許UNION 之外的其他查詢；
◇ SUBQUERY：子查詢內層查詢的第一個SELECT，後果不依賴於內部查詢後果集；
◇ UNCACHEABLE SUBQUERY：後果集無法緩存的子查詢；
◇ UNION：UNION 語句中第二個SELECT 開端的前面一切SELECT，第一個SELECT 為PRIMARY
◇ UNION RESULT：UNION 中的兼並後果；
◆ Table：顯示這一步所訪問的數據庫中的表的稱號；
◆ Type：通知我們對表所運用的訪問方式，次要包括如下集中類型；
◇ all：全表掃描
◇ const：讀常量，且最多只會有一條記載婚配，由於是常量，所以實踐上只需求讀一次；
◇ eq_ref：最多只會有一條婚配後果，普通是經過主鍵或許獨一鍵索引來訪問；
◇ fulltext：
◇ index：全索引掃描；
◇ index_merge：查詢中同時運用兩個（或更多）索引，然後對索引後果停止merge 之後再讀取表數據；
◇ index_subquery：子查詢中的前往後果字段組合是一個索引（或索引組合），但不是一個主鍵或許獨一索引；
◇ rang：索引范圍掃描；
◇ ref：Join 語句中被驅動表索引援用查詢；
◇ ref_or_null：與ref 的獨一區別就是在運用索引援用查詢之外再添加一個空值的查詢；
◇ system：零碎表，表中只要一行數據；
◇ unique_subquery：子查詢中的前往後果字段組合是主鍵或許獨一約束；
◆ Possible_keys：該查詢可以應用的索引. 假如沒有任何索引可以運用，就會顯示成null，這一項內容關於優化時分索引的調整十分重要；
◆ Key：MySQL Query Optimizer 從possible_keys 中所選擇運用的索引；
◆ Key_len：被選中運用索引的索引鍵長度；
◆ Ref：列出是經過常量（const），還是某個表的某個字段（假如是join）來過濾（經過key）的；
◆ Rows：MySQL Query Optimizer 經過零碎搜集到的統計信息預算出來的後果集記載條數；
◆ Extra：查詢中每一步完成的額定細節信息，次要能夠會是以下內容：
◇ Distinct：查找distinct 值，所以當mysql 找到了第一條婚配的後果後，將中止該值的查詢而轉為前面其他值的查詢；
◇ Full scan on NULL key：子查詢中的一種優化方式，次要在遇到無法經過索引訪問null值的運用運用；
◇ Impossible WHERE noticed after reading const tables：MySQL Query Optimizer 經過搜集到的統計信息判別出不能夠存在後果；
◇ No tables：Query 語句中運用FROM DUAL 或許不包括任何FROM 子句；
◇ Not exists：在某些左銜接中MySQL Query Optimizer 所經過改動原有Query 的組成而運用的優化辦法，可以局部增加數據訪問次數；
◇ Range checked for each record (index map: N)：經過MySQL 官方手冊的描繪，當MySQL Query Optimizer 沒有發現好的可以運用的索引的時分，假如發現假如來自後面的表的列值已知，能夠局部索引可以運用。對後面的表的每個行組合，MySQL 反省能否可以運用range 或index_merge 訪問辦法來討取行。
◇ Select tables optimized away：當我們運用某些聚合函數來訪問存在索引的某個字段的時分，MySQL Query Optimizer 會經過索引而直接一次定位到所需的數據行完成整個查詢。當然，前提是在Query 中不能有GROUP BY 操作。如運用MIN()或許MAX（）的時
候；
◇ Using filesort：當我們的Query 中包括ORDER BY 操作，而且無法應用索引完成排序操作的時分，MySQL Query Optimizer 不得不選擇相應的排序算法來完成。
◇ Using index：所需求的數據只需求在Index 即可全部取得而不需求再到表中取數據；
◇ Using index for group-by：數據訪問和Using index 一樣，所需數據只需求讀取索引即可，而當Query 中運用了GROUP BY 或許DISTINCT 子句的時分，假如分組字段也在索引中，Extra 中的信息就會是Using index for group-by；
◇ Using temporary：當MySQL 在某些操作中必需運用暫時表的時分，在Extra 信息中就會呈現Using temporary 。次要罕見於GROUP BY 和ORDER BY 等操作中。
◇ Using where：假如我們不是讀取表的一切數據，或許不是僅僅經過索引就可以獲取一切需求的數據，則會呈現Using where 信息；
◇ Using where with pushed condition：這是一個僅僅在NDBCluster 存儲引擎中才會呈現的信息，而且還需求經過翻開Condition Pushdown 優化功用才能夠會被運用。控制參數為engine_condition_pushdown 。
 
什麼是松懈索引？
答：實踐上就是當MySQL 完全應用索引掃描來完成GROUP BY 的時分，並不需求掃描一切滿足條件的索引鍵即可完成操作得出後果。
要應用到松懈索引掃描完成GROUP BY，需求至多滿足以下幾個條件：
◆ GROUP BY 條件字段必需在同一個索引中最後面的延續地位；
◆ 在運用GROUP BY 的同時，只能運用MAX 和MIN 這兩個聚合函數；
◆ 假如援用到了該索引中GROUP BY 條件之外的字段條件的時分，必需以常量方式存在；

為什麼松懈索引掃描的效率會很高？
答：由於在沒有WHERE 子句，也就是必需經過全索引掃描的時分， 松懈索引掃描需求讀取的鍵值數量與分組的組數量一樣多，也就是說比實踐存在的鍵值數目要少很多。而在WHERE 子句包括范圍判別式或許等值表達式的時分， 松懈索引掃描查找滿足范圍條件的每個組的第1 個關鍵字，並且再次讀取盡能夠最多數量的關鍵字。
 
什麼是緊湊索引？
答：緊湊索引掃描完成GROUP BY 和松懈索引掃描的區別次要在於他需求在掃描索引的時分，讀取一切滿足條件的索引鍵，然後再依據讀取的數據來完成GROUP BY 操作失掉相應後果。

MySQL 處置GROUP BY 的方式，有兩種如下優化思緒：
1. 盡能夠讓MySQL 可以應用索引來完成GROUP BY 操作，當然最好是松懈索引掃描的方式最佳。在零碎允許的狀況下，我們可以經過調整索引或許調整Query 這兩種方式來到達目的；

2. 當無法運用索引完成GROUP BY 的時分，由於要運用到暫時表且需求filesort，所以我們必需要有足夠的sort_buffer_size 來供MySQL 排序的時分運用，而且盡量不要停止大後果集的GROUPBY 操作，由於假如超出零碎設置的暫時表大小的時分會呈現將暫時表數據copy 到磁盤下面再停止操作，這時分的排序分組操作功能將是成數量級的下降；
 
DINSTINCT 其實和 GROUP BY 原理相似，異樣可以運用松懈索引。
 
MySQL Schema 設計優化小記：
1. 過度冗余
2. 大字段垂直分拆
3. 大表程度分拆
 
時間字段類型：timestamp 占用4個字節，datetime,date占用8個字節，但是timestamp只能用在1970年當前的記載，datetime,date可用在1001年開端。
 
MySQL binlog日志優化方案：

Binlog 相關參數及優化戰略
我們首先看看Binlog 的相關參數，經過執行如下命令可以取得關於Binlog 的相關參數。當然，其中也顯示出了“ innodb_locks_unsafe_for_binlog”這個Innodb 存儲引擎特有的與Binlog 相關的參數：
mysql> show variables like '%binlog%';
+--------------------------------+------------+
| Variable_name | Value |
+--------------------------------+------------+
| binlog_cache_size | 1048576 |
| innodb_locks_unsafe_for_binlog | OFF |
| max_binlog_cache_size | 4294967295 |
| max_binlog_size | 1073741824 |
| sync_binlog | 0 |
+--------------------------------+------------+
“binlog_cache_size"：在事務進程中包容二進制日志SQL 語句的緩存大小。二進制日志緩存是服務器支持事務存儲引擎並且服務器啟用了二進制日志(—log-bin 選項)的前提下為每個客戶端分配的內存，留意，是每個Client 都可以分配設置大小的binlog cache 空間。假如讀者冤家的零碎中常常會呈現多語句事務的華，可以嘗試添加該值的大小，以取得更好的功能。當然，我們可以經過MySQL 的以下兩個形態變量來判別以後的binlog_cache_size 的情況：Binlog_cache_use 和Binlog_cache_disk_use。“max_binlog_cache_size”：和"binlog_cache_size"絕對應，但是所代表的是binlog 可以運用的最大cache 內存大小。當我們執行多語句事務的時分，max_binlog_cache_size 假如不夠大的話，零碎能夠會報出“ Multi-statement transaction required more than 'max_binlog_cache_size' bytes ofstorage”的錯誤。
“max_binlog_size”：Binlog 日志最大值，普通來說設置為512M 或許1G，但不能超越1G。該大小並不能十分嚴厲控制Binlog 大小，尤其是當抵達Binlog 比擬接近尾部而又遇到一個較大事務的時分，零碎為了保證事務的完好性，不能夠做切換日志的舉措，只能將該事務的一切SQL 都記載進入以後日志，直到該事務完畢。這一點和Oracle 的Redo 日志有點不一樣，由於Oracle 的Redo 日志所記載的是數據文件的物理地位的變化，而且外面同時記載了Redo 和Undo 相關的信息，所以同一個事務能否在一個日志中對Oracle 來說並不關鍵。而MySQL 在Binlog 中所記載的是數據庫邏輯變化信息，MySQL 稱之為Event，實踐上就是帶來數據庫變化的DML 之類的Query 語句。“sync_binlog”：這個參數是關於MySQL 零碎來說是至關重要的，他不只影響到Binlog 對MySQL 所帶來的功能損耗，而且還影響到MySQL 中數據的完好性。關於“sync_binlog”參數的各種設置的闡明如下：
● sync_binlog=0，當事務提交之後，MySQL 不做fsync 之類的磁盤同步指令刷新binlog_cache 中的信息到磁盤，而讓Filesystem 自行決議什麼時分來做同步，或許cache 滿了之後才同步到磁盤。
● sync_binlog=n，當每停止n 次事務提交之後，MySQL 將停止一次fsync 之類的磁盤同步指令來將binlog_cache 中的數據強迫寫入磁盤。在MySQL 中零碎默許的設置是sync_binlog=0，也就是不做任何強迫性的磁盤刷新指令，這時分的功能是最好的，但是風險也是最大的。由於一旦零碎Crash，在binlog_cache 中的一切binlog 信息都會被喪失。而當設置為“1”的時分，是最平安但是功能損耗最大的設置。由於當設置為1 的時分，即便零碎Crash，也最多喪失binlog_cache 中未完成的一個事務，對實踐數據沒有任何本質性影響。從以往經歷和相關測試來看，關於高並發事務的零碎來說，“sync_binlog”設置為0 和設置為1 的零碎寫入功能差距能夠高達5 倍甚至更多。
 
MySQL QueryCache 負面影響：
a) Query 語句的hash 運算以及hash 查找資源耗費。當我們運用Query Cache 之後，每條SELECT類型的Query 在抵達MySQL 之後，都需求停止一個hash 運算然後查找能否存在該Query 的Cache，雖然這個hash 運算的算法能夠曾經十分高效了，hash 查找的進程也曾經足夠的優化了，關於一條Query 來說耗費的資源的確是十分十分的少，但是當我們每秒都有上千甚至幾千條Query 的時分，我們就不能對發生的CPU 的耗費完全無視了。
b) Query Cache 的生效問題。假如我們的表變卦比擬頻繁，則會形成Query Cache 的生效率十分高。這裡的表變卦不只僅指表中數據的變卦，還包括構造或許索引等的任何變卦。也就是說我們每次緩存到Query Cache 中的Cache 數據能夠在剛存入後很快就會由於表中的數據被改動而被肅清，然後新的相反Query 出去之後無法運用到之前的Cache。
c) Query Cache 中緩存的是Result Set ，而不是數據頁，也就是說，存在同一條記載被Cache 屢次的能夠性存在。從而形成內存資源的過渡耗費。當然，能夠有人會說我們可以限定QueryCache 的大小啊。是的，我們的確可以限定Query Cache 的大小，但是這樣，Query Cache 就很容易形成由於內存缺乏而被換出，形成命中率的下降。
 
在短銜接的使用零碎中，thread_cache_size 的值應該設置的絕對大一些，不應該小於使用零碎對數據庫的實踐並發懇求數。
 
經過零碎設置和以後形態的剖析，我們可以發現，thread_cache_size 的設置曾經足夠了，甚至還遠大於零碎的需求。所以我們可以適當增加thread_cache_size 的設置，比方設置為8 或許16。依據Connections 和Threads_created 這兩個零碎形態值，我們還可以計算出零碎新建銜接銜接的ThreadCache 命中率，也就是經過Thread Cache 池中獲得銜接線程的次數與零碎接納的總銜接次數的比率，如下：
Threads_Cache_Hit = (Connections - Threads_created) / Connections * 100%
普通來說，當零碎波動運轉一段時間之後，我們的Thread Cache 命中率應該堅持在90%左右甚至更高的比率才算正常。可以看出下面環境中的Thread Cache 命中比率根本還算是正常的。
 
如何檢查MySQL翻開Table的數量：
mysql> show status like 'open_tables';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| Open_tables | 6 |
+---------------+-------+
 
MySQL buffer留意事項
join_buffer_size 和 sort_buffer_size 是針對的每個線程的buffer大小而言的，而不是整個零碎共享的Buffer。
 
假定是一台獨自給MySQL 運用的主機，物理內存總大小為8G，MySQL 最大銜接數為500，同時還運用了MyISAM 存儲引擎，這時分我們的全體內存該如何分配呢？
內存分配為如下幾大局部：
a) 零碎運用，假定預留800M；
b) 線程獨享，約2GB = 500 * (1MB + 1MB + 1MB + 512KB + 512KB)，組成大約如下:
sort_buffer_size：1MB
join_buffer_size：1MB
read_buffer_size：1MB
read_rnd_buffer_size：512KB
thread_statck：512KB
c) MyISAM Key Cache，假定大約為1.5GB；
d) Innodb Buffer Pool 最大可用量：8GB - 800MB - 2GB - 1.5GB = 3.7GB；