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

第二加緩存，memcached,redis；

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

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

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

第六才是水平切分，針對(duì)數(shù)據(jù)量大的表，這一步最麻煩，最能考驗(yàn)技術(shù)水平，要選擇一個(gè)合理的sharding key,為了有好的查詢效率，表結(jié)構(gòu)也要改動(dòng)，做一定的冗余，應(yīng)用也要改，sql中盡量帶sharding key，將數(shù)據(jù)定位到限定的表上去查，而不是掃描全部的表；

mysql數(shù)據(jù)庫(kù)一般都是按照這個(gè)步驟去演化的，成本也是由低到高；

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

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

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

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

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

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

總結(jié)

以上是生活随笔為你收集整理的海量url mysql_海量数据mysql优化步骤的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。