公司數據中心計劃將海量數據做一次遷移，同時增加某時間字段（原來是datatime類型，現在增加一個date類型），單表數據量達到6億多條記錄，數據是基于時間（月）做的partition由于比較忙，一直沒有總結，所以很細節(jié)的地方都記不清楚了，此處只是簡單總結下當時的情形，備忘

亂打亂撞

    最初接到任務，沒有明確的入手點，直接就是select * from db limit 10000,動態(tài)修改翻頁數量，通過控制臺看耗時情況，慢

是否可以基于partition讀數據呢

    既然數據庫是按partition做分區(qū)，是否可以按partition讀數據呢，如果可以改用怎樣的語法讀呢？時間上只要按月讀數據，mysql會自動的基于partition讀，具體可以用命令：explain partition即可看到具有基于哪個partition
    讀大數據會十分耗時，對于數據進行到什么狀態(tài)，我們可能十分想了解，可以用命令：show status查看，我印象中主要是sending data，writting to net之類的。
    innodb引擎的性能較myIsam引擎到底如何？
    導庫實驗中導出并導入一個月的數據（8G的文本量，2500w條記錄），在myisam引擎下需要不到4h（測試環(huán)境為pc機），但是在innodb引擎下，卻需要32小時，改善索引之類的，也需要28h，性能有8倍之差。

    在網上找到了高人關于innodb與myisam區(qū)別，說需要修改innodb_buffer_pool_size、innodb_flush_log_at_trx_commit

可保證沒有太大差別，嘗試了沒有明顯改善，在本機倒是可以，為什么呢？？？這個折騰了我好長時間

innodb_flush_log_at_trx_commit

    是否為Innodb比MyISAM慢1000倍而頭大？看來也許你忘了修改這個參數了。默認值是 1，這意味著每次提交的更新事務（或者每個事務之外的語句）都會刷新到磁盤中，而這相當耗費資源，尤其是沒有電池備用緩存時。很多應用程序，尤其是從 MyISAM轉變過來的那些，把它的值設置為 2 就可以了，也就是不把日志刷新到磁盤上，而只刷新到操作系統的緩存上。日志仍然會每秒刷新到磁盤中去，因此通常不會丟失每秒1-2次更新的消耗。如果設置 為 0 就快很多了，不過也相對不安全了 — MySQL服務器崩潰時就會丟失一些事務。設置為 2 只會丟失刷新到操作系統緩存的那部分事務。

innodb_buffer_pool_size

    Innodb在默認的 innodb_buffer_pool_size 設置下跟蝸牛似的。由于Innodb把數據和索引都緩存起來，無需留給操作系統太多的內存，因此如果只需要用Innodb的話則可以設置它高達 70-80% 的可用內存。

    最后千辛萬苦的、跋山涉水的，找到了另外兩個參數

innodb_log_file_size

    在高寫入負載尤其是大數據集的情況下很重要。這個值越大則性能相對越高，但是要注意到可能會增加恢復時間。我經常設置為 64-512MB，跟據服務器大小而異。

innodb_log_buffer_size
    默認的設置在中等強度寫入負載以及較短事務的情況下，服務器性能還可以。如果存在更新操作峰值或者負載較大，就應該考慮加大它的值了。如果它的值設置太高了，可能會浪費內存 — 它每秒都會刷新一次，因此無需設置超過1秒所需的內存空間。通常 8-16MB 就足夠了。越小的系統它的值越小。

最終搞定，myisam與innodb的導數據的性能基本一致，2500的數據約需要3.5h，單庫讀數據需要2h，這個只是一個示意值僅供參考（pc上的測試），正式服務的上的測試結果更加明顯

性能調優(yōu)語句參考
 

并行讀取是否會更快？

如果基于partition導數據，還是不能達到既定目標，我最終是通過編寫shell腳步，多進程并行基于partition導數據，即啟動多個mysql -uroot -p db < exp201201.sql 、mysql -uroot -p db < exp201202.sql，每個sql下按天做讀寫（事件環(huán)境下是按月做partition的）