一般情況下mysql上百萬數(shù)據(jù)讀取和插入更新是沒什么問題了浩销，但到了上千萬級就會出現(xiàn)很慢频轿，下面我們來看mysql千萬級數(shù)據(jù)庫插入速度和讀取速度的調(diào)整記錄吧沸停。
1）提高數(shù)據(jù)庫插入性能中心思想：盡量將數(shù)據(jù)一次性寫入到Data File和減少數(shù)據(jù)庫的checkpoint 操作肯骇。這次修改了下面四個配置項(xiàng)：
1）將 innodb_flush_log_at_trx_commit 配置設(shè)定為0奋渔；按過往經(jīng)驗(yàn)設(shè)定為0，插入速度會有很大提高物臂。
0: 日志緩沖每秒一次地被寫到日志文件旺拉，并且對日志文件做到磁盤操作的刷新，但是在一個事務(wù)提交不做任何操作棵磷。
1：在每個事務(wù)提交時蛾狗，日志緩沖被寫到日志文件，對日志文件做到磁盤操作的刷新泽本。
2：在每個提交淘太，日志緩沖被寫到文件，但不對日志文件做到磁盤操作的刷新规丽。對日志文件每秒刷新一次蒲牧。
默認(rèn)值是 1，也是最安全的設(shè)置赌莺，即每個事務(wù)提交的時候都會從 log buffer 寫
到日志文件冰抢，而且會實(shí)際刷新磁盤，但是這樣性能有一定的損失艘狭。如果可以容忍在數(shù)
據(jù)庫崩潰的時候損失一部分?jǐn)?shù)據(jù)挎扰，那么設(shè)置成 0 或者 2 都會有所改善。設(shè)置成 0巢音，則
在數(shù)據(jù)庫崩潰的時候會丟失那些沒有被寫入日志文件的事務(wù)遵倦，最多丟失 1 秒鐘的事
務(wù)，這種方式是最不安全的官撼，也是效率最高的梧躺。設(shè)置成 2 的時候，因?yàn)橹皇菦]有刷新
到磁盤傲绣，但是已經(jīng)寫入日志文件掠哥，所以只要操作系統(tǒng)沒有崩潰巩踏，那么并沒有丟失數(shù)據(jù) ，
比設(shè)置成 0 更安全一些续搀。
在 mysql 的手冊中塞琼，為了確保事務(wù)的持久性和復(fù)制設(shè)置的耐受性、一致性禁舷，都是
建議將這個參數(shù)設(shè)置為 1 的彪杉。
2）將 innodb_autoextend_increment 配置由于默認(rèn)8M 調(diào)整到 128M
此配置項(xiàng)作用主要是當(dāng)tablespace 空間已經(jīng)滿了后，需要MySQL系統(tǒng)需要自動擴(kuò)展多少空間牵咙，每次tablespace 擴(kuò)展都會讓各個SQL 處于等待狀態(tài)在讶。增加自動擴(kuò)展Size可以減少tablespace自動擴(kuò)展次數(shù)。
3）將 innodb_log_buffer_size 配置由于默認(rèn)1M 調(diào)整到 16M
此配置項(xiàng)作用設(shè)定innodb 數(shù)據(jù)庫引擎寫日志緩存區(qū)霜大；將此緩存段增大可以減少數(shù)據(jù)庫寫數(shù)據(jù)文件次數(shù)。
4）將 innodb_log_file_size 配置由于默認(rèn) 8M 調(diào)整到 128M
此配置項(xiàng)作用設(shè)定innodb 數(shù)據(jù)庫引擎UNDO日志的大懈锎稹战坤；從而減少數(shù)據(jù)庫checkpoint操作。
經(jīng)過以上調(diào)整残拐，系統(tǒng)插入速度由于原來10分鐘幾萬條提升至1秒1W左右途茫；注：以上參數(shù)調(diào)整，需要根據(jù)不同機(jī)器來進(jìn)行實(shí)際調(diào)整溪食。特別是 innodb_flush_log_at_trx_commit囊卜、innodb_log_buffer_size和 innodb_log_file_size 需要謹(jǐn)慎調(diào)整；因?yàn)樯婕癕ySQL本身的容災(zāi)處理错沃。
（2）提升數(shù)據(jù)庫讀取速度栅组，重數(shù)據(jù)庫層面上讀取速度提升主要由于幾點(diǎn)：簡化SQL、加索引和分區(qū)枢析； 經(jīng)過檢查程序SQL已經(jīng)是最簡單玉掸，查詢條件上已經(jīng)增加索引。我們只能用武器：表分區(qū)醒叁。
數(shù)據(jù)庫 MySQL分區(qū)前準(zhǔn)備：在MySQL中司浪，表空間就是存儲數(shù)據(jù)和索引的數(shù)據(jù)文件。
將S11數(shù)據(jù)庫由于同享tablespace 修改為支持多個tablespace;
將wb_user_info_sina 和 wb_user_info_tx 兩個表修改為各自獨(dú)立表空間把沼；（Sina：1700W數(shù)據(jù)啊易，2.6G 大數(shù)據(jù)文件，Tencent 1400W饮睬，2.3G大數(shù)據(jù)文件）租谈；
分區(qū)操作：
將現(xiàn)有的主鍵和索引先刪除
重現(xiàn)建立id,uid 的聯(lián)合主鍵
再以 uid 為鍵值進(jìn)行分區(qū)。這時候到/var/data/mysql 查看數(shù)據(jù)文件续捂，可以看到兩個大表各自獨(dú)立表空間已經(jīng)分割成若干個較少獨(dú)立分區(qū)空間垦垂。（這時候若以uid 為檢索條件進(jìn)行查詢宦搬，并不提升速度；因?yàn)殒I值只是安排數(shù)據(jù)存儲的分區(qū)并不會建立分區(qū)索引劫拗。我非常郁悶這點(diǎn)比Oracle 差得不是一點(diǎn)半點(diǎn)间校。）
再以 uid 字段上進(jìn)行建立索引。再次到/var/data/mysql 文件夾查看數(shù)據(jù)文件页慷，非常郁悶地發(fā)現(xiàn)各個分區(qū)Size竟然大了憔足。MySQL還是老樣子將索引與數(shù)據(jù)存儲在同一個tablespace里面。若能index 與 數(shù)據(jù)分離能夠更加好管理酒繁。
經(jīng)過以上調(diào)整滓彰，暫時沒能體現(xiàn)出系統(tǒng)讀取速度提升；基本都是在 2~3秒完成5K數(shù)據(jù)更新州袒。
MySQL數(shù)據(jù)庫插入速度調(diào)整補(bǔ)充資料：
MySQL 從最開始的時候 1000條/分鐘的插入速度調(diào)高至 10000條/秒揭绑。 相信大家都已經(jīng)等急了相關(guān)介紹，下面我做調(diào)優(yōu)時候的整個過程郎哭。提高數(shù)據(jù)庫插入性能中心思想：
1他匪、盡量使數(shù)據(jù)庫一次性寫入Data File
2、減少數(shù)據(jù)庫的checkpoint 操作
3夸研、程序上盡量緩沖數(shù)據(jù)邦蜜，進(jìn)行批量式插入與提交
4、減少系統(tǒng)的IO沖突
根據(jù)以上四點(diǎn)內(nèi)容亥至，作為一個業(yè)余DBA對MySQL服務(wù)進(jìn)行了下面調(diào)整：
修改負(fù)責(zé)收錄記錄MySQL服務(wù)器配置悼沈，提升MySQL整體寫速度；具體為下面三個數(shù)據(jù)庫變量值：innodb_autoextend_increment姐扮、innodb_log_buffer_size絮供、innodb_log_file_size；此三個變量默認(rèn)值分別為 5M溶握、8M杯缺、8M，根據(jù)服務(wù)器內(nèi)存大小與具體使用情況睡榆，將此三只分別修改為：128M萍肆、16M、128M胀屿。同時塘揣，也將原來2個 Log File 變更為 8 個Log File。此次修改主要滿足第一和第二點(diǎn)宿崭，如：增加innodb_autoextend_increment就是為了避免由于頻繁自動擴(kuò)展Data File而導(dǎo)致 MySQL 的checkpoint 操作亲铡；
將大表轉(zhuǎn)變?yōu)楠?dú)立表空并且進(jìn)行分區(qū)，然后將不同分區(qū)下掛在多個不同硬盤陣列中。
完成了以上修改操作后奖蔓；我看到下面幸福結(jié)果：
獲取測試結(jié)果：
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
最后表的數(shù)據(jù)量：
+————+
| count(*) |
+————+
| 10000000|
+————+
從上面結(jié)果來看赞草，數(shù)據(jù)量增加會對插入性能有一定影響。不過吆鹤，整體速度還是非常面議厨疙。一天不到時間，就可以完成4億數(shù)據(jù)正常處理疑务。
