很多人第一反應是各種切分；我給的順序是:

第一優(yōu)化你的sql和索引；

第二加緩存，memcached,redis；

第三以上都做了后，還是慢，就做主從復制或主主復制，讀寫分離，可以在應用層做，效率高，也可以用三方工具，第三方工具推薦360的atlas,其它的要么效率不高，要么沒人維護；

第四如果以上都做了還是慢，不要想著去做切分，mysql自帶分區(qū)表，先試試這個，對你的應用是透明的，無需更改代碼,但是sql語句是需要針對分區(qū)表做優(yōu)化的，sql條件中要帶上分區(qū)條件的列，從而使查詢定位到少量的分區(qū)上，否則就會掃描全部分區(qū)，另外分區(qū)表還有一些坑，在這里就不多說了；

第五如果以上都做了，那就先做垂直拆分，其實就是根據你模塊的耦合度，將一個大的系統(tǒng)分為多個小的系統(tǒng)，也就是分布式系統(tǒng)；

第六才是水平切分，針對數據量大的表，這一步最麻煩，最能考驗技術水平，要選擇一個合理的sharding key,為了有好的查詢效率，表結構也要改動，做一定的冗余，應用也要改，sql中盡量帶sharding key，將數據定位到限定的表上去查，而不是掃描全部的表；

mysql數據庫一般都是按照這個步驟去演化的，成本也是由低到高；

有人也許要說第一步優(yōu)化sql和索引這還用說嗎？的確，大家都知道，但是很多情況下，這一步做的并不到位，甚至有的只做了根據sql去建索引，根本沒對sql優(yōu)化(中槍了沒？)，除了最簡單的增刪改查外，想實現(xiàn)一個查詢，可以寫出很多種查詢語句，不同的語句，根據你選擇的引擎、表中數據的分布情況、索引情況、數據庫優(yōu)化策略、查詢中的鎖策略等因素，最終查詢的效率相差很大；優(yōu)化要從整體去考慮，有時你優(yōu)化一條語句后，其它查詢反而效率被降低了，所以要取一個平衡點；即使精通mysql的話，除了純技術面優(yōu)化，還要根據業(yè)務面去優(yōu)化sql語句，這樣才能達到最優(yōu)效果；你敢說你的sql和索引已經是最優(yōu)了嗎?

再說一下不同引擎的優(yōu)化，myisam讀的效果好，寫的效率差，這和它數據存儲格式，索引的指針和鎖的策略有關的，它的數據是順序存儲的(innodb數據存儲方式是聚簇索引)，他的索引btree上的節(jié)點是一個指向數據物理位置的指針，所以查找起來很快，(innodb索引節(jié)點存的則是數據的主鍵，所以需要根據主鍵二次查找)；myisam鎖是表鎖，只有讀讀之間是并發(fā)的，寫寫之間和讀寫之間(讀和插入之間是可以并發(fā)的，去設置concurrent_insert參數，定期執(zhí)行表優(yōu)化操作，更新操作就沒有辦法了)是串行的，所以寫起來慢，并且默認的寫優(yōu)先級比讀優(yōu)先級高，高到寫操作來了后，可以馬上插入到讀操作前面去，如果批量寫，會導致讀請求餓死，所以要設置讀寫優(yōu)先級或設置多少寫操作后執(zhí)行讀操作的策略;myisam不要使用查詢時間太長的sql，如果策略使用不當，也會導致寫?zhàn)I死，所以盡量去拆分查詢效率低的sql,

innodb一般都是行鎖，這個一般指的是sql用到索引的時候，行鎖是加在索引上的，不是加在數據記錄上的，如果sql沒有用到索引，仍然會鎖定表,mysql的讀寫之間是可以并發(fā)的，普通的select是不需要鎖的，當查詢的記錄遇到鎖時，用的是一致性的非鎖定快照讀，也就是根據數據庫隔離級別策略，會去讀被鎖定行的快照，其它更新或加鎖讀語句用的是當前讀，讀取原始行；因為普通讀與寫不沖突，所以innodb不會出現(xiàn)讀寫?zhàn)I死的情況，又因為在使用索引的時候用的是行鎖，鎖的粒度小，競爭相同鎖的情況就少，就增加了并發(fā)處理，所以并發(fā)讀寫的效率還是很優(yōu)秀的，問題在于索引查詢后的根據主鍵的二次查找導致效率低；

ps:很奇怪，為什innodb的索引葉子節(jié)點存的是主鍵而不是像mysism一樣存數據的物理地址指針嗎？如果存的是物理地址指針不就不需要二次查找了嗎，這也是我開始的疑惑，根據mysism和innodb數據存儲方式的差異去想，你就會明白了，我就不費口舌了！

所以innodb為了避免二次查找可以使用索引覆蓋技術，無法使用索引覆蓋的，再延伸一下就是基于索引覆蓋實現(xiàn)延遲關聯(lián)；不知道什么是索引覆蓋的，建議你無論如何都要弄清楚它是怎么回事！

盡你所能去優(yōu)化你的sql吧！說它成本低，卻又是一項費時費力的活，需要在技術與業(yè)務都熟悉的情況下，用心去優(yōu)化才能做到最優(yōu)，優(yōu)化后的效果也是立竿見影的！

ANSWER2

提問：如何設計或優(yōu)化千萬級別的大表？此外無其他信息，個人覺得這個話題有點范，就只好簡單說下該如何做，對于一個存儲設計，必須考慮業(yè)務特點，收集的信息如下：

1.數據的容量：1-3年內會大概多少條數據，每條數據大概多少字節(jié)；

2.數據項：是否有大字段，那些字段的值是否經常被更新；

3.數據查詢SQL條件：哪些數據項的列名稱經常出現(xiàn)在WHERE、GROUP BY、ORDER BY子句中等；

4.數據更新類SQL條件：有多少列經常出現(xiàn)UPDATE或DELETE 的WHERE子句中；

5.SQL量的統(tǒng)計比，如：SELECT：UPDATE+DELETE：INSERT=多少？

6.預計大表及相關聯(lián)的SQL，每天總的執(zhí)行量在何數量級？

7.表中的數據：更新為主的業(yè)務 還是 查詢?yōu)橹鞯臉I(yè)務

8.打算采用什么數據庫物理服務器，以及數據庫服務器架構？

9.并發(fā)如何？

10.存儲引擎選擇InnoDB還是MyISAM？

大致明白以上10個問題，至于如何設計此類的大表，應該什么都清楚了！

至于優(yōu)化若是指創(chuàng)建好的表，不能變動表結構的話，那建議InnoDB引擎，多利用點內存，減輕磁盤IO負載，因為IO往往是數據庫服務器的瓶頸

索引已經創(chuàng)建的非常好，若是讀為主，可以考慮打開query_cache，

以及調整一些參數值：sort_buffer_size,read_buffer_size,read_rnd_buffer_size,join_buffer_size

另外對優(yōu)化索引結構去解決性能問題的話，建議優(yōu)先考慮修改類SQL語句，使他們更快些，不得已只靠索引組織結構的方式，當然此話前提是，

索引已經創(chuàng)建的非常好，若是讀為主，可以考慮打開query_cache，

以及調整一些參數值：sort_buffer_size,read_buffer_size,read_rnd_buffer_size,join_buffer_size

ANSWER3

不紙上談兵，說一下我的思路以及我的解決，拋磚引玉了

我最近正在解決這個問題

我現(xiàn)在的公司有三張表，是5億的數據，每天張表每天的增量是100w

每張表大概在10個columns左右

下面是我做的測試和對比

1.首先看engine,在大數據量情況下，在沒有做分區(qū)的情況下

mysiam比innodb在只讀的情況下，效率要高13％左右

2.在做了partition之后，你可以去讀一下mysql的官方文檔，其實對于partition，專門是對myisam做的優(yōu)化，對于innodb，所有的數據是存在ibdata里面的，所以即使你可以看到schema變了，其實沒有本質的變化

在分區(qū)出于同一個physical disk下面的情況下，提升大概只有1％

在分區(qū)在不同的physical disk下，我分到了三個不同的disks下，提升大概在3％，其實所謂的吞吐量，由很多因素決定的，比如你的explain parition時候可以看到，record在那一個分區(qū)，如果每個分區(qū)都有，其實本質上沒有解決讀的問題，這樣只會提升寫的效率。

另外一個問題在于，分區(qū)，你怎么分，如果一張表，有三個column都是經常被用于做查詢條件的，其實是一件很悲慘的事情，因為你沒有辦法對所有的sql做針對性的分區(qū)，如果你只是如mysql官方文檔上說的，只對時間做一個分區(qū)，而且你也只用時間查詢的話，恭喜你

3.表主要用來讀還是寫，其實這個問題是不充分的，應該這樣問，你在寫入的時候，同時并發(fā)的查詢多么？我的問題還比較簡單，因為mongodb的shredding支持不能，在crush之后，還是回到mysql，所以在通常情況下，9am－9pm，寫入的情況很多，這個時候我會做一個view，view是基于最近被插入或者經常被查詢的，通過做view來分離讀取，就是說寫是在table上的，讀在進行邏輯判斷前是在view上操作的

4做一些archive table，比如先對這些大表做很多已有的統(tǒng)計分析，然后通過已有的分析＋增量來解決 5如果你用mysiam，還有一個問題你要注意，如果你的.configure的時候，加了一個max index length參數的時候，當你的record數大于制定長度的時候，這個index會被disable

總結

以上是生活随笔為你收集整理的mysql 压力测试知乎_MySQL 对于千万级的大表要怎么优化? - MySQL的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。