很多人第一反應是各種切分；我給的順序是:
第一優化你的sql和索引；
第二加快取，memcached,redis；
第三以上都做了後，還是慢，就做主從複製或主主複製，讀寫分離，可以在應用層做，效率高，也可以用三方工具，第三方工具推薦360的atlas,其它的要麼效率不高，要麼沒人維護；
第四如果以上都做了還是慢，不要想著去做切分，mysql自帶分割槽表，先試試這個，對你的應用是透明的，無需更改**,但是sql語句是需要針對分割槽表做優化的，sql條件中要帶上分割槽條件的列，從而使查詢定位到少量的分割槽上，否則就會掃瞄全部分割槽，另外分割槽表還有一些坑，在這裡就不多說了；
第五如果以上都做了，那就先做垂直拆分，其實就是根據你模組的耦合度，將乙個大的系統分為多個小的系統，也就是分布式系統；
第六才是水平切分，針對資料量大的表，這一步最麻煩，最能考驗技術水平，要選擇乙個合理的sharding key,為了有好的查詢效率，表結構也要改動，做一定的冗餘，應用也要改，sql中盡量帶sharding key，將資料定位到限定的表上去查，而不是掃瞄全部的表；
mysql資料庫一般都是按照這個步驟去演化的，成本也是由低到高；
有人也許要說第一步優化sql和索引這還用說嗎？的確，大家都知道，但是很多情況下，這一步做的並不到位，甚至有的只做了根據sql去建索引，根本沒對sql優化（中槍了沒？），除了最簡單的增刪改查外，想實現乙個查詢，可以寫出很多種查詢語句，不同的語句，根據你選擇的引擎、表中資料的分布情況、索引情況、資料庫優化策略、查詢中的鎖策略等因素，最終查詢的效率相差很大；優化要從整體去考慮，有時你優化一條語句後，其它查詢反而效率被降低了，所以要取乙個平衡點；即使精通mysql的話，除了純技術面優化，還要根據業務面去優化sql語句，這樣才能達到最優效果；你敢說你的sql和索引已經是最優了嗎?
再說一下不同引擎的優化，myisam讀的效果好，寫的效率差，這和它資料儲存格式，索引的指標和鎖的策略有關的，它的資料是順序儲存的（innodb資料儲存方式是聚簇索引），他的索引btree上的節點是乙個指向資料物理位置的指標，所以查詢起來很快，（innodb索引節點存的則是資料的主鍵，所以需要根據主鍵二次查詢）；myisam鎖是表鎖，只有讀讀之間是併發的，寫寫之間和讀寫之間（讀和插入之間是可以併發的，去設定concurrent_insert引數，定期執行表優化操作，更新操作就沒有辦法了）是序列的，所以寫起來慢，並且預設的寫優先順序比讀優先順序高，高到寫操作來了後，可以馬上插入到讀操作前面去，如果批量寫，會導致讀請求餓死，所以要設定讀寫優先順序或設定多少寫操作後執行讀操作的策略;myisam不要使用查詢時間太長的sql，如果策略使用不當，也會導致寫餓死，所以盡量去拆分查詢效率低的sql,
innodb一般都是行鎖，這個一般指的是sql用到索引的時候，行鎖是加在索引上的，不是加在資料記錄上的，如果sql沒有用到索引，仍然會鎖定表,mysql的讀寫之間是可以併發的，普通的select是不需要鎖的，當查詢的記錄遇到鎖時，用的是一致性的非鎖定快照讀，也就是根據資料庫隔離級別策略，會去讀被鎖定行的快照，其它更新或加鎖讀語句用的是當前讀，讀取原始行；因為普通讀與寫不衝突，所以innodb不會出現讀寫餓死的情況，又因為在使用索引的時候用的是行鎖，鎖的粒度小，競爭相同鎖的情況就少，就增加了併發處理，所以併發讀寫的效率還是很優秀的，問題在於索引查詢後的根據主鍵的二次查詢導致效率低；
ps:很奇怪，為什innodb的索引葉子節點存的是主鍵而不是像mysism一樣存資料的實體地址指標嗎？如果存的是實體地址指標不就不需要二次查詢了嗎，這也是我開始的疑惑，根據mysism和innodb資料儲存方式的差異去想，你就會明白了，我就不費口舌了！
所以innodb為了避免二次查詢可以使用索引覆蓋技術，無法使用索引覆蓋的，再延伸一下就是基於索引覆蓋實現延遲關聯；不知道什麼是索引覆蓋的，建議你無論如何都要弄清楚它是怎麼回事！
盡你所能去優化你的sql吧！說它成本低，卻又是一項費時費力的活，需要在技術與業務都熟悉的情況下，用心去優化才能做到最優，優化後的效果也是立竿見影的！
記憶體資料庫的產品演化
記憶體資料庫產品是把資料放在記憶體中，實現高效讀寫，目前是傳統的關係型資料庫的有效補充。在此我以產品演化的視角簡單總結一下我所理解的記憶體資料庫發展歷史，目的是理解記憶體資料庫產品的發展趨勢，不恰當的地方請讀者指正。一 關聯式資料庫快取 記憶體資料庫的雛形 適用於對吞吐量和響應時間要求不高的企業級應...
資料庫優化 資料庫設計優化
一 索引優化 1.首先索引不是越多越好，要視情況而定。因為索引會降低insert和update的效率 insert和update有時可能會重建索引。2.乙個表的索參數量最好不要超過6個，擇優而建。3.專案上線後，根據使用者的查詢條件字段稍微調整資料庫中的字段索引。二 分表 1.縱切 根據表字段來且分...
資料庫引擎優化顧問優化資料庫
現在一直在做的專案，資料量相對也不小，開始的時候沒有覺得，因為是剛開始，資料量還很小，在程式使用過程中速度還挺快，但是隨著資料量的不停的增長，發現程式越來越慢，甚至出現了超時的問題，因此要對程式和資料庫進行優化，前期專案比較緊，沒有針對大資料量業務進行分析設計，所以索引等相關優化沒有做到位，通過後期...