1、日誌產生的效能影響:
由於日誌的記錄帶來的直接效能損耗就是資料庫系統中最為昂貴的io資源。mysql的日誌包括錯誤日誌(errorlog)，更新日誌(updatelog)，二進位制日誌(binlog)，查詢日誌(querylog)，慢查詢日誌(slowquerylog)等。當然，更新日誌是老版本的mysql才有的，目前已經被二進位制日誌替代。
在預設情況下，系統僅僅開啟錯誤日誌，關閉了其他所有日誌，以達到盡可能減少io損耗提高系統效能的目的。但是在一般稍微重要一點的實際應用場景中，都至少需要開啟二進位制日誌，因為這是mysql很多儲存引擎進行增量備份的基礎，也是mysql實現複製的基本條件。有時候為了進一步的效能優化，定位執行較慢的sql語句，很多系統也會開啟慢查詢日誌來記錄執行時間超過特定數值(由我們自行設定)的sql語句。
一般情況下，在生產系統中很少有系統會開啟查詢日誌。因為查詢日誌開啟之後會將mysql中執行的每一條query都記錄到日誌中，會該系統帶來比較大的io負擔，而帶來的實際效益卻並不是非常大。一般只有在開發測試環境中，為了定位某些功能具體使用了哪些sql語句的時候，才會在短時間段內開啟該日誌來做相應的分析。所以，在mysql系統中，會對效能產生影響的mysql日誌(不包括各儲存引擎自己的日誌)主要就是binlog了。
2、mysql內執行如下指令：
set global sync_binlog=500;
當每進行500次事務提交之後，mysql將進行一次fsync之類的磁碟同步指令來將binlog_cache中的資料強制寫入磁碟。
set global innodb_flush_log_at_trx_commit=2;
預設值1代表每一次事務提交或事務外的指令都需要把日誌寫入(flush)硬碟，這是很費時的。特別是使用電池供電快取(battery backed up cache)時。設定為2代表不寫入硬碟而是寫入系統快取。日誌仍然會每秒flush到硬碟，所以你一般不會丟失超過1-2秒的更新。設成0會更快一點，但安全方面比較差，即使mysql掛了也可能會丟失事務的資料。而值設定為2只會在整個作業系統宕機時才可能丟資料。
注：重新開機後，該指令失效。可在服務啟動時，設定如上兩項。
Postgres間隔大量寫IO的解決辦法
為了保證資料可靠性，同時還要保證好的讀寫效能，以及讀寫的一致性，經過多年的積累，redo日誌，shared buffer等基本成為關係型資料庫的標配。postgres也不例外。為了保證資料的可靠性，通常在將髒頁面寫入硬碟前，先將wal日誌先寫入硬碟，然後將修改的資料非同步分批寫入。為了保證好的讀寫效...
寫io的幾種模式
寫io的幾種模式 buffer write 特點 a 應用程式寫入到page cache b 作業系統 writeback 優缺點 a 大部分情況直接寫記憶體，速度很快 b 資料完整性無法得到嚴格保證 c 小部分寫入受到系統回寫影響，服務質量沒有辦法保證 direct write 特點 a 繞過作業...
mysql高併發解決方案
mysql高併發的解決方法有 優化sql語句，優化資料庫字段，加快取，分割槽表，讀寫分離以及垂直拆分，解耦模組，水平切分等。高併發大多的瓶頸在後台，在儲存mysql的正常的優化方案如下 1 中sql語句優化 2 資料庫字段優化，索引優化 3 加快取，redis memcache等 4 主從，讀寫分離...