mysql千萬級數據庫插入速度和讀取速度的調整記錄

（1）提升數據庫插入性能中心思想：儘可能將數據一次性寫入到Data File和減小數據庫的checkpoint 操做。此次修改了下面四個配置項： 
1）將 innodb_flush_log_at_trx_commit 配置設定爲0；按過往經驗設定爲0，插入速度會有很大提升。

0: Write the log buffer to the log file and flush the log file every second, but do nothing at transaction commit. 
1：the log buffer is written out to the log file at each transaction commit and the flush to disk operation is performed on the log file 
2：the log buffer is written out to the file at each commit, but the flush to disk operation is not performed on it 
2）將 innodb_autoextend_increment 配置因爲默認8M 調整到 128M

此配置項做用主要是當tablespace 空間已經滿了後，須要MySQL系統須要自動擴展多少空間，每次tablespace 擴展都會讓各個SQL 處於等待狀態。增長自動擴展Size能夠減小tablespace自動擴展次數。

3）將 innodb_log_buffer_size 配置因爲默認1M 調整到 16M

此配置項做用設定innodb 數據庫引擎寫日誌緩存區；將此緩存段增大能夠減小數據庫寫數據文件次數。

4）將 innodb_log_file_size 配置因爲默認 8M 調整到 128M

此配置項做用設定innodb 數據庫引擎UNDO日誌的大小；從而減小數據庫checkpoint操做。

通過以上調整，系統插入速度因爲原來10分鐘幾萬條提高至1秒1W左右；注：以上參數調整，須要根據不一樣機器來進行實際調整。特別是 innodb_flush_log_at_trx_commit、innodb_log_buffer_size和 innodb_log_file_size 須要謹慎調整；由於涉及MySQL自己的容災處理。

（2）提高數據庫讀取速度，重數據庫層面上讀取速度提高主要因爲幾點：簡化SQL、加索引和分區； 通過檢查程序SQL已是最簡單，查詢條件上已經增長索引。咱們只能用武器：表分區。

數據庫 MySQL分區前準備：在MySQL中，表空間就是存儲數據和索引的數據文件。 
將S11數據庫因爲同享tablespace 修改成支持多個tablespace;

將wb_user_info_sina 和 wb_user_info_tx 兩個表修改成各自獨立表空間；（Sina：1700W數據，2.6G 大數據文件，Tencent 1400W，2.3G大數據文件）； 
分區操做： 
將現有的主鍵和索引先刪除 
重現創建id,uid 的聯合主鍵 
再以 uid 爲鍵值進行分區。這時候到/var/data/mysql 查看數據文件，能夠看到兩個大表各自獨立表空間已經分割成若干個較少獨立分區空間。（這時候若以uid 爲檢索條件進行查詢，並不提高速度；由於鍵值只是安排數據存儲的分區並不會創建分區索引。我很是鬱悶這點比Oracle 差得不是一點半點。） 
再以 uid 字段上進行創建索引。再次到/var/data/mysql 文件夾查看數據文件，很是鬱悶地發現各個分區Size居然大了。MySQL仍是老樣子將索引與數據存儲在同一個tablespace裏面。若能index 與 數據分離可以更加好管理。

通過以上調整，暫時沒能體現出系統讀取速度提高；基本都是在 2~3秒完成5K數據更新。

MySQL數據庫插入速度調整補充資料：

MySQL 從最開始的時候 1000條/分鐘的插入速度調高至 10000條/秒。 相信你們都已經等急了相關介紹，下面我作調優時候的整個過程。提升數據庫插入性能中心思想： 
一、儘可能使數據庫一次性寫入Data File 
二、減小數據庫的checkpoint 操做 
三、程序上儘可能緩衝數據，進行批量式插入與提交 
四、減小系統的IO衝突

根據以上四點內容，做爲一個業餘DBA對MySQL服務進行了下面調整： 
修改負責收錄記錄MySQL服務器配置，提高MySQL總體寫速度；具體爲下面三個數據庫變量值：innodb_autoextend_increment、innodb_log_buffer_size、innodb_log_file_size；此三個變量默認值分別爲 5M、8M、8M，根據服務器內存大小與具體使用狀況，將此三隻分別修改成：128M、16M、128M。同時，也將原來2個 Log File 變動爲 8 個Log File。這次修改主要知足第一和第二點，如：增長innodb_autoextend_increment就是爲了不因爲頻繁自動擴展Data File而致使 MySQL 的checkpoint 操做； 
將大表轉變爲獨立表空而且進行分區，而後將不一樣分區下掛在多個不一樣硬盤陣列中。

完成了以上修改操做後；我看到下面幸福結果：

獲取測試結果： 
Query OK, 2500000 rows affected (4 min 4.85 sec) 
Records: 2500000 Duplicates: 0 Warnings: 0 
Query OK, 2500000 rows affected (4 min 58.89 sec) 
Records: 2500000 Duplicates: 0 Warnings: 0 
Query OK, 2500000 rows affected (5 min 25.91 sec) 
Records: 2500000 Duplicates: 0 Warnings: 0 
Query OK, 2500000 rows affected (5 min 22.32 sec)

Records: 2500000 Duplicates: 0 Warnings: 0 
最後表的數據量： 
+------------+ 
| count(*) | +------------+ | 10000000| +------------+ 從上面結果來看，數據量增長會對插入性能有必定影響。不過，總體速度仍是很是面議。一天不到時間，就能夠完成4億數據正常處理。預計數據庫瓶頸已經被巧妙解決，結果變成程序「猿」苦逼地向我埋怨，大哥不用這麼狠啊。