mysql參數優化
mysql參數優化
innodb_buffer_pool_size：
先寫入innodb_log_buffer buffer寫滿或事務提交，刷新數據 大事務頻繁，增加innodb_log_buffer_size大小，對於單獨的MySQL數據庫服務器推薦設為物理內存的75%-------------------------------------------
innodb_buffer_pool_instances：
將innodb_buffer_pool劃分為不同的instance 每個instance獨立的LRU、FLUSH、FREE 獨立的mutex控制 --------------------------------------------innodb_log_file_size ：
在mysql 5.5和5.5以前innodb的logfile最大設置為4GB,在5.6以後的版本中logfile最大的可以設為512GB.
innodb的logfile就是事務日誌，用來在mysql crash後的恢復.所以設置合理的大小對於mysql的性能非常重要
在5.5的版本中，default設置為5M.在新建的mysql服務器中，需要盡快修改該參數.
--------------------------------------------
innodb_log_buffer_size：
先寫入innodb_log_buffer buffer寫滿或事務提交，刷新數據 大事務頻繁，增加innodb_log_buffer_size大小--------------------------------------------
innodb_thread_concurrency(並發線程) ：
innodb_thread_concurrency = 0，innodb內部自己控制 –kernel_mutex競爭 –CPU上下文切換 innodb_thread_concurrency設置為cpu的核心數--------------------------------------------
innodb_io_capacity ：
innodb每秒後臺進程處理IO操作的數據頁上限 innodb_buffer_pool_size總的io處理能力上限 innodb_buffer_pool_instances分割成多個內存塊時，每個內存塊的IO處理能力為：innodb_io_capacity/innodb_buffer_pool_instances --------------------------------------------innodb_max_dirty_pages_pct ：
innodb_flush_method ：
O_DSYNC：使用O_SYNC打開和刷新log文件，使用fsync()刷新數據文件。 O_DIRECT：使用O_DIRECT打開數據文件，使用fsync()刷新日誌文件和數據文件。 在raid設備上，為了避免數據被innodb_buffer和raid多次cache，設置為O_DIRECT方式。---------------------------------------------
innodb_file_per_table ：
不同的表空間可以靈活設置數據目錄的地址 避免共享表空間產生的IO競爭------------------------------------------
innodb_flush_log_at_trx_commit :
0:每秒將log buffer的內容與事務日誌並數據刷盤;-----------------------最快數據最不安全
1:每個事務提交後，將log_buffer的內容寫事務日誌並數據刷盤;-----------最慢最安全
2:每個事務提交後，將log_buffer的內容寫事務日誌，但不進行數據刷盤;---折中
------------------------------------------
sync_binlog :
請註意如果在autocommit模式，每執行一個語句向二進制日誌寫入一次，否則每個事務寫入一次。 默認值是0，不與硬盤同步。值為1是最安全的選擇，因為崩潰時，你最多丟掉二進制日誌中的一個語句/事務；但是，這是最慢的選擇。
雙1模式，即innodb_flush_log_at_trx_commit=1，sync_binlog=1 這樣主備庫的數據是一致的，不會丟失數據。（在此請問你考慮到IO負載了嗎？）
當sync_binlog=N時：
N>0 每向二進制日誌文件寫入N條SQL或N個事務後，則把二進制日誌文件的緩存數據刷新到磁盤上；
N=0 不主動刷新二進制日誌文件的數據到磁盤上，而是由操作系統決定；
推薦配置組合：
N=1,1 適合數據安全性要求非常高，而且磁盤IO寫能力足夠支持業務，比如充值消費系統；
N=1,0 適合數據安全性要求高，磁盤IO寫能力支持業務不富余，允許備庫落後或無復制；
N=2,0或2,m(0<m<100) 適合數據安全性有要求，允許丟失一點事務日誌，復制架構的延遲也能接受；
N=0,0 磁盤IO寫能力有限，無復制或允許復制延遲稍微長點能接受，例如：日誌性登記業務；
----------------------------------------
key_buffer_size ：
key_buffer_size只能緩存MyISAM或類MyISAM引擎的索引數據，而innodb_buffer_pool_size不僅能緩存索引數據，還能緩存元數據，但是對於我們只使用InnoDB引擎的數據庫系統而言，此參數值也不能設置過於偏小，因為臨時表可能會使用到此鍵緩存區空間，索引緩存區推薦：64M
----------------------------------------
query_cache_type and query_cache_size ：
query_cache_type=N：
N=0 —- 禁用查詢緩存的功能；
(有人認為mysql的query cache大部分情況下其實只是雞肋而已，而且建議全面禁用 ; 總之，如果線上環境中99%以上都是只讀，很少有更新，再考慮開啟QC吧，否則，就別開了。詳見 http://www.wtoutiao.com/p/r9aGUI.html)
N=1 —- 啟用產訊緩存的功能，緩存所有符合要求的查詢結果集，除SELECT SQL_NO_CACHE..， 以及不符合查詢緩存設置的結果集外；
N=2 —- 僅僅緩存SELECT SQL_CACHE …子句的查詢結果集，除不符合查詢緩存設置的結果集外；
query_cache_size：
查詢緩存設置多大才是合理？至少需要從四個維度考慮：
① 查詢緩存區對DDL和DML語句的性能影響；
② 查詢緩存區的內部維護成本；
③ 查詢緩存區的命中率及內存使用率等綜合考慮
④ 業務類型
----------------------------------------
max_connections :
MySQL的最大連接數，增加該值增加mysqld 要求的文件描述符的數量。如果服務器的並發連接請求量比較大，建議調高此值，以增加並行連接數量，當然這建立在機器能支撐的情況下，因為如果連接數越多，介於MySQL會為每個連接提供連接緩沖區，就會開銷越多的內存，所以要適當調整該值，不能盲目提高設值。
數值過小會經常出現ERROR 1040: Too many connections錯誤，可以過’conn%’通配符查看當前狀態的連接數量，以定奪該值的大小。
show variables like ‘max_connections‘ ; 查看當前最大連接數設置值
show status like ‘max_used_connections‘ ; 查看最大響應的連接數
如下：
mysql> show variables like ‘max_connections‘;
+———————–+——-+
| Variable_name | Value |
+———————–+——-+
| max_connections | 256 |
+———————–+——-+
mysql> show status like ‘max%connections‘;
+———————–+——-+
| Variable_name | Value |
+—————————-+——-+
| max_used_connections | 256|
+—————————-+——-+
max_used_connections / max_connections * 100% （理想值≈ 85%）
如果max_used_connections跟max_connections相同 那麽就是max_connections設置過低或者超過服務器負載上限了，低於10%則設置過大。
修改方法： vim /etc/my.cnf（永久生效） 或者直接修改會話全局變量（臨時即時生效,重啟mysql後失效，恢復原樣）。所以建議修改指定參數後，同樣修改my.cnf保持一致。
[mysqld]
max_connections=1000
----------------------------------------
mysql參數優化