一们童、MySQL的主要適用場(chǎng)景

1畔况、Web網(wǎng)站系統(tǒng)

2、日志記錄系統(tǒng)

3慧库、數(shù)據(jù)倉(cāng)庫(kù)系統(tǒng)

4跷跪、嵌入式系統(tǒng)

二、MySQL架構(gòu)圖：

三齐板、MySQL存儲(chǔ)引擎概述

1）MyISAM存儲(chǔ)引擎

MyISAM存儲(chǔ)引擎的表在數(shù)據(jù)庫(kù)中吵瞻，每一個(gè)表都被存放為三個(gè)以表名命名的物理文件。首先肯定會(huì)有任何存儲(chǔ)引擎都不可缺少的存放表結(jié)構(gòu)定義信息的.frm文件甘磨，另外還有.MYD和.MYI文件橡羞，分別存放了表的數(shù)據(jù)（.MYD）和索引數(shù)據(jù)（.MYI）。每個(gè)表都有且僅有這樣三個(gè)文件做為MyISAM存儲(chǔ)類(lèi)型的表的存儲(chǔ)济舆，也就是說(shuō)不管這個(gè)表有多少個(gè)索引，都是存放在同一個(gè).MYI文件中。

MyISAM支持以下三種類(lèi)型的索引：

1结笨、B-Tree索引

B-Tree索引，顧名思義齐邦，就是所有的索引節(jié)點(diǎn)都按照balancetree的數(shù)據(jù)結(jié)構(gòu)來(lái)存儲(chǔ)，所有的索引數(shù)據(jù)節(jié)點(diǎn)都在葉節(jié)點(diǎn)第租。

2侄旬、R-Tree索引

R-Tree索引的存儲(chǔ)方式和b-tree索引有一些區(qū)別，主要設(shè)計(jì)用于為存儲(chǔ)空間和多維數(shù)據(jù)的字段做索引煌妈，所以目前的MySQL版本來(lái)說(shuō)儡羔，也僅支持geometry類(lèi)型的字段作索引。

3璧诵、Full-text索引

Full-text索引就是我們長(zhǎng)說(shuō)的全文索引汰蜘，他的存儲(chǔ)結(jié)構(gòu)也是b-tree。主要是為了解決在我們需要用like查詢(xún)的低效問(wèn)題之宿。

2）Innodb 存儲(chǔ)引擎

1族操、支持事務(wù)安裝

2、數(shù)據(jù)多版本讀取

3比被、鎖定機(jī)制的改進(jìn)

4色难、實(shí)現(xiàn)外鍵

3）NDBCluster存儲(chǔ)引擎

NDB存儲(chǔ)引擎也叫NDBCluster存儲(chǔ)引擎，主要用于MySQLCluster分布式集群環(huán)境等缀，Cluster是MySQL從5.0版本才開(kāi)始提供的新功能枷莉。

4）Merge存儲(chǔ)引擎

MERGE存儲(chǔ)引擎，在MySQL用戶(hù)手冊(cè)中也提到了尺迂，也被大家認(rèn)識(shí)為MRG_MyISAM引擎笤妙。Why？因?yàn)镸ERGE存儲(chǔ)引擎可以簡(jiǎn)單的理解為其功能就是實(shí)現(xiàn)了對(duì)結(jié)構(gòu)相同的MyISAM表噪裕，通過(guò)一些特殊的包裝對(duì)外提供一個(gè)單一的訪問(wèn)入口蹲盘，以達(dá)到減小應(yīng)用的復(fù)雜度的目的。要?jiǎng)?chuàng)建MERGE表膳音，不僅僅基表的結(jié)構(gòu)要完全一致召衔，包括字段的順序，基表的索引也必須完全一致祭陷。

5）Memory存儲(chǔ)引擎

Memory存儲(chǔ)引擎苍凛，通過(guò)名字就很容易讓人知道，他是一個(gè)將數(shù)據(jù)存儲(chǔ)在內(nèi)存中的存儲(chǔ)引擎颗胡。Memory存儲(chǔ)引擎不會(huì)將任何數(shù)據(jù)存放到磁盤(pán)上毫深，僅僅存放了一個(gè)表結(jié)構(gòu)相關(guān)信息的.frm文件在磁盤(pán)上面。所以一旦MySQLCrash或者主機(jī)Crash之后毒姨，Memory的表就只剩下一個(gè)結(jié)構(gòu)了哑蔫。Memory表支持索引，并且同時(shí)支持Hash和B－Tree兩種格式的索引。由于是存放在內(nèi)存中闸迷，所以Memory都是按照定長(zhǎng)的空間來(lái)存儲(chǔ)數(shù)據(jù)的嵌纲，而且不支持BLOB和TEXT類(lèi)型的字段。Memory存儲(chǔ)引擎實(shí)現(xiàn)頁(yè)級(jí)鎖定腥沽。

6）BDB存儲(chǔ)引擎

BDB存儲(chǔ)引擎全稱(chēng)為BerkeleyDB存儲(chǔ)引擎逮走，和Innodb一樣，也不是MySQL自己開(kāi)發(fā)實(shí)現(xiàn)的一個(gè)存儲(chǔ)引擎今阳，而是由SleepycatSoftware所提供师溅，當(dāng)然，也是開(kāi)源存儲(chǔ)引擎盾舌，同樣支持事務(wù)安全墓臭。

7）FEDERATED存儲(chǔ)引擎

FEDERATED存儲(chǔ)引擎所實(shí)現(xiàn)的功能，和Oracle的DBLINK基本相似妖谴，主要用來(lái)提供對(duì)遠(yuǎn)程MySQL服務(wù)器上面的數(shù)據(jù)的訪問(wèn)接口窿锉。如果我們使用源碼編譯來(lái)安裝MySQL，那么必須手工指定啟用FEDERATED存儲(chǔ)引擎才行膝舅，因?yàn)镸ySQL默認(rèn)是不起用該存儲(chǔ)引擎的嗡载。

8）ARCHIVE存儲(chǔ)引擎

ARCHIVE存儲(chǔ)引擎主要用于通過(guò)較小的存儲(chǔ)空間來(lái)存放過(guò)期的很少訪問(wèn)的歷史數(shù)據(jù)。ARCHIVE表不支持索引仍稀，通過(guò)一個(gè).frm的結(jié)構(gòu)定義文件洼滚，一個(gè).ARZ的數(shù)據(jù)壓縮文件還有一個(gè).ARM的meta信息文件。由于其所存放的數(shù)據(jù)的特殊性琳轿，ARCHIVE表不支持刪除判沟，修改操

作，僅支持插入和查詢(xún)操作崭篡。鎖定機(jī)制為行級(jí)鎖定。

9）BLACKHOLE存儲(chǔ)引擎

BLACKHOLE存儲(chǔ)引擎是一個(gè)非常有意思的存儲(chǔ)引擎吧秕，功能恰如其名琉闪，就是一個(gè)“黑洞”。就像我們unix系統(tǒng)下面的“/dev/null”設(shè)備一樣砸彬，不管我們寫(xiě)入任何信息颠毙，都是有去無(wú)回。

10）CSV存儲(chǔ)引擎

CSV存儲(chǔ)引擎實(shí)際上操作的就是一個(gè)標(biāo)準(zhǔn)的CSV文件砂碉，他不支持索引蛀蜜。起主要用途就是大家有些時(shí)候可能會(huì)需要通過(guò)數(shù)據(jù)庫(kù)中的數(shù)據(jù)導(dǎo)出成一份報(bào)表文件，而CSV文件是很多軟件都支持的一種較為標(biāo)準(zhǔn)的格式增蹭，所以我們可以通過(guò)先在數(shù)據(jù)庫(kù)中建立一張CVS表滴某，然后將生成的報(bào)表信息插入到該表，即可得到一份CSV報(bào)表文件了。

四霎奢、影響MySQLServer性能的相關(guān)因素

1商業(yè)需求對(duì)性能的影響

典型需求：一個(gè)論壇帖子總量的統(tǒng)計(jì)户誓，要求：實(shí)時(shí)更新。

2系統(tǒng)架構(gòu)及實(shí)現(xiàn)對(duì)性能的影響

以下幾類(lèi)數(shù)據(jù)都是不適合在數(shù)據(jù)庫(kù)中存放的：

二進(jìn)制多媒體數(shù)據(jù)

流水隊(duì)列數(shù)據(jù)

超大文本數(shù)據(jù)

通過(guò)Cache技術(shù)來(lái)提高系統(tǒng)性能：

系統(tǒng)各種配置及規(guī)則數(shù)據(jù)幕侠；

活躍用戶(hù)的基本信息數(shù)據(jù)帝美；

活躍用戶(hù)的個(gè)性化定制信息數(shù)據(jù)；

準(zhǔn)實(shí)時(shí)的統(tǒng)計(jì)信息數(shù)據(jù)晤硕；

其他一些訪問(wèn)頻繁但變更較少的數(shù)據(jù)悼潭；

3 Query語(yǔ)句對(duì)系統(tǒng)性能的影響

需求：取出某個(gè)group（假設(shè)id為1）下的用戶(hù)編號(hào)（id），用戶(hù)昵稱(chēng)（nick_name）舞箍，并按照加入組的時(shí)間（user_group.gmt_create）來(lái)進(jìn)行倒序排列舰褪，取出前20個(gè)。

解決方案一：

代碼如下:

SELECT id,nick_name FROM user,user_group WHERE user_group.group_id=1 and user_group.user_id=user.id ORDER BY user_group.gmt_create desc limit 100,20;

解決方案二：

SELECTuser.id,user.nick_nameFROM(

SELECTuser_id

FROMuser_group

WHEREuser_group.group_id=1

ORDERBYgmt_createdesc

limit 100,20)t,user

WHEREt.user_id=user.id;

通過(guò)比較兩個(gè)解決方案的執(zhí)行計(jì)劃创译，我們可以看到第一中解決方案中需要和user表參與Join的記錄數(shù)MySQL通過(guò)統(tǒng)計(jì)數(shù)據(jù)估算出來(lái)是31156抵知，也就是通過(guò)user_group表返回的所有滿足group_id=1的記錄數(shù)（系統(tǒng)中的實(shí)際數(shù)據(jù)是20000）。而第二種解決方案的執(zhí)行計(jì)劃中软族，user表參與Join的數(shù)據(jù)就只有20條刷喜，兩者相差很大，我們認(rèn)為第二中解決方案應(yīng)該明顯優(yōu)于第一種解決方案立砸。

4 Schema設(shè)計(jì)對(duì)系統(tǒng)的性能影響

盡量減少對(duì)數(shù)據(jù)庫(kù)訪問(wèn)的請(qǐng)求掖疮。

盡量減少無(wú)用數(shù)據(jù)的查詢(xún)請(qǐng)求。

5硬件環(huán)境對(duì)系統(tǒng)性能的影響

1颗祝、典型OLTP應(yīng)用系統(tǒng)

對(duì)于各種數(shù)據(jù)庫(kù)系統(tǒng)環(huán)境中大家最常見(jiàn)的OLTP系統(tǒng)浊闪，其特點(diǎn)是并發(fā)量大，整體數(shù)據(jù)量比較多螺戳，但每次訪問(wèn)的數(shù)據(jù)比較少搁宾，且訪問(wèn)的數(shù)據(jù)比較離散，活躍數(shù)據(jù)占總體數(shù)據(jù)的比例不是太大倔幼。對(duì)于這類(lèi)系統(tǒng)的數(shù)據(jù)庫(kù)實(shí)際上是最難維護(hù)盖腿，最難以?xún)?yōu)化的，對(duì)主機(jī)整體性能要求也是最高的损同。因?yàn)椴粌H訪問(wèn)量很高翩腐，數(shù)據(jù)量也不小。

針對(duì)上面的這些特點(diǎn)和分析膏燃，我們可以對(duì)OLTP的得出一個(gè)大致的方向茂卦。

雖然系統(tǒng)總體數(shù)據(jù)量較大，但是系統(tǒng)活躍數(shù)據(jù)在數(shù)據(jù)總量中所占的比例不大组哩，那么我們可以通過(guò)擴(kuò)大內(nèi)存容量來(lái)盡可能多的將活躍數(shù)據(jù)cache到內(nèi)存中等龙；

雖然IO訪問(wèn)非常頻繁处渣，但是每次訪問(wèn)的數(shù)據(jù)量較少且很離散，那么我們對(duì)磁盤(pán)存儲(chǔ)的要求是IOPS表現(xiàn)要很好而咆，吞吐量是次要因素霍比；

并發(fā)量很高，CPU每秒所要處理的請(qǐng)求自然也就很多暴备，所以CPU處理能力需要比較強(qiáng)勁悠瞬；

雖然與客戶(hù)端的每次交互的數(shù)據(jù)量并不是特別大，但是網(wǎng)絡(luò)交互非常頻繁涯捻，所以主機(jī)與客戶(hù)端交互的網(wǎng)絡(luò)設(shè)備對(duì)流量能力也要求不能太弱浅妆。

2、典型OLAP應(yīng)用系統(tǒng)

用于數(shù)據(jù)分析的OLAP系統(tǒng)的主要特點(diǎn)就是數(shù)據(jù)量非常大障癌，并發(fā)訪問(wèn)不多凌外，但每次訪問(wèn)所需要檢索的數(shù)據(jù)量都比較多，而且數(shù)據(jù)訪問(wèn)相對(duì)較為集中涛浙，沒(méi)有太明顯的活躍數(shù)據(jù)概念康辑。

基于OLAP系統(tǒng)的各種特點(diǎn)和相應(yīng)的分析，針對(duì)OLAP系統(tǒng)硬件優(yōu)化的大致策略如下：

數(shù)據(jù)量非常大轿亮，所以磁盤(pán)存儲(chǔ)系統(tǒng)的單位容量需要盡量大一些疮薇；

單次訪問(wèn)數(shù)據(jù)量較大，而且訪問(wèn)數(shù)據(jù)比較集中我注，那么對(duì)IO系統(tǒng)的性能要求是需要有盡可能大的每秒IO吞吐量按咒，所以應(yīng)該選用每秒吞吐量盡可能大的磁盤(pán)；

雖然IO性能要求也比較高但骨，但是并發(fā)請(qǐng)求較少励七，所以CPU處理能力較難成為性能瓶頸，所以CPU處理能力沒(méi)有太苛刻的要求奔缠；

雖然每次請(qǐng)求的訪問(wèn)量很大掠抬，但是執(zhí)行過(guò)程中的數(shù)據(jù)大都不會(huì)返回給客戶(hù)端，最終返回給客戶(hù)端的數(shù)據(jù)量都較小校哎，所以和客戶(hù)端交互的網(wǎng)絡(luò)設(shè)備要求并不是太高剿另；

此外，由于OLAP系統(tǒng)由于其每次運(yùn)算過(guò)程較長(zhǎng)贬蛙，可以很好的并行化，所以一般的OLAP系統(tǒng)都是由多臺(tái)主機(jī)構(gòu)成的一個(gè)集群谚攒，而集群中主機(jī)與主機(jī)之間的數(shù)據(jù)交互量一般來(lái)說(shuō)都是非常大的阳准，所以在集群中主機(jī)之間的網(wǎng)絡(luò)設(shè)備要求很高。

3馏臭、除了以上兩個(gè)典型應(yīng)用之外野蝇，還有一類(lèi)比較特殊的應(yīng)用系統(tǒng)讼稚，他們的數(shù)據(jù)量不是特別大，但是訪問(wèn)請(qǐng)求及其頻繁绕沈，而且大部分是讀請(qǐng)求锐想。可能每秒需要提供上萬(wàn)甚至幾萬(wàn)次請(qǐng)求乍狐，每次請(qǐng)求都非常簡(jiǎn)單赠摇，可能大部分都只有一條或者幾條比較小的記錄返回，就比如基于數(shù)據(jù)庫(kù)的DNS服務(wù)就是這樣類(lèi)型的服務(wù)浅蚪。

雖然數(shù)據(jù)量小藕帜，但是訪問(wèn)極其頻繁，所以可以通過(guò)較大的內(nèi)存來(lái)cache住大部分的數(shù)據(jù)惜傲，這能夠保證非常高的命中率洽故，磁盤(pán)IO量比較小，所以磁盤(pán)也不需要特別高性能的盗誊；

并發(fā)請(qǐng)求非常頻繁时甚，比需要較強(qiáng)的CPU處理能力才能處理；

雖然應(yīng)用與數(shù)據(jù)庫(kù)交互量非常大哈踱，但是每次交互數(shù)據(jù)較少荒适，總體流量雖然也會(huì)較大，但是一般來(lái)說(shuō)普通的千兆網(wǎng)卡已經(jīng)足夠了嚣鄙。

五吻贿、MySQL 鎖定機(jī)制簡(jiǎn)介

行級(jí)鎖定（row-level）

表級(jí)鎖定（table-level）

頁(yè)級(jí)鎖定（page-level）

在MySQL數(shù)據(jù)庫(kù)中，使用表級(jí)鎖定的主要是MyISAM哑子，Memory舅列，CSV等一些非事務(wù)性存儲(chǔ)引擎，而使用行級(jí)鎖定的主要是Innodb存儲(chǔ)引擎和NDBCluster存儲(chǔ)引擎卧蜓，頁(yè)級(jí)鎖定主要是BerkeleyDB存儲(chǔ)引擎的鎖定方式帐要。

六、MySQL Query的優(yōu)化

Query語(yǔ)句的優(yōu)化思路和原則主要提現(xiàn)在以下幾個(gè)方面：

1. 優(yōu)化更需要優(yōu)化的Query弥奸；

2. 定位優(yōu)化對(duì)象的性能瓶頸榨惠；

3. 明確的優(yōu)化目標(biāo)；

4. 從Explain入手盛霎；

5. 多使用profile

6. 永遠(yuǎn)用小結(jié)果集驅(qū)動(dòng)大的結(jié)果集赠橙；

7. 盡可能在索引中完成排序；

8. 只取出自己需要的Columns愤炸；

9. 僅僅使用最有效的過(guò)濾條件期揪；

10.盡可能避免復(fù)雜的Join和子查詢(xún)；

合理設(shè)計(jì)并利用索引

1）B-Tree索引

一般來(lái)說(shuō)规个，MySQL中的B-Tree索引的物理文件大多都是以BalanceTree的結(jié)構(gòu)來(lái)存儲(chǔ)的凤薛，也就是所有實(shí)際需要的數(shù)據(jù)都存放于Tree的LeafNode姓建，而且到任何一個(gè)LeafNode的最短路徑的長(zhǎng)度都是完全相同的，所以我們大家都稱(chēng)之為B-Tree索引當(dāng)然缤苫，可能各種數(shù)據(jù)庫(kù)（或MySQL的各種存儲(chǔ)引擎）在存放自己的B-Tree索引的時(shí)候會(huì)對(duì)存儲(chǔ)結(jié)構(gòu)稍作改造速兔。如Innodb存儲(chǔ)引擎的B-Tree索引實(shí)際使用的存儲(chǔ)結(jié)構(gòu)實(shí)際上是B+Tree，也就是在B-Tree數(shù)據(jù)結(jié)構(gòu)的基礎(chǔ)上做了很小的改造活玲，在每一個(gè)LeafNode上面出了存放索引鍵的相關(guān)信息之外涣狗，還存儲(chǔ)了指向與該LeafNode相鄰的后一個(gè)LeafNode的指針信息，這主要是為了加快檢索多個(gè)相鄰LeafNode的效率考慮翼虫。

2）Hash索引

Hash索引在MySQL中使用的并不是很多屑柔，目前主要是Memory存儲(chǔ)引擎使用，而且在Memory存儲(chǔ)引擎中將Hash索引作為默認(rèn)的索引類(lèi)型珍剑。所謂Hash索引掸宛，實(shí)際上就是通過(guò)一定的Hash算法，將需要索引的鍵值進(jìn)行Hash運(yùn)算招拙，然后將得到的Hash值存入一個(gè)Hash表中唧瘾。然后每次需要檢索的時(shí)候，都會(huì)將檢索條件進(jìn)行相同算法的Hash運(yùn)算别凤，然后再和Hash表中的Hash值進(jìn)行比較并得出相應(yīng)的信息饰序。

Hash索引僅僅只能滿足“=”,“IN”和“<=>”查詢(xún)，不能使用范圍查詢(xún)规哪；

Hash索引無(wú)法被利用來(lái)避免數(shù)據(jù)的排序操作求豫；

Hash索引不能利用部分索引鍵查詢(xún)；

Hash索引在任何時(shí)候都不能避免表掃面诉稍；

Hash索引遇到大量Hash值相等的情況后性能并不一定就會(huì)比B-Tree索引高蝠嘉；

3）Full-text索引

Full-text索引也就是我們常說(shuō)的全文索引，目前在MySQL中僅有MyISAM存儲(chǔ)引擎支持杯巨，而且也并不是所有的數(shù)據(jù)類(lèi)型都支持全文索引蚤告。目前來(lái)說(shuō)，僅有CHAR服爷，VARCHAR和TEXT這三種數(shù)據(jù)類(lèi)型的列可以建Full-text索引杜恰。

索引能夠極大的提高數(shù)據(jù)檢索效率，也能夠改善排序分組操作的性能仍源，但是我們不能忽略的一個(gè)問(wèn)題就是索引是完全獨(dú)立于基礎(chǔ)數(shù)據(jù)之外的一部分?jǐn)?shù)據(jù)心褐，更新數(shù)據(jù)會(huì)帶來(lái)的IO量和調(diào)整索引所致的計(jì)算量的資源消耗。

是否需要?jiǎng)?chuàng)建索引笼踩，幾點(diǎn)原則：較頻繁的作為查詢(xún)條件的字段應(yīng)該創(chuàng)建索引檬寂；唯一性太差的字段不適合單獨(dú)創(chuàng)建索引，即使頻繁作為查詢(xún)條件戳表；更新非常頻繁的字段不適合創(chuàng)建索引桶至；

不會(huì)出現(xiàn)在WHERE子句中的字段不該創(chuàng)建索引；

Join語(yǔ)句的優(yōu)化

盡可能減少Join語(yǔ)句中的NestedLoop的循環(huán)總次數(shù)匾旭；“永遠(yuǎn)用小結(jié)果集驅(qū)動(dòng)大的結(jié)果集”镣屹。

優(yōu)先優(yōu)化NestedLoop的內(nèi)層循環(huán)；

保證Join語(yǔ)句中被驅(qū)動(dòng)表上Join條件字段已經(jīng)被索引价涝；

當(dāng)無(wú)法保證被驅(qū)動(dòng)表的Join條件字段被索引且內(nèi)存資源充足的前提下女蜈，不要太吝惜JoinBuffer的設(shè)置；

ORDER BY色瘩，GROUP BY和DISTINCT優(yōu)化

1）ORDER BY的實(shí)現(xiàn)與優(yōu)化

優(yōu)化Query語(yǔ)句中的ORDER BY的時(shí)候伪窖，盡可能利用已有的索引來(lái)避免實(shí)際的排序計(jì)算，可以很大幅度的提升ORDER BY操作的性能居兆。

優(yōu)化排序：

1.加大max_length_for_sort_data參數(shù)的設(shè)置覆山；

2.去掉不必要的返回字段；

3.增大sort_buffer_size參數(shù)設(shè)置泥栖；

2）GROUP BY的實(shí)現(xiàn)與優(yōu)化

由于GROUP BY實(shí)際上也同樣需要進(jìn)行排序操作簇宽，而且與ORDER BY相比，GROUP BY主要只是多了排序之后的分組操作吧享。當(dāng)然魏割，如果在分組的時(shí)候還使用了其他的一些聚合函數(shù)，那么還需要一些聚合函數(shù)的計(jì)算钢颂。所以钞它，在GROUP BY的實(shí)現(xiàn)過(guò)程中，與ORDER BY一樣也可以利用到索引殊鞭。

3）DISTINCT的實(shí)現(xiàn)與優(yōu)化

DISTINCT實(shí)際上和GROUP BY的操作非常相似遭垛，只不過(guò)是在GROUP BY之后的每組中只取出一條記錄而已。所以钱豁，DISTINCT的實(shí)現(xiàn)和GROUP BY的實(shí)現(xiàn)也基本差不多耻卡，沒(méi)有太大的區(qū)別。同樣可以通過(guò)松散索引掃描或者是緊湊索引掃描來(lái)實(shí)現(xiàn)牲尺，當(dāng)然卵酪，在無(wú)法僅僅使用索引即能完成DISTINCT的時(shí)候，MySQL只能通過(guò)臨時(shí)表來(lái)完成谤碳。但是溃卡，和GROUP BY有一點(diǎn)差別的是，DISTINCT并不需要進(jìn)行排序蜒简。也就是說(shuō)瘸羡，在僅僅只是DISTINCT操作的Query如果無(wú)法僅僅利用索引完成操作的時(shí)候，MySQL會(huì)利用臨時(shí)表來(lái)做一次數(shù)據(jù)的“緩存”搓茬，但是不會(huì)對(duì)臨時(shí)表中的數(shù)據(jù)進(jìn)行filesort操作犹赖。

七队他、MySQL數(shù)據(jù)庫(kù)Schema設(shè)計(jì)的性能優(yōu)化

高效的模型設(shè)計(jì)

適度冗余-讓Query盡兩減少Join

大字段垂直分拆-summary表優(yōu)化

大表水平分拆-基于類(lèi)型的分拆優(yōu)化

統(tǒng)計(jì)表-準(zhǔn)實(shí)時(shí)優(yōu)化

合適的數(shù)據(jù)類(lèi)型

類(lèi)并不是太多，我們常用的主要就是DATETIME峻村，DATE和TIMESTAMP這三種了麸折。從存儲(chǔ)空間來(lái)看TIMESTAMP最少，四個(gè)字節(jié)粘昨，而其他兩種數(shù)據(jù)類(lèi)型都是八個(gè)字節(jié)垢啼，多了一倍。而TIMESTAMP的缺點(diǎn)在于他只能存儲(chǔ)從1970年之后的時(shí)間张肾，而另外兩種時(shí)間類(lèi)型可以存放最早從1001年開(kāi)始的時(shí)間芭析。如果有需要存放早于1970年之前的時(shí)間的需求，我們必須放棄TIMESTAMP類(lèi)型吞瞪，但是只要我們不需要使用1970年之前的時(shí)間馁启，最好盡量使用TIMESTAMP來(lái)減少存儲(chǔ)空間的占用。

字符存儲(chǔ)類(lèi)型

CHAR[(M)]類(lèi)型屬于靜態(tài)長(zhǎng)度類(lèi)型尸饺，存放長(zhǎng)度完全以字符數(shù)來(lái)計(jì)算进统，所以最終的存儲(chǔ)長(zhǎng)度是基于字符集的，如latin1則最大存儲(chǔ)長(zhǎng)度為255字節(jié)浪听，但是如果使用gbk則最大存儲(chǔ)長(zhǎng)度為510字節(jié)螟碎。CHAR類(lèi)型的存儲(chǔ)特點(diǎn)是不管我們實(shí)際存放多長(zhǎng)數(shù)據(jù)，在數(shù)據(jù)庫(kù)中都會(huì)存放M個(gè)字符迹栓，不夠的通過(guò)空格補(bǔ)上掉分，M默認(rèn)為1。雖然CHAR會(huì)通過(guò)空格補(bǔ)齊存放的空間克伊，但是在訪問(wèn)數(shù)據(jù)的時(shí)候酥郭，MySQL會(huì)忽略最后的所有空格，所以如果我們的實(shí)際數(shù)據(jù)中如果在最后確實(shí)需要空格愿吹，則不能使用CHAR類(lèi)型來(lái)存放不从。

VARCHAR[(M)]屬于動(dòng)態(tài)存儲(chǔ)長(zhǎng)度類(lèi)型，僅存占用實(shí)際存儲(chǔ)數(shù)據(jù)的長(zhǎng)度犁跪。TINYTEXT椿息，TEXT，MEDIUMTEXT和LONGTEXT這四種類(lèi)型同屬于一種存儲(chǔ)方式坷衍，都是動(dòng)態(tài)存儲(chǔ)長(zhǎng)度類(lèi)型寝优，不同的僅僅是最大長(zhǎng)度的限制。

事務(wù)優(yōu)化

1. 臟讀：臟讀就是指當(dāng)一個(gè)事務(wù)正在訪問(wèn)數(shù)據(jù)枫耳，并且對(duì)數(shù)據(jù)進(jìn)行了修改乏矾，而這種修改還沒(méi)有提交到數(shù)據(jù)庫(kù)中，這時(shí)，另外一個(gè)事務(wù)也訪問(wèn)這個(gè)數(shù)據(jù)钻心，然后使用了這個(gè)數(shù)據(jù)凄硼。

2. 不可重復(fù)讀：是指在一個(gè)事務(wù)內(nèi)，多次讀同一數(shù)據(jù)扔役。在這個(gè)事務(wù)還沒(méi)有結(jié)束時(shí)帆喇，另外一個(gè)事務(wù)也訪問(wèn)該同一數(shù)據(jù)。那么亿胸，在第一個(gè)事務(wù)中的兩次讀數(shù)據(jù)之間，由于第二個(gè)事務(wù)的修改预皇，那么第一個(gè)事務(wù)兩次讀到的的數(shù)據(jù)可能是不一樣的侈玄。這樣就發(fā)生了在一個(gè)事務(wù)內(nèi)兩次讀到的數(shù)據(jù)是不一樣的，因此稱(chēng)為是不可重復(fù)讀吟温。

3. 幻讀：是指當(dāng)事務(wù)不是獨(dú)立執(zhí)行時(shí)發(fā)生的一種現(xiàn)象序仙，例如第一個(gè)事務(wù)對(duì)一個(gè)表中的數(shù)據(jù)進(jìn)行了修改，這種修改涉及到表中的全部數(shù)據(jù)行鲁豪。同時(shí)潘悼，第二個(gè)事務(wù)也修改這個(gè)表中的數(shù)據(jù)，這種修改是向表中插入一行新數(shù)據(jù)爬橡。那么治唤，以后就會(huì)發(fā)生操作第一個(gè)事務(wù)的用戶(hù)發(fā)現(xiàn)表中還有沒(méi)有修改的數(shù)據(jù)行，就好象發(fā)生了幻覺(jué)一樣糙申。

Innodb在事務(wù)隔離級(jí)別方面支持的信息如下：

1.READ UNCOMMITTED

常被成為Dirty Reads（臟讀）宾添，可以說(shuō)是事務(wù)上的最低隔離級(jí)別：在普通的非鎖定模式下SELECT的執(zhí)行使我們看到的數(shù)據(jù)可能并不是查詢(xún)發(fā)起時(shí)間點(diǎn)的數(shù)據(jù)，因而在這個(gè)隔離度下是非Consistent Reads（一致性讀）柜裸；

2.READ COMMITTED

這一隔離級(jí)別下缕陕，不會(huì)出現(xiàn)DirtyRead，但是可能出現(xiàn)Non-RepeatableReads(不可重復(fù)讀)和PhantomReads（幻讀）疙挺。

3. REPEATABLE READ

REPEATABLE READ隔離級(jí)別是InnoDB默認(rèn)的事務(wù)隔離級(jí)扛邑。在REPEATABLE READ隔離級(jí)別下，不會(huì)出現(xiàn)DirtyReads铐然，也不會(huì)出現(xiàn)Non-Repeatable Read蔬崩，但是仍然存在PhantomReads的可能性。

4.SERIALIZABLE

SERIALIZABLE隔離級(jí)別是標(biāo)準(zhǔn)事務(wù)隔離級(jí)別中的最高級(jí)別锦爵。設(shè)置為SERIALIZABLE隔離級(jí)別之后舱殿，在事務(wù)中的任何時(shí)候所看到的數(shù)據(jù)都是事務(wù)啟動(dòng)時(shí)刻的狀態(tài)，不論在這期間有沒(méi)有其他事務(wù)已經(jīng)修改了某些數(shù)據(jù)并提交险掀。所以沪袭，SERIALIZABLE事務(wù)隔離級(jí)別下，PhantomReads也不會(huì)出現(xiàn)。

八冈绊、可擴(kuò)展性設(shè)計(jì)之?dāng)?shù)據(jù)切分

數(shù)據(jù)的垂直切分

數(shù)據(jù)的垂直切分侠鳄，也可以稱(chēng)之為縱向切分。將數(shù)據(jù)庫(kù)想象成為由很多個(gè)一大塊一大塊的“數(shù)據(jù)塊”（表）組成死宣，我們垂直的將這些“數(shù)據(jù)塊”切開(kāi)伟恶，然后將他們分散到多臺(tái)數(shù)據(jù)庫(kù)主機(jī)上面。這樣的切分方法就是一個(gè)垂直（縱向）的數(shù)據(jù)切分毅该。

垂直切分的優(yōu)點(diǎn)

◆數(shù)據(jù)庫(kù)的拆分簡(jiǎn)單明了博秫，拆分規(guī)則明確；

◆應(yīng)用程序模塊清晰明確眶掌，整合容易挡育；

◆數(shù)據(jù)維護(hù)方便易行，容易定位朴爬；

垂直切分的缺點(diǎn)

◆部分表關(guān)聯(lián)無(wú)法在數(shù)據(jù)庫(kù)級(jí)別完成即寒，需要在程序中完成；

◆對(duì)于訪問(wèn)極其頻繁且數(shù)據(jù)量超大的表仍然存在性能平靜召噩，不一定能滿足要求母赵；

◆事務(wù)處理相對(duì)更為復(fù)雜；

◆切分達(dá)到一定程度之后具滴，擴(kuò)展性會(huì)遇到限制凹嘲；

◆過(guò)讀切分可能會(huì)帶來(lái)系統(tǒng)過(guò)渡復(fù)雜而難以維護(hù)。

數(shù)據(jù)的水平切分

數(shù)據(jù)的垂直切分基本上可以簡(jiǎn)單的理解為按照表按照模塊來(lái)切分?jǐn)?shù)據(jù)抵蚊，而水平切分就不再是按照表或者是功能模塊來(lái)切分了施绎。一般來(lái)說(shuō)，簡(jiǎn)單的水平切分主要是將某個(gè)訪問(wèn)極其平凡的表再按照某個(gè)字段的某種規(guī)則來(lái)分散到多個(gè)表之中贞绳，每個(gè)表中包含一部分?jǐn)?shù)據(jù)谷醉。

水平切分的優(yōu)點(diǎn)

◆表關(guān)聯(lián)基本能夠在數(shù)據(jù)庫(kù)端全部完成；

◆不會(huì)存在某些超大型數(shù)據(jù)量和高負(fù)載的表遇到瓶頸的問(wèn)題冈闭；

◆應(yīng)用程序端整體架構(gòu)改動(dòng)相對(duì)較少俱尼；

◆事務(wù)處理相對(duì)簡(jiǎn)單；

◆只要切分規(guī)則能夠定義好萎攒，基本上較難遇到擴(kuò)展性限制遇八；

水平切分的缺點(diǎn)

◆切分規(guī)則相對(duì)更為復(fù)雜，很難抽象出一個(gè)能夠滿足整個(gè)數(shù)據(jù)庫(kù)的切分規(guī)則耍休；

◆后期數(shù)據(jù)的維護(hù)難度有所增加刃永，人為手工定位數(shù)據(jù)更困難；

◆應(yīng)用系統(tǒng)各模塊耦合度較高羊精，可能會(huì)對(duì)后面數(shù)據(jù)的遷移拆分造成一定的困難斯够。

數(shù)據(jù)切分與整合中可能存在的問(wèn)題

1.引入分布式事務(wù)的問(wèn)題

完全可以將一個(gè)跨多個(gè)數(shù)據(jù)庫(kù)的分布式事務(wù)分拆成多個(gè)僅處于單個(gè)數(shù)據(jù)庫(kù)上面的小事務(wù)，并通過(guò)應(yīng)用程序來(lái)總控各個(gè)小事務(wù)。當(dāng)然读规，這樣作的要求就是我們的俄應(yīng)用程序必須要有足夠的健壯性抓督，當(dāng)然也會(huì)給應(yīng)用程序帶來(lái)一些技術(shù)難度。

2.跨節(jié)點(diǎn)Join的問(wèn)題

推薦通過(guò)應(yīng)用程序來(lái)進(jìn)行處理束亏，先在驅(qū)動(dòng)表所在的MySQLServer中取出相應(yīng)的驅(qū)動(dòng)結(jié)果集铃在，然后根據(jù)驅(qū)動(dòng)結(jié)果集再到被驅(qū)動(dòng)表所在的MySQL Server中取出相應(yīng)的數(shù)據(jù)。

3.跨節(jié)點(diǎn)合并排序分頁(yè)問(wèn)題

從多個(gè)數(shù)據(jù)源并行的取數(shù)據(jù)碍遍，然后應(yīng)用程序匯總處理定铜。

九、可擴(kuò)展性設(shè)計(jì)之Cache與Search的利用

通過(guò)引入Cache（Redis怕敬、Memcached）宿稀，減少數(shù)據(jù)庫(kù)的訪問(wèn)，增加性能赖捌。

通過(guò)引入Search（Lucene、Solr矮烹、ElasticSearch）越庇，利用搜索引擎高效的全文索引和分詞算法，以及高效的數(shù)據(jù)檢索實(shí)現(xiàn)奉狈，來(lái)解決數(shù)據(jù)庫(kù)和傳統(tǒng)的Cache軟件完全無(wú)法解決的全文模糊搜索卤唉、分類(lèi)統(tǒng)計(jì)查詢(xún)等功能。