關於mysql資料庫效能分析點
mysql中innodb_flush_log_at_trx_commit和sync_binlog 兩個引數是控制mysql 磁碟寫入策略以及資料安全性的關鍵引數。
mysql的binlog是邏輯日誌，其記錄是對應的sql語句, 記錄了所有的ddl和dml語句（除了資料查詢語句select），以事件形式記錄，還包含語句所執行的消耗的時間，mysql的二進位制日誌是事務安全型的。
innodb儲存引擎層面的重做日誌是物理日誌，innodb儲存引擎的重做日誌在事務進行中不斷地被寫入，日誌不是隨事務提交的順序進行寫入的。
二進位制日誌僅在事務提交時記錄，並且對於每乙個事務，僅在事務提交時記錄，並且對於每乙個事務，僅包含對應事務的乙個日誌。
innodb儲存引擎的重做日誌，由於其記錄是物理操作日誌，每個事務對應多個日誌條目，並且事務的重做日誌寫入是併發的，並非在事務提交時寫入，做其在檔案中記錄的順序並非是事務開始的順序。
innodb_flush_log_at_trx_commit是 innodb 引擎特有的，ib_logfile的重新整理方式（ib_logfile：記錄的是redo log和undo log的資訊）
檢視引數如下：
showvariables like 'innodb_flush%';
|innodb_flush_log_at_trx_commit | 1 |
innodb_flush_log_at_trx_commit設定為0，log buffer將每秒一次地寫入logfile中，並且log file的flush(刷到磁碟)操作同時進行. 該模式下，在事務提交的時候，不會主動觸發寫入磁碟的操作。如果innodb_flush_log_at_trx_commit設定為1，每次事務提交時mysql都會把log buffer的資料寫入log file，並且flush(刷到磁碟)中去。如果innodb_flush_log_at_trx_commit設定為2，每次事務提交時mysql會把log buffer的資料寫入logfile.但是flush(刷到磁碟)操作並不會同時進行。該模式下,mysql會每秒執行一次 flush(刷到磁碟)操作。
0：當mysql掛了之後，可能會損失前一秒的事務資訊
2：當mysql掛了之後，如果系統檔案系統沒掛，不會有事務丟失
sync_binlog：是mysql 的二進位制日誌（binarylog）同步到磁碟的頻率。
sync_binlog=0，當事務提交之後，mysql不做fsync之類的磁碟同步指令重新整理binlog_cache中的資訊到磁碟，而讓filesystem自行決定什麼時候來做同步，或者cache滿了之後才同步到磁碟。等待作業系統的fdatasync從記憶體flush到磁碟。
sync_binlog=1，當每進行1次事務提交之後，mysql將進行一次fsync之類的磁碟同步指令來將binlog_cache中的資料強制寫入磁碟。
sync_binlog=n，當每進行n次事務提交之後，mysql將進行一次fsync之類的磁碟同步指令來將binlog_cache中的資料強制寫入磁碟。
innodb_log_file_size調整日誌檔案大小。
innodb_log_files_in_group調整日誌檔案數量。
innodb_log_group_home_dir調整日誌檔案位於目錄。
innodb_log_file_size會影響效能，預設設定為5m，難以滿足生產環境下的需求。日誌檔案在mysql例項第一次啟動時初始化，該檔案是旋轉的和oracle資料庫是類似的，可以根據檔案修改時間來判斷日誌檔案的旋轉頻率，如果太頻繁，說明日誌檔案太小需要擴大。innodb_log_file_size設定大小通常視innodb_buffer_pool_size而定。
引數innodb_log_buffer_size確保有足夠大的日誌緩衝區來儲存髒資料在被寫入到日誌檔案之前。該變數將資料存匯入到記憶體中，可以減少大量的io資源消耗。當事務提交時，儲存髒資料，後續在重新整理到磁碟。調整innodb_buffer_pool_size大小時，innodb_log_buffer_size和innodb_log_file_size也應該做出相應的調整。
innodb_log_file_size是靜態的變數，需要以「乾淨」的方式更改並重新啟動
unix實現在核心中設有緩衝區快取記憶體或頁面快取記憶體，大多數磁碟i/o都通過緩衝進行。
當將資料寫入檔案時，核心通常先將該資料複製到其中乙個緩衝區中，如果該緩衝區尚未寫滿，則並不將其排入輸出佇列，而是等待其寫滿或者當核心需要重用該緩衝區以便存放其他磁碟塊資料時，再將該緩衝排入輸出佇列，這種輸出方式被稱為延遲寫（delayed write）。
為了保證磁碟上實際檔案系統與緩衝區快取記憶體中內容的一致性，unix系統提供了sync、fsync和fdatasync三個函式。
sync函式只是將所有修改過的塊緩衝區排入寫佇列，然後返回，它並不等待實際寫磁碟操作結束。
通常稱為update的系統守護程序會周期性地（一般每隔30秒）呼叫sync函式。這就保證了定期沖洗核心的塊緩衝區。命令sync(1)也呼叫sync函式。
fsync函式只對由檔案描述符filedes指定的單一檔案起作用，並且等待寫磁碟操作結束，然後返回。fsync可用於資料庫這樣的應用程式。fsync的功能是確保檔案fd所有已修改的內容已經正確同步到硬碟上，該呼叫會阻塞等待直到裝置報告io完成。除了同步檔案的修改內容（髒頁），fsync還會同步檔案的描述資訊（metadata，包括size、訪問時間st_atime & st_mtime等等），因為檔案的資料和metadata通常存在硬碟的不同地方，因此fsync至少需要兩次io寫操作。
fdatasync函式類似於fsync，但它只影響檔案的資料部分。而所以從效能上來看fdatasync是要優於fsync的。
a) innodb_buffer_pool_size:緩衝池是資料和索引快取的地方，保證你在大多數的讀取操作時使用的是記憶體。檢視命令：show variables like '%buffer_pool_size%'
b)innodb_log_file_size：這是redo日誌的大小。redo日誌被用於確保寫操作快速而可靠並且在崩潰時恢復。可以一開始就把innodb_log_file_size設定成512m(這樣有1gb的redo日誌)會使你有充裕的寫操作空間。如果你知道你的應用程式需要頻繁的寫入資料並且你使用的時mysql 5.6，你可以一開始就把它這是成4g。
c)max_connections:經常看到『too many connections'錯誤，是因為max_connections的值太低了。因為應用程式沒有正確的關閉資料庫連線，需要比預設的151連線數更大的值。在應用程式裡使用連線池或者在mysql裡使用程序池有助於解決這一問題。
d) binlog_cache_size :表示binlog能夠使用的最大cache記憶體大小,當執行多語句事務的時候所有session的使用的記憶體超過max_binlog_cache_size的值時,就會報錯：「multi-statementtransaction required more than 'max_binlog_cache_size' bytes ofstorage」,設定太大的話，會比較消耗記憶體資源;設定太小又會使用到臨時檔案即磁碟io。
e) innodb_log_buffer_size控制在2-8m。不用太多的，裡面的記憶體資料最慢一秒鐘寫到磁碟一次。具體寫入方式和你的事務提交方式有關。
mysql 5.5版本開始，innodb是預設的儲存引擎。
a)innodb_file_per_table：這項設定告知innodb是否需要將所有表的資料和索引存放在共享表空間裡（innodb_file_per_table= off） 或者為每張表的資料單獨放在乙個.ibd檔案（innodb_file_per_table =on）。每張表乙個檔案允許你在drop、truncate或者rebuild表時**磁碟空間。這對於一些高階特性也是有必要的，比如資料壓縮。但是它不會帶來任何效能收益。有非常多的表時候可以off掉。mysql 5.6中，這個屬性預設值是on。
b) innodb_flush_log_at_trx_commit：預設值為1，表示innodb完全支援acid特性。
d) innodb_log_buffer_size: 這項配置決定了為尚未執行的事務分配的快取。其預設值（1mb）一般來說已經夠用了，但是如果你的事務中包含有二進位製大物件或者大文字字段的話，這點快取很快就會被填滿並觸發額外的i/o操作。看看innodb_log_waits狀態變數，如果它不是0，增加innodb_log_buffer_size。
mysql資料庫效能資料 MYSQL資料庫效能優化
1.選取最適用的字段屬性 表中字段的寬度設得盡可能小 char 的上限為 255 位元組 固定占用空間 varchar 的上限 65535 位元組 實際占用空間 text 的上限為 65535。盡量把字段設定為 not null，執行查詢的時候，資料庫不用去比較 null 值。2.使用連線 join...
關於mySQL資料庫的效能優化
1 wait timeout時間設定 連線數是直接反應資料庫效能好壞的關鍵指標，連線數過多，很可能有多種原因，比如，被一條sql查詢給堵了，造成後面的dml操作等待，又比如，增，刪，改，查操作很頻繁，磁碟io遇到了瓶頸，導致無法處理繁忙的請求，也許有人說增大max connections值就行了吧，...
MySQL資料庫效能優化 硬體瓶頸分析
在過往與很多人的交流過程中發現，在談到基於硬體來進行資料庫效能瓶頸分析的時候，常被大家誤解為簡單的使用更為強勁的主機或者儲存來替換現有的裝置。個人覺得這其中可能存在乙個非常大的誤區。我們在談論基於硬體進行優化的時候，不能僅僅將資料庫使用的硬體劃分為主機和儲存兩部分，而是需要進一步對硬體進行更細的分解...