自己想深入學(xué)習(xí)Mysql方面的知識(shí)，最近在網(wǎng)上看到一篇不錯(cuò)的文章：
一、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ǔ)類型的表的存儲(chǔ)今野，也就是說不管這個(gè)表有多少個(gè)索引葡公，都是存放在同一個(gè).MYI文件中罐农。
MyISAM支持以下三種類型的索引：
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)說宠默，也僅支持geometry類型的字段作索引麸恍。
3、Full-text索引
Full-text索引就是我們長(zhǎng)說的全文索引，他的存儲(chǔ)結(jié)構(gòu)也是b-tree抹沪。主要是為了解決在我們需要用like查詢的低效問題刻肄。
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版本才開始提供的新功能。
4）Merge存儲(chǔ)引擎
MERGE存儲(chǔ)引擎欠肾，在MySQL用戶手冊(cè)中也提到了瓶颠，也被大家認(rèn)識(shí)為MRG_MyISAM引擎。Why刺桃？因?yàn)镸ERGE存儲(chǔ)引擎可以簡(jiǎn)單的理解為其功能就是實(shí)現(xiàn)了對(duì)結(jié)構(gòu)相同的MyISAM表步清，通過一些特殊的包裝對(duì)外提供一個(gè)單一的訪問入口，以達(dá)到減小應(yīng)用的復(fù)雜度的目的虏肾。要?jiǎng)?chuàng)建MERGE表廓啊，不僅僅基表的結(jié)構(gòu)要完全一致，包括字段的順序封豪，基表的索引也必須完全一致谴轮。
5）Memory存儲(chǔ)引擎
Memory存儲(chǔ)引擎，通過名字就很容易讓人知道吹埠，他是一個(gè)將數(shù)據(jù)存儲(chǔ)在內(nèi)存中的存儲(chǔ)引擎第步。Memory存儲(chǔ)引擎不會(huì)將任何數(shù)據(jù)存放到磁盤上，僅僅存放了一個(gè)表結(jié)構(gòu)相關(guān)信息的.frm文件在磁盤上面缘琅。所以一旦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類型的字段堆生。Memory存儲(chǔ)引擎實(shí)現(xiàn)頁(yè)級(jí)鎖定。
6）BDB存儲(chǔ)引擎
BDB存儲(chǔ)引擎全稱為BerkeleyDB存儲(chǔ)引擎雷酪，和Innodb一樣淑仆，也不是MySQL自己開發(fā)實(shí)現(xiàn)的一個(gè)存儲(chǔ)引擎，而是由SleepycatSoftware所提供哥力，當(dāng)然蔗怠，也是開源存儲(chǔ)引擎，同樣支持事務(wù)安全。
7）FEDERATED存儲(chǔ)引擎
FEDERATED存儲(chǔ)引擎所實(shí)現(xiàn)的功能寞射，和Oracle的DBLINK基本相似最住，主要用來(lái)提供對(duì)遠(yuǎn)程MySQL服務(wù)器上面的數(shù)據(jù)的訪問接口。如果我們使用源碼編譯來(lái)安裝MySQL怠惶，那么必須手工指定啟用FEDERATED存儲(chǔ)引擎才行涨缚，因?yàn)镸ySQL默認(rèn)是不起用該存儲(chǔ)引擎的。
8）ARCHIVE存儲(chǔ)引擎
ARCHIVE存儲(chǔ)引擎主要用于通過較小的存儲(chǔ)空間來(lái)存放過期的很少訪問的歷史數(shù)據(jù)策治。ARCHIVE表不支持索引脓魏，通過一個(gè).frm的結(jié)構(gòu)定義文件，一個(gè).ARZ的數(shù)據(jù)壓縮文件還有一個(gè).ARM的meta信息文件通惫。由于其所存放的數(shù)據(jù)的特殊性茂翔，ARCHIVE表不支持刪除，修改操
作履腋，僅支持插入和查詢操作珊燎。鎖定機(jī)制為行級(jí)鎖定。
9）BLACKHOLE存儲(chǔ)引擎
BLACKHOLE存儲(chǔ)引擎是一個(gè)非常有意思的存儲(chǔ)引擎遵湖，功能恰如其名悔政，就是一個(gè)“黑洞”。就像我們unix系統(tǒng)下面的“/dev/null”設(shè)備一樣延旧，不管我們寫入任何信息谋国，都是有去無(wú)回。
10）CSV存儲(chǔ)引擎
CSV存儲(chǔ)引擎實(shí)際上操作的就是一個(gè)標(biāo)準(zhǔn)的CSV文件迁沫，他不支持索引芦瘾。起主要用途就是大家有些時(shí)候可能會(huì)需要通過數(shù)據(jù)庫(kù)中的數(shù)據(jù)導(dǎo)出成一份報(bào)表文件，而CSV文件是很多軟件都支持的一種較為標(biāo)準(zhǔn)的格式集畅，所以我們可以通過先在數(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ì)性能的影響
以下幾類數(shù)據(jù)都是不適合在數(shù)據(jù)庫(kù)中存放的：
二進(jìn)制多媒體數(shù)據(jù)
流水隊(duì)列數(shù)據(jù)
超大文本數(shù)據(jù)
通過Cache技術(shù)來(lái)提高系統(tǒng)性能：
系統(tǒng)各種配置及規(guī)則數(shù)據(jù)谣辞；
活躍用戶的基本信息數(shù)據(jù)；
活躍用戶的個(gè)性化定制信息數(shù)據(jù)沐扳；
準(zhǔn)實(shí)時(shí)的統(tǒng)計(jì)信息數(shù)據(jù)；
其他一些訪問頻繁但變更較少的數(shù)據(jù)句占；
3 Query語(yǔ)句對(duì)系統(tǒng)性能的影響
需求：取出某個(gè)group（假設(shè)id為1）下的用戶編號(hào)（id）沪摄，用戶昵稱（nick_name），并按照加入組的時(shí)間（user_group.gmt_create）來(lái)進(jìn)行倒序排列，取出前20個(gè)杨拐。
解決方案一：
SELECTid,nick_nameFROMuser,user_groupWHEREuser_group.group_id=1anduser_group.user_id=user.idORDERBYuser_group.gmt_createdesclimit100,20;
解決方案二：
SELECTuser.id,user.nick_nameFROM(SELECTuser_idFROMuser_groupWHEREuser_group.group_id=1ORDERBYgmt_createdesclimit100,20)t,userWHEREt.user_id=user.id;
通過比較兩個(gè)解決方案的執(zhí)行計(jì)劃祈餐，我們可以看到第一中解決方案中需要和user表參與Join的記錄數(shù)MySQL通過統(tǒng)計(jì)數(shù)據(jù)估算出來(lái)是31156，也就是通過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ù)訪問的請(qǐng)求。
盡量減少無(wú)用數(shù)據(jù)的查詢請(qǐng)求至扰。
5硬件環(huán)境對(duì)系統(tǒng)性能的影響
1鳍徽、典型OLTP應(yīng)用系統(tǒng)
對(duì)于各種數(shù)據(jù)庫(kù)系統(tǒng)環(huán)境中大家最常見的OLTP系統(tǒng)，其特點(diǎn)是并發(fā)量大敢课，整體數(shù)據(jù)量比較多阶祭，但每次訪問的數(shù)據(jù)比較少，且訪問的數(shù)據(jù)比較離散直秆，活躍數(shù)據(jù)占總體數(shù)據(jù)的比例不是太大濒募。對(duì)于這類系統(tǒng)的數(shù)據(jù)庫(kù)實(shí)際上是最難維護(hù)剑勾，最難以優(yōu)化的您宪，對(duì)主機(jī)整體性能要求也是最高的纷妆。因?yàn)椴粌H訪問量很高古掏，數(shù)據(jù)量也不小流部。
針對(duì)上面的這些特點(diǎn)和分析铁坎，我們可以對(duì)OLTP的得出一個(gè)大致的方向绸罗。
雖然系統(tǒng)總體數(shù)據(jù)量較大草添，但是系統(tǒng)活躍數(shù)據(jù)在數(shù)據(jù)總量中所占的比例不大遗座，那么我們可以通過擴(kuò)大內(nèi)存容量來(lái)盡可能多的將活躍數(shù)據(jù)cache到內(nèi)存中舀凛；
雖然IO訪問非常頻繁，但是每次訪問的數(shù)據(jù)量較少且很離散途蒋，那么我們對(duì)磁盤存儲(chǔ)的要求是IOPS表現(xiàn)要很好猛遍，吞吐量是次要因素；
并發(fā)量很高号坡，CPU每秒所要處理的請(qǐng)求自然也就很多懊烤，所以CPU處理能力需要比較強(qiáng)勁；
雖然與客戶端的每次交互的數(shù)據(jù)量并不是特別大宽堆，但是網(wǎng)絡(luò)交互非常頻繁腌紧，所以主機(jī)與客戶端交互的網(wǎng)絡(luò)設(shè)備對(duì)流量能力也要求不能太弱。
2畜隶、典型OLAP應(yīng)用系統(tǒng)
用于數(shù)據(jù)分析的OLAP系統(tǒng)的主要特點(diǎn)就是數(shù)據(jù)量非常大壁肋，并發(fā)訪問不多号胚，但每次訪問所需要檢索的數(shù)據(jù)量都比較多，而且數(shù)據(jù)訪問相對(duì)較為集中浸遗，沒有太明顯的活躍數(shù)據(jù)概念猫胁。
基于OLAP系統(tǒng)的各種特點(diǎn)和相應(yīng)的分析，針對(duì)OLAP系統(tǒng)硬件優(yōu)化的大致策略如下：
數(shù)據(jù)量非常大跛锌，所以磁盤存儲(chǔ)系統(tǒng)的單位容量需要盡量大一些弃秆；
單次訪問數(shù)據(jù)量較大，而且訪問數(shù)據(jù)比較集中髓帽，那么對(duì)IO系統(tǒng)的性能要求是需要有盡可能大的每秒IO吞吐量菠赚，所以應(yīng)該選用每秒吞吐量盡可能大的磁盤；
雖然IO性能要求也比較高氢卡，但是并發(fā)請(qǐng)求較少锈至，所以CPU處理能力較難成為性能瓶頸，所以CPU處理能力沒有太苛刻的要求译秦；
雖然每次請(qǐng)求的訪問量很大峡捡，但是執(zhí)行過程中的數(shù)據(jù)大都不會(huì)返回給客戶端，最終返回給客戶端的數(shù)據(jù)量都較小筑悴，所以和客戶端交互的網(wǎng)絡(luò)設(shè)備要求并不是太高们拙；
此外，由于OLAP系統(tǒng)由于其每次運(yùn)算過程較長(zhǎng)阁吝，可以很好的并行化砚婆，所以一般的OLAP系統(tǒng)都是由多臺(tái)主機(jī)構(gòu)成的一個(gè)集群，而集群中主機(jī)與主機(jī)之間的數(shù)據(jù)交互量一般來(lái)說都是非常大的突勇，所以在集群中主機(jī)之間的網(wǎng)絡(luò)設(shè)備要求很高装盯。
3、除了以上兩個(gè)典型應(yīng)用之外甲馋，還有一類比較特殊的應(yīng)用系統(tǒng)埂奈，他們的數(shù)據(jù)量不是特別大，但是訪問請(qǐng)求及其頻繁定躏，而且大部分是讀請(qǐng)求账磺。可能每秒需要提供上萬(wàn)甚至幾萬(wàn)次請(qǐng)求痊远，每次請(qǐng)求都非常簡(jiǎn)單垮抗，可能大部分都只有一條或者幾條比較小的記錄返回，就比如基于數(shù)據(jù)庫(kù)的DNS服務(wù)就是這樣類型的服務(wù)碧聪。
雖然數(shù)據(jù)量小冒版，但是訪問極其頻繁，所以可以通過較大的內(nèi)存來(lái)cache住大部分的數(shù)據(jù)矾削，這能夠保證非常高的命中率壤玫，磁盤IO量比較小豁护，所以磁盤也不需要特別高性能的哼凯；
并發(fā)請(qǐng)求非常頻繁欲间，比需要較強(qiáng)的CPU處理能力才能處理；
雖然應(yīng)用與數(shù)據(jù)庫(kù)交互量非常大断部，但是每次交互數(shù)據(jù)較少猎贴，總體流量雖然也會(huì)較大，但是一般來(lái)說普通的千兆網(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. 僅僅使用最有效的過濾條件曼月；
10.盡可能避免復(fù)雜的Join和子查詢；
合理設(shè)計(jì)并利用索引
1）B-Tree索引
一般來(lái)說柔昼，MySQL中的B-Tree索引的物理文件大多都是以BalanceTree的結(jié)構(gòu)來(lái)存儲(chǔ)的哑芹，也就是所有實(shí)際需要的數(shù)據(jù)都存放于Tree的LeafNode，而且到任何一個(gè)LeafNode的最短路徑的長(zhǎ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)的索引類型曹货。所謂Hash索引咆繁，實(shí)際上就是通過一定的Hash算法，將需要索引的鍵值進(jìn)行Hash運(yùn)算顶籽，然后將得到的Hash值存入一個(gè)Hash表中玩般。然后每次需要檢索的時(shí)候，都會(huì)將檢索條件進(jìn)行相同算法的Hash運(yùn)算礼饱，然后再和Hash表中的Hash值進(jìn)行比較并得出相應(yīng)的信息坏为。
Hash索引僅僅只能滿足“=”,“IN”和“<=>”查詢，不能使用范圍查詢镊绪；
Hash索引無(wú)法被利用來(lái)避免數(shù)據(jù)的排序操作匀伏；
Hash索引不能利用部分索引鍵查詢；
Hash索引在任何時(shí)候都不能避免表掃面蝴韭；
Hash索引遇到大量Hash值相等的情況后性能并不一定就會(huì)比B-Tree索引高够颠；
3）Full-text索引
Full-text索引也就是我們常說的全文索引，目前在MySQL中僅有MyISAM存儲(chǔ)引擎支持榄鉴，而且也并不是所有的數(shù)據(jù)類型都支持全文索引履磨。目前來(lái)說，僅有CHAR牢硅，VARCHAR和TEXT這三種數(shù)據(jù)類型的列可以建Full-text索引蹬耘。
索引能夠極大的提高數(shù)據(jù)檢索效率，也能夠改善排序分組操作的性能减余，但是我們不能忽略的一個(gè)問題就是索引是完全獨(dú)立于基礎(chǔ)數(shù)據(jù)之外的一部分?jǐn)?shù)據(jù)综苔，更新數(shù)據(jù)會(huì)帶來(lái)的IO量和調(diào)整索引所致的計(jì)算量的資源消耗。
是否需要?jiǎng)?chuàng)建索引位岔，幾點(diǎn)原則：較頻繁的作為查詢條件的字段應(yīng)該創(chuàng)建索引如筛；唯一性太差的字段不適合單獨(dú)創(chuàng)建索引，即使頻繁作為查詢條件抒抬；更新非常頻繁的字段不適合創(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)過程中，與ORDER BY一樣也可以利用到索引创橄。
3）DISTINCT的實(shí)現(xiàn)與優(yōu)化
DISTINCT實(shí)際上和GROUP BY的操作非常相似箩做，只不過是在GROUP BY之后的每組中只取出一條記錄而已。所以妥畏，DISTINCT的實(shí)現(xiàn)和GROUP BY的實(shí)現(xiàn)也基本差不多邦邦，沒有太大的區(qū)別。同樣可以通過松散索引掃描或者是緊湊索引掃描來(lái)實(shí)現(xiàn)醉蚁，當(dāng)然燃辖，在無(wú)法僅僅使用索引即能完成DISTINCT的時(shí)候，MySQL只能通過臨時(shí)表來(lái)完成网棍。但是黔龟，和GROUP BY有一點(diǎn)差別的是，DISTINCT并不需要進(jìn)行排序滥玷。也就是說氏身，在僅僅只是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)化
大表水平分拆-基于類型的分拆優(yōu)化
統(tǒng)計(jì)表-準(zhǔn)實(shí)時(shí)優(yōu)化
合適的數(shù)據(jù)類型
時(shí)間存儲(chǔ)格式總類并不是太多如贷，我們常用的主要就是DATETIME陷虎，DATE和TIMESTAMP這三種了。從存儲(chǔ)空間來(lái)看TIMESTAMP最少杠袱，四個(gè)字節(jié)尚猿，而其他兩種數(shù)據(jù)類型都是八個(gè)字節(jié)，多了一倍霞掺。而TIMESTAMP的缺點(diǎn)在于他只能存儲(chǔ)從1970年之后的時(shí)間谊路，而另外兩種時(shí)間類型可以存放最早從1001年開始的時(shí)間。如果有需要存放早于1970年之前的時(shí)間的需求菩彬，我們必須放棄TIMESTAMP類型缠劝，但是只要我們不需要使用1970年之前的時(shí)間潮梯，最好盡量使用TIMESTAMP來(lái)減少存儲(chǔ)空間的占用。
字符存儲(chǔ)類型
CHAR[(M)]類型屬于靜態(tài)長(zhǎng)度類型惨恭，存放長(zhǎng)度完全以字符數(shù)來(lái)計(jì)算秉馏，所以最終的存儲(chǔ)長(zhǎng)度是基于字符集的，如latin1則最大存儲(chǔ)長(zhǎng)度為255字節(jié)脱羡，但是如果使用gbk則最大存儲(chǔ)長(zhǎng)度為510字節(jié)萝究。CHAR類型的存儲(chǔ)特點(diǎn)是不管我們實(shí)際存放多長(zhǎng)數(shù)據(jù)，在數(shù)據(jù)庫(kù)中都會(huì)存放M個(gè)字符锉罐，不夠的通過空格補(bǔ)上帆竹，M默認(rèn)為1。雖然CHAR會(huì)通過空格補(bǔ)齊存放的空間脓规，但是在訪問數(shù)據(jù)的時(shí)候栽连，MySQL會(huì)忽略最后的所有空格，所以如果我們的實(shí)際數(shù)據(jù)中如果在最后確實(shí)需要空格侨舆，則不能使用CHAR類型來(lái)存放秒紧。
VARCHAR[(M)]屬于動(dòng)態(tài)存儲(chǔ)長(zhǎng)度類型，僅存占用實(shí)際存儲(chǔ)數(shù)據(jù)的長(zhǎng)度挨下。TINYTEXT熔恢，TEXT，MEDIUMTEXT和LONGTEXT這四種類型同屬于一種存儲(chǔ)方式臭笆，都是動(dòng)態(tài)存儲(chǔ)長(zhǎng)度類型叙淌，不同的僅僅是最大長(zhǎng)度的限制。
事務(wù)優(yōu)化
1.?臟讀：臟讀就是指當(dāng)一個(gè)事務(wù)正在訪問數(shù)據(jù)耗啦，并且對(duì)數(shù)據(jù)進(jìn)行了修改凿菩，而這種修改還沒有提交到數(shù)據(jù)庫(kù)中，這時(shí)帜讲，另外一個(gè)事務(wù)也訪問這個(gè)數(shù)據(jù)衅谷，然后使用了這個(gè)數(shù)據(jù)。
2.?不可重復(fù)讀：是指在一個(gè)事務(wù)內(nèi)似将，多次讀同一數(shù)據(jù)获黔。在這個(gè)事務(wù)還沒有結(jié)束時(shí)，另外一個(gè)事務(wù)也訪問該同一數(shù)據(jù)在验。那么玷氏，在第一個(gè)事務(wù)中的兩次讀數(shù)據(jù)之間，由于第二個(gè)事務(wù)的修改腋舌，那么第一個(gè)事務(wù)兩次讀到的的數(shù)據(jù)可能是不一樣的盏触。這樣就發(fā)生了在一個(gè)事務(wù)內(nèi)兩次讀到的數(shù)據(jù)是不一樣的，因此稱為是不可重復(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ù)的用戶發(fā)現(xiàn)表中還有沒有修改的數(shù)據(jù)行屉佳，就好象發(fā)生了幻覺一樣。
Innodb在事務(wù)隔離級(jí)別方面支持的信息如下：
1.READ UNCOMMITTED
常被成為Dirty Reads（臟讀）洲押，可以說是事務(wù)上的最低隔離級(jí)別：在普通的非鎖定模式下SELECT的執(zhí)行使我們看到的數(shù)據(jù)可能并不是查詢發(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)，不論在這期間有沒有其他事務(wù)已經(jīng)修改了某些數(shù)據(jù)并提交玉雾。所以翔试，SERIALIZABLE事務(wù)隔離級(jí)別下，PhantomReads也不會(huì)出現(xiàn)复旬。
八垦缅、可擴(kuò)展性設(shè)計(jì)之?dāng)?shù)據(jù)切分
數(shù)據(jù)的垂直切分
數(shù)據(jù)的垂直切分，也可以稱之為縱向切分驹碍。將數(shù)據(jù)庫(kù)想象成為由很多個(gè)一大塊一大塊的“數(shù)據(jù)塊”（表）組成壁涎，我們垂直的將這些“數(shù)據(jù)塊”切開，然后將他們分散到多臺(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ì)于訪問極其頻繁且數(shù)據(jù)量超大的表仍然存在性能平靜漫试，不一定能滿足要求六敬；
◆事務(wù)處理相對(duì)更為復(fù)雜；
◆切分達(dá)到一定程度之后驾荣，擴(kuò)展性會(huì)遇到限制外构；
◆過讀切分可能會(huì)帶來(lái)系統(tǒng)過渡復(fù)雜而難以維護(hù)。
數(shù)據(jù)的水平切分
數(shù)據(jù)的垂直切分基本上可以簡(jiǎn)單的理解為按照表按照模塊來(lái)切分?jǐn)?shù)據(jù)播掷，而水平切分就不再是按照表或者是功能模塊來(lái)切分了审编。一般來(lái)說，簡(jiǎn)單的水平切分主要是將某個(gè)訪問極其平凡的表再按照某個(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ù)載的表遇到瓶頸的問題件炉；
◆應(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ù)切分與整合中可能存在的問題
1.引入分布式事務(wù)的問題
完全可以將一個(gè)跨多個(gè)數(shù)據(jù)庫(kù)的分布式事務(wù)分拆成多個(gè)僅處于單個(gè)數(shù)據(jù)庫(kù)上面的小事務(wù)，并通過應(yīng)用程序來(lái)總控各個(gè)小事務(wù)呵燕。當(dāng)然棠绘，這樣作的要求就是我們的俄應(yīng)用程序必須要有足夠的健壯性，當(dāng)然也會(huì)給應(yīng)用程序帶來(lái)一些技術(shù)難度虏等。
2.跨節(jié)點(diǎn)Join的問題
推薦通過應(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è)問題
從多個(gè)數(shù)據(jù)源并行的取數(shù)據(jù)候引，然后應(yīng)用程序匯總處理。
九敦跌、可擴(kuò)展性設(shè)計(jì)之Cache與Search的利用
通過引入Cache（Redis澄干、Memcached）逛揩，減少數(shù)據(jù)庫(kù)的訪問，增加性能麸俘。
通過引入Search（Lucene辩稽、Solr、ElasticSearch）从媚，利用搜索引擎高效的全文索引和分詞算法逞泄，以及高效的數(shù)據(jù)檢索實(shí)現(xiàn)，來(lái)解決數(shù)據(jù)庫(kù)和傳統(tǒng)的Cache軟件完全無(wú)法解決的全文模糊搜索拜效、分類統(tǒng)計(jì)查詢等功能喷众。
