接著上一篇學習：http://www.dbjr.com.cn/article/70528.htm

七、MySQL數(shù)據(jù)庫Schema設計的性能優(yōu)化
高效的模型設計

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

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

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

統(tǒng)計表-準實時優(yōu)化

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

時間存儲格式總類并不是太多，我們常用的主要就是DATETIME，DATE和TIMESTAMP這三種了。從存儲空間來看TIMESTAMP最少，四個字節(jié)，而其他兩種數(shù)據(jù)類型都是八個字節(jié)，多了一倍。而TIMESTAMP的缺點在于他只能存儲從1970年之后的時間，而另外兩種時間類型可以存放最早從1001年開始的時間。如果有需要存放早于1970年之前的時間的需求，我們必須放棄TIMESTAMP類型，但是只要我們不需要使用1970年之前的時間，最好盡量使用TIMESTAMP來減少存儲空間的占用。

字符存儲類型

CHAR[(M)]類型屬于靜態(tài)長度類型，存放長度完全以字符數(shù)來計算，所以最終的存儲長度是基于字符集的，如latin1則最大存儲長度為255字節(jié)，但是如果使用gbk則最大存儲長度為510字節(jié)。CHAR類型的存儲特點是不管我們實際存放多長數(shù)據(jù)，在數(shù)據(jù)庫中都會存放M個字符，不夠的通過空格補上，M默認為1。雖然CHAR會通過空格補齊存放的空間，但是在訪問數(shù)據(jù)的時候，MySQL會忽略最后的所有空格，所以如果我們的實際數(shù)據(jù)中如果在最后確實需要空格，則不能使用CHAR類型來存放。

VARCHAR[(M)]屬于動態(tài)存儲長度類型，僅存占用實際存儲數(shù)據(jù)的長度。TINYTEXT，TEXT，MEDIUMTEXT和LONGTEXT這四種類型同屬于一種存儲方式，都是動態(tài)存儲長度類型，不同的僅僅是最大長度的限制。

事務優(yōu)化

1. 臟讀：臟讀就是指當一個事務正在訪問數(shù)據(jù)，并且對數(shù)據(jù)進行了修改，而這種修改還沒有提交到數(shù)據(jù)庫中，這時，另外一個事務也訪問這個數(shù)據(jù)，然后使用了這個數(shù)據(jù)。

2. 不可重復讀：是指在一個事務內，多次讀同一數(shù)據(jù)。在這個事務還沒有結束時，另外一個事務也訪問該同一數(shù)據(jù)。那么，在第一個事務中的兩次讀數(shù)據(jù)之間，由于第二個事務的修改，那么第一個事務兩次讀到的的數(shù)據(jù)可能是不一樣的。這樣就發(fā)生了在一個事務內兩次讀到的數(shù)據(jù)是不一樣的，因此稱為是不可重復讀。

3. 幻讀：是指當事務不是獨立執(zhí)行時發(fā)生的一種現(xiàn)象，例如第一個事務對一個表中的數(shù)據(jù)進行了修改，這種修改涉及到表中的全部數(shù)據(jù)行。同時，第二個事務也修改這個表中的數(shù)據(jù)，這種修改是向表中插入一行新數(shù)據(jù)。那么，以后就會發(fā)生操作第一個事務的用戶發(fā)現(xiàn)表中還有沒有修改的數(shù)據(jù)行，就好象發(fā)生了幻覺一樣。

Innodb在事務隔離級別方面支持的信息如下：

1.READ UNCOMMITTED

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

2.READ COMMITTED

這一隔離級別下，不會出現(xiàn)DirtyRead，但是可能出現(xiàn)Non-RepeatableReads(不可重復讀)和PhantomReads（幻讀）。

3. REPEATABLE READ

REPEATABLE READ隔離級別是InnoDB默認的事務隔離級。在REPEATABLE READ隔離級別下，不會出現(xiàn)DirtyReads，也不會出現(xiàn)Non-Repeatable Read，但是仍然存在PhantomReads的可能性。

4.SERIALIZABLE

SERIALIZABLE隔離級別是標準事務隔離級別中的最高級別。設置為SERIALIZABLE隔離級別之后，在事務中的任何時候所看到的數(shù)據(jù)都是事務啟動時刻的狀態(tài)，不論在這期間有沒有其他事務已經(jīng)修改了某些數(shù)據(jù)并提交。所以，SERIALIZABLE事務隔離級別下，PhantomReads也不會出現(xiàn)。

八、可擴展性設計之數(shù)據(jù)切分

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

數(shù)據(jù)的垂直切分，也可以稱之為縱向切分。將數(shù)據(jù)庫想象成為由很多個一大塊一大塊的“數(shù)據(jù)塊”（表）組成，我們垂直的將這些“數(shù)據(jù)塊”切開，然后將他們分散到多臺數(shù)據(jù)庫主機上面。這樣的切分方法就是一個垂直（縱向）的數(shù)據(jù)切分。

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

◆數(shù)據(jù)庫的拆分簡單明了，拆分規(guī)則明確；

◆應用程序模塊清晰明確，整合容易；

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

垂直切分的缺點

◆部分表關聯(lián)無法在數(shù)據(jù)庫級別完成，需要在程序中完成；

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

◆事務處理相對更為復雜；

◆切分達到一定程度之后，擴展性會遇到限制；

◆過讀切分可能會帶來系統(tǒng)過渡復雜而難以維護。

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

數(shù)據(jù)的垂直切分基本上可以簡單的理解為按照表按照模塊來切分數(shù)據(jù)，而水平切分就不再是按照表或者是功能模塊來切分了。一般來說，簡單的水平切分主要是將某個訪問極其平凡的表再按照某個字段的某種規(guī)則來分散到多個表之中，每個表中包含一部分數(shù)據(jù)。

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

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

◆不會存在某些超大型數(shù)據(jù)量和高負載的表遇到瓶頸的問題；

◆應用程序端整體架構改動相對較少；

◆事務處理相對簡單；

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

水平切分的缺點

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

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

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

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

1.引入分布式事務的問題

完全可以將一個跨多個數(shù)據(jù)庫的分布式事務分拆成多個僅處于單個數(shù)據(jù)庫上面的小事務，并通過應用程序來總控各個小事務。當然，這樣作的要求就是我們的俄應用程序必須要有足夠的健壯性，當然也會給應用程序帶來一些技術難度。

2.跨節(jié)點Join的問題

推薦通過應用程序來進行處理，先在驅動表所在的MySQLServer中取出相應的驅動結果集，然后根據(jù)驅動結果集再到被驅動表所在的MySQL Server中取出相應的數(shù)據(jù)。

3.跨節(jié)點合并排序分頁問題

從多個數(shù)據(jù)源并行的取數(shù)據(jù)，然后應用程序匯總處理。

九、可擴展性設計之Cache與Search的利用

通過引入Cache（Redis、Memcached），減少數(shù)據(jù)庫的訪問，增加性能。

通過引入Search（Lucene、Solr、ElasticSearch），利用搜索引擎高效的全文索引和分詞算法，以及高效的數(shù)據(jù)檢索實現(xiàn)，來解決數(shù)據(jù)庫和傳統(tǒng)的Cache軟件完全無法解決的全文模糊搜索、分類統(tǒng)計查詢等功能。

以上就是本文的全部內容，希望大家可以喜歡。

最新評論