資源描述：
《MySQL 數(shù)據(jù)庫性能優(yōu)化之索引優(yōu)化.doc》由會(huì)員上傳分享，免費(fèi)在線閱讀，更多相關(guān)內(nèi)容在應(yīng)用文檔-天天文庫。
1、這篇文章是以MySQL為背景，很多內(nèi)容同時(shí)適用于其他關(guān)系型數(shù)據(jù)庫，需要有一些索引知識(shí)為基礎(chǔ) 優(yōu)化目標(biāo) 減少IO次數(shù) IO永遠(yuǎn)是數(shù)據(jù)庫最容易瓶頸的地方，這是由數(shù)據(jù)庫的職責(zé)所決定的，大部分?jǐn)?shù)據(jù)庫操作中超過90%的時(shí)間都是IO操作所占用的，減少IO次數(shù)是SQL優(yōu)化中需要第一優(yōu)先考慮，當(dāng)然，也是收效最明顯的優(yōu)化手段?！ 〗档虲PU計(jì)算 除了IO瓶頸之外，SQL優(yōu)化中需要考慮的就是CPU運(yùn)算量的優(yōu)化了。orderby,groupby,distinct…都是消耗CPU的大戶(這些操作基本上都是CPU處理內(nèi)存中的數(shù)據(jù)比較運(yùn)算)。當(dāng)我們的IO優(yōu)化
2、做到一定階段之后，降低CPU計(jì)算也就成為了我們SQL優(yōu)化的重要目標(biāo) 優(yōu)化方法 改變SQL執(zhí)行計(jì)劃 明確了優(yōu)化目標(biāo)之后，我們需要確定達(dá)到我們目標(biāo)的方法。對(duì)于SQL語句來說，達(dá)到上述2個(gè)目標(biāo)的方法其實(shí)只有一個(gè)，那就是改變SQL的執(zhí)行計(jì)劃，讓他盡量“少走彎路”，盡量通過各種“捷徑”來找到我們需要的數(shù)據(jù)，以達(dá)到“減少IO次數(shù)”和“降低CPU計(jì)算”的目標(biāo) 常見誤區(qū) count(1)和count(primary_key)優(yōu)于count(*) 很多人為了統(tǒng)計(jì)記錄條數(shù)，就使用count(1)和count(primary_key)而不是coun
3、t(*)，他們認(rèn)為這樣性能更好，其實(shí)這是一個(gè)誤區(qū)。對(duì)于有些場景，這樣做可能性能會(huì)更差，應(yīng)為數(shù)據(jù)庫對(duì)count(*)計(jì)數(shù)操作做了一些特別的優(yōu)化。 count(column)和count(*)是一樣的 這個(gè)誤區(qū)甚至在很多的資深工程師或者是DBA中都普遍存在，很多人都會(huì)認(rèn)為這是理所當(dāng)然的。實(shí)際上，count(column)和count(*)是一個(gè)完全不一樣的操作，所代表的意義也完全不一樣?！ ount(column)是表示結(jié)果集中有多少個(gè)column字段不為空的記錄 count(*)是表示整個(gè)結(jié)果集有多少條記錄 selecta,bfr
4、om…比selecta,b,cfrom…可以讓數(shù)據(jù)庫訪問更少的數(shù)據(jù)量 這個(gè)誤區(qū)主要存在于大量的開發(fā)人員中，主要原因是對(duì)數(shù)據(jù)庫的存儲(chǔ)原理不是太了解?！ ?shí)際上，大多數(shù)關(guān)系型數(shù)據(jù)庫都是按照行(row)的方式存儲(chǔ)，而數(shù)據(jù)存取操作都是以一個(gè)固定大小的IO單元(被稱作block或者page)為單位，一般為4KB，8KB…大多數(shù)時(shí)候，每個(gè)IO單元中存儲(chǔ)了多行，每行都是存儲(chǔ)了該行的所有字段(lob等特殊類型字段除外)?！ ∷?，我們是取一個(gè)字段還是多個(gè)字段，實(shí)際上數(shù)據(jù)庫在表中需要訪問的數(shù)據(jù)量其實(shí)是一樣的。 當(dāng)然，也有例外情況，那就是我們的這個(gè)查詢?cè)?/p>
5、索引中就可以完成，也就是說當(dāng)只取a,b兩個(gè)字段的時(shí)候，不需要回表，而c這個(gè)字段不在使用的索引中，需要回表取得其數(shù)據(jù)。在這樣的情況下，二者的IO量會(huì)有較大差異。 orderby一定需要排序操作 我們知道索引數(shù)據(jù)實(shí)際上是有序的，如果我們的需要的數(shù)據(jù)和某個(gè)索引的順序一致，而且我們的查詢又通過這個(gè)索引來執(zhí)行，那么數(shù)據(jù)庫一般會(huì)省略排序操作，而直接將數(shù)據(jù)返回，因?yàn)閿?shù)據(jù)庫知道數(shù)據(jù)已經(jīng)滿足我們的排序需求了。 實(shí)際上，利用索引來優(yōu)化有排序需求的SQL，是一個(gè)非常重要的優(yōu)化手段 延伸閱讀：MySQLORDERBY的實(shí)現(xiàn)分析，MySQL中GROUPBY
6、基本實(shí)現(xiàn)原理以及MySQLDISTINCT的基本實(shí)現(xiàn)原理這3篇文章中有更為深入的分析，尤其是第一篇 執(zhí)行計(jì)劃中有filesort就會(huì)進(jìn)行磁盤文件排序 有這個(gè)誤區(qū)其實(shí)并不能怪我們，而是因?yàn)镸ySQL開發(fā)者在用詞方面的問題。filesort是我們?cè)谑褂胑xplain命令查看一條SQL的執(zhí)行計(jì)劃的時(shí)候可能會(huì)看到在“Extra”一列顯示的信息?！ ?shí)際上，只要一條SQL語句需要進(jìn)行排序操作，都會(huì)顯示“Usingfilesort”，這并不表示就會(huì)有文件排序操作。 延伸閱讀：理解MySQLExplain命令輸出中的filesort，我在這里有更
7、為詳細(xì)的介紹 基本原則 盡量少join MySQL的優(yōu)勢(shì)在于簡單，但這在某些方面其實(shí)也是其劣勢(shì)。MySQL優(yōu)化器效率高，但是由于其統(tǒng)計(jì)信息的量有限，優(yōu)化器工作過程出現(xiàn)偏差的可能性也就更多。對(duì)于復(fù)雜的多表Join，一方面由于其優(yōu)化器受限，再者在Join這方面所下的功夫還不夠，所以性能表現(xiàn)離Oracle等關(guān)系型數(shù)據(jù)庫前輩還是有一定距離。但如果是簡單的單表查詢，這一差距就會(huì)極小甚至在有些場景下要優(yōu)于這些數(shù)據(jù)庫前輩。 盡量少排序 排序操作會(huì)消耗較多的CPU資源，所以減少排序可以在緩存命中率高等IO能力足夠的場景下會(huì)較大影響SQL的響應(yīng)時(shí)
8、間?！ ?duì)于MySQL來說，減少排序有多種辦法，比如： 上面誤區(qū)中提到的通過利用索引來排序的方式進(jìn)行優(yōu)化 減少參與排序的記錄條數(shù) 非必要不對(duì)數(shù)據(jù)進(jìn)行排序 … 盡量避免select*
