資料庫的分區表

⑴ 浠涔堟槸鍒嗚〃鍜屽垎鍖篗ysql鏁版嵁搴撳垎鍖哄拰鍒嗚〃鏂規硶

1銆佷負浠涔堣佸垎琛ㄥ拰鍒嗗尯

鏃ュ父寮鍙戜腑鎴戜滑緇忓父浼氶亣鍒板ぇ琛ㄧ殑鎯呭喌錛屾墍璋撶殑澶ц〃鏄鎸囧瓨鍌ㄤ簡鐧句竾綰т箖鑷沖崈涓囩駭鏉¤板綍鐨勮〃銆傝繖鏍風殑琛ㄨ繃浜庡簽澶э紝瀵艱嚧鏁版嵁搴撳湪鏌ヨ㈠拰鎻掑叆鐨勬椂鍊欒楁椂澶闀匡紝鎬ц兘浣庝笅錛屽傛灉娑夊強鑱斿悎鏌ヨ㈢殑鎯呭喌錛屾ц兘浼氭洿鍔犵碂緋曘傚垎琛ㄥ拰琛ㄥ垎鍖虹殑鐩鐨勫氨鏄鍑忓皯鏁版嵁搴撶殑璐熸媴錛屾彁楂樻暟鎹搴撶殑鏁堢巼錛岄氬父鐐規潵璁插氨鏄鎻愰珮琛ㄧ殑澧炲垹鏀規煡鏁堢巼銆

2銆佷粈涔堟槸鍒嗚〃鍜屽垎鍖

2.1 鍒嗚〃

鍒嗚〃鏄灝嗕竴涓澶ц〃鎸夌収涓瀹氱殑瑙勫垯鍒嗚В鎴愬氬紶鍏鋒湁鐙絝嬪瓨鍌ㄧ┖闂寸殑瀹炰綋琛錛屾垜浠鍙浠ョО涓哄瓙琛錛屾瘡涓琛ㄩ兘瀵瑰簲涓変釜鏂囦歡錛孧YD鏁版嵁鏂囦歡錛.MYI緔㈠紩鏂囦歡錛.frm琛ㄧ粨鏋勬枃浠躲傝繖浜涘瓙琛ㄥ彲浠ュ垎甯冨湪鍚屼竴鍧楃佺洏涓婏紝涔熷彲浠ュ湪涓嶅悓鐨勬満鍣ㄤ笂銆俛pp璇誨啓鐨勬椂鍊欐牴鎹浜嬪厛瀹氫箟濂界殑瑙勫垯寰楀埌瀵瑰簲鐨勫瓙琛ㄥ悕錛岀劧鍚庡幓鎿嶄綔瀹冦

2.2 鍒嗗尯

鍒嗗尯鍜屽垎琛ㄧ浉浼礆紝閮芥槸鎸夌収瑙勫垯鍒嗚В琛ㄣ備笉鍚屽湪浜庡垎琛ㄥ皢澶ц〃鍒嗚В涓鴻嫢騫蹭釜鐙絝嬬殑瀹炰綋琛錛岃屽垎鍖烘槸灝嗘暟鎹鍒嗘靛垝鍒嗗湪澶氫釜浣嶇疆瀛樻斁錛屽彲浠ユ槸鍚屼竴鍧楃佺洏涔熷彲浠ュ湪涓嶅悓鐨勬満鍣ㄣ傚垎鍖哄悗錛岃〃闈涓婅繕鏄涓寮犺〃錛屼絾鏁版嵁鏁ｅ垪鍒板氫釜浣嶇疆浜嗐俛pp璇誨啓鐨勬椂鍊欐搷浣滅殑榪樻槸澶ц〃鍚嶅瓧錛宒b鑷鍔ㄥ幓緇勭粐鍒嗗尯鐨勬暟鎹銆
鍒嗗尯鐨勪富瑕佺洰鐨勬槸涓轟簡鍦ㄧ壒瀹氱殑SQL鎿嶄綔涓鍑忓皯鏁版嵁璇誨啓鐨勬婚噺浠ョ緝鍑忓搷搴旀椂闂淬

2.3 mysql鍒嗚〃鍜屽垎鍖烘湁浠涔堣仈緋誨憿錛

1錛夈侀兘鑳芥彁楂榤ysql鐨勬ц兘錛屽湪楂樺苟鍙戠姸鎬佷笅閮芥湁涓涓鑹濂界殑琛ㄧ幇銆
2錛夈佸垎琛ㄥ拰鍒嗗尯涓嶇煕鐩撅紝鍙浠ョ浉浜掗厤鍚堢殑錛屽逛簬閭ｄ簺澶ц塊棶閲忥紝騫朵笖琛ㄦ暟鎹姣旇緝澶氱殑琛錛屾垜浠鍙浠ラ噰鍙栧垎琛ㄥ拰鍒嗗尯緇撳悎鐨勬柟寮忥紝璁塊棶閲忎笉澶э紝浣嗘槸琛ㄦ暟鎹寰堝氱殑琛錛屾垜浠鍙浠ラ噰鍙栧垎鍖虹殑鏂瑰紡絳夈
3錛夈佸垎琛ㄦ妧鏈鏄姣旇緝楹葷儲鐨勶紝闇瑕佹墜鍔ㄥ幓鍒涘緩瀛愯〃錛宎pp鏈嶅姟絝璇誨啓鏃跺欓渶瑕佽＄畻瀛愯〃鍚嶃傞噰鐢╩erge濂戒竴浜涳紝浣嗕篃瑕佸壋寤哄瓙琛ㄥ拰閰嶇疆瀛愯〃闂寸殑union鍏崇郴銆
4錛夈佽〃鍒嗗尯鐩稿逛簬鍒嗚〃錛屾搷浣滄柟渚匡紝涓嶉渶瑕佸壋寤哄瓙琛ㄣ


3銆佸垎琛ㄧ殑鍑犵嶆柟寮

3.1 mysql闆嗙兢

瀹冨苟涓嶆槸鍒嗚〃錛屼絾璧峰埌浜嗗拰鍒嗚〃鐩稿悓鐨勪綔鐢ㄣ傞泦緹ゅ彲鍒嗘媴鏁版嵁搴撶殑鎿嶄綔嬈℃暟錛屽皢浠誨姟鍒嗘媴鍒板氬彴鏁版嵁搴撲笂銆傞泦緹ゅ彲浠ヨ誨啓鍒嗙伙紝鍑忓皯璇誨啓鍘嬪姏銆備粠鑰屾彁鍗囨暟鎹搴撴ц兘銆

3.2 鑷瀹氫箟瑙勫垯鍒嗚〃

澶ц〃鍙浠ユ寜鐓т笟鍔＄殑瑙勫垯鏉ュ垎瑙ｄ負澶氫釜瀛愯〃銆傞氬父涓轟互涓嬪嚑縐嶇被鍨嬶紝涔熷彲鑷宸卞畾涔夎勫垯銆

Range錛堣寖鍥達級_榪欑嶆ā寮忓厑璁稿皢鏁版嵁鍒掑垎涓嶅悓鑼冨洿銆備緥濡傚彲浠ュ皢涓涓琛ㄩ氳繃騫翠喚鍒掑垎鎴愯嫢騫蹭釜鍒嗗尯銆
Hash錛堝搱甯岋級_榪欎腑妯″紡鍏佽擱氳繃瀵硅〃鐨勪竴涓鎴栧氫釜鍒楃殑Hash Key榪涜岃＄畻錛屾渶鍚庨氳繃榪欎釜Hash鐮佷笉鍚屾暟鍊煎瑰簲鐨勬暟鎹鍖哄煙榪涜屽垎鍖恆備緥濡傚彲浠ュ緩絝嬩竴涓瀵硅〃涓婚敭榪涜屽垎鍖虹殑琛ㄣ
Key錛堥敭鍊礆級_涓婇潰Hash妯″紡鐨勪竴縐嶅歡浼革紝榪欓噷鐨凥ash Key鏄疢ySQL緋葷粺浜х敓鐨勩
List錛堥勫畾涔夊垪琛錛塤榪欑嶆ā寮忓厑璁哥郴緇熼氳繃棰勫畾涔夌殑鍒楄〃鐨勫兼潵瀵規暟鎹榪涜屽垎鍓層
Composite錛堝嶅悎妯″紡錛塤浠ヤ笂妯″紡鐨勭粍鍚堜嬌鐢


鍒嗚〃瑙勫垯涓庡垎鍖鴻勫垯涓鏍鳳紝鍦ㄥ垎鍖烘ā鍧楄︾粏浠嬬粛銆


涓嬮潰浠Range綆鍗曚粙緇嶄笅濡備綍鍒嗚〃錛堟寜鐓у勾浠借〃錛夈

鍋囪捐〃緇撴瀯鏈4涓瀛楁碉細鑷澧瀒d錛屽撳悕錛屽瓨嬈鵑噾棰濓紝瀛樻炬棩鏈
鎶婂瓨嬈炬棩鏈熶綔涓鴻勫垯鍒嗚〃錛屽垎鍒鍒涘緩鍑犱釜琛
2011騫達細account_2011
2012騫達細account_2012
??
2015騫達細account_2015
app鍦ㄨ誨啓鐨勬椂鍊欐牴鎹鏃ユ湡鏉ユ煡鎵懼瑰簲鐨勮〃鍚嶏紝闇瑕佹墜鍔ㄦ潵鍒ゅ畾銆

3.3 鍒╃敤merge瀛樺偍寮曟搸鏉ュ疄鐜板垎琛

merge鍒嗚〃錛屽垎涓轟富琛ㄥ拰瀛愯〃錛屼富琛ㄧ被浼間簬涓涓澹沖瓙錛岄昏緫涓婂皝瑁呬簡瀛愯〃錛屽疄闄呬笂鏁版嵁閮芥槸瀛樺偍鍦ㄥ瓙琛ㄤ腑鐨勩

鎴戜滑鍙浠ラ氳繃涓昏〃鎻掑叆鍜屾煡璇㈡暟鎹錛屽傛灉娓呮氬垎琛ㄨ勫緥錛屼篃鍙浠ョ洿鎺ユ搷浣滃瓙琛ㄣ

瀛愯〃2011騫

CREATE TABLE `account_2011` (
`id` int(11) NOT NULL AUTO_INCREMENT ,
`name` varchar(50) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL ,
`money` float NOT NULL ,
`tradeDate` datetime NOT NULL
PRIMARY KEY (`id`)
)
ENGINE=MyISAM
DEFAULT CHARACTER SET=utf8 COLLATE=utf8_general_ci
AUTO_INCREMENT=2
CHECKSUM=0
ROW_FORMAT=DYNAMIC
DELAY_KEY_WRITE=0
;
瀛愯〃2012騫

CREATE TABLE `account_2012` (
`id` int(11) NOT NULL AUTO_INCREMENT ,
`name` varchar(50) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL ,
`money` float NOT NULL ,
`tradeDate` datetime NOT NULL
PRIMARY KEY (`id`)
)
ENGINE=MyISAM
DEFAULT CHARACTER SET=utf8 COLLATE=utf8_general_ci
AUTO_INCREMENT=2
CHECKSUM=0
ROW_FORMAT=DYNAMIC
DELAY_KEY_WRITE=0
;
涓昏〃錛屾墍鏈夊勾

CREATE TABLE `account_all` (
`id` int(11) NOT NULL AUTO_INCREMENT ,
`name` varchar(50) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL ,
`money` float NOT NULL ,
`tradeDate` datetime NOT NULL
PRIMARY KEY (`id`)
)
ENGINE=MRG_MYISAM
DEFAULT CHARACTER SET=utf8 COLLATE=utf8_general_ci
UNION=(`account_2011`,`account_2012`)
INSERT_METHOD=LAST
ROW_FORMAT=DYNAMIC
;
鍒涘緩涓昏〃鐨勬椂鍊欐湁涓狪NSERT_METHOD錛屾寚鏄庢彃鍏ユ柟寮忥紝鍙栧煎彲浠ユ槸錛0 涓嶅厑璁告彃鍏ワ紱FIRST 鎻掑叆鍒癠NION涓鐨勭涓涓琛錛 LAST 鎻掑叆鍒癠NION涓鐨勬渶鍚庝竴涓琛ㄣ

閫氳繃涓昏〃鏌ヨ㈢殑鏃跺欙紝鐩稿綋浜庡皢鎵鏈夊瓙琛ㄥ悎鍦ㄤ竴璧鋒煡璇銆傝繖鏍峰苟涓嶈兘浣撶幇鍒嗚〃鐨勪紭鍔匡紝寤鴻榪樻槸鏌ヨ㈠瓙琛ㄣ

4銆佸垎鍖虹殑鍑犵嶆柟寮

4.1 Range

create table range(
id int(11),
money int(11) unsigned not null,
date datetime
)partition by range(year(date))(
partition p2007 values less than (2008),
partition p2008 values less than (2009),
partition p2009 values less than (2010)
partition p2010 values less than maxvalue
);
4.2 List

create table list(
a int(11),
b int(11)
)(partition by list (b)
partition p0 values in (1,3,5,7,9),
partition p1 values in (2,4,6,8,0)
);
4.3 Hash

create table hash(
a int(11),
b datetime
)partition by hash (YEAR(b)
partitions 4;
4.4 key

create table t_key(
a int(11),
b datetime)
partition by key (b)
partitions 4;
4.5 鍒嗗尯綆＄悊

4.5.1 鏂板炲垎鍖

ALTER TABLE sale_data
ADD PARTITION (PARTITION p201010 VALUES LESS THAN (201011));
4.5.2 鍒犻櫎鍒嗗尯

褰撳垹闄や簡涓涓鍒嗗尯錛屼篃鍚屾椂鍒犻櫎浜嗚ュ垎鍖轟腑鎵鏈夌殑鏁版嵁銆

ALTER TABLE sale_data DROP PARTITION p201010;
4.5.3 鍚堝苟鍒嗗尯

涓嬮潰鐨凷QL錛屽皢p201001 - p201009 鍚堝苟涓3涓鍒嗗尯p2010Q1 - p2010Q3

ALTER TABLE sale_data
REORGANIZE PARTITION p201001,p201002,p201003,
p201004,p201005,p201006,
p201007,p201008,p201009 INTO
(
PARTITION p2010Q1 VALUES LESS THAN (201004),
PARTITION p2010Q2 VALUES LESS THAN (201007),
PARTITION p2010Q3 VALUES LESS THAN (201010)
);

⑵ Mysql分表和分區的區別，分庫和分表區別

分表和分區的區別：

一、什麼是mysql分表，分區

分表：從表面意思上看呢，就是把一張表分成N多個小表，具體請看:mysql分表的3種方法

分區：分區呢就是把一張表的數據分成N多個區塊，這些區塊可以在同一個磁碟上，也可以在不同的磁碟上，具體請參考mysql分區功能詳細介紹，以及實例

二、mysql分表和分區有什麼區別呢

1、實現方式上
①mysql的分表是真正的分表，一張表分成很多表後，每一個小表都是完正的一張表，都對應三個文件，一個.MYD數據文件，.MYI索引文件，.frm表結構文件。

[root@BlackGhosttest]#ls|grepuser
alluser.MRG
alluser.frm
user1.MYD
user1.MYI
user1.frm
user2.MYD
user2.MYI
user2.frm

簡單說明一下，上面的分表呢是利用了merge存儲引擎（分表的一種），alluser是總表，下面有二個分表，user1，user2。他們二個都是獨立的表，取數據的時候，我們可以通過總表來取。這里總表是沒有.MYD,.MYI這二個文件的，也就是說，總表他不是一張表，沒有數據，數據都放在分表裡面。我們來看看.MRG到底是什麼東西

[root@BlackGhosttest]#catalluser.MRG|more
user1
user2
#INSERT_METHOD=LAST

從上面我們可以看出，alluser.MRG裡面就存了一些分表的關系，以及插入數據的方式。可以把總表理解成一個外殼，或者是聯接池。

②分區不一樣，一張大表進行分區後，他還是一張表，不會變成二張表，但是他存放數據的區塊變多了。

[root@BlackGhosttest]#ls|grepaa
aa#P#p1.MYD
aa#P#p1.MYI
aa#P#p3.MYD
aa#P#p3.MYI
aa.frm
aa.par

從上面我們可以看出，aa這張表，分為二個區，p1和p3，本來是三個區，被我刪了一個區。我們都知道一張表對應三個文件.MYD,.MYI,.frm。分 區呢根據一定的規則把數據文件和索引文件進行了分割，還多出了一個.par文件，打開.par文件後你可以看出他記錄了，這張表的分區信息，根分表中的.MRG有點像。分區後，還是一張，而不是多張表。
如orderid,userid,ordertime,.....
ordertime<2015-01-01 #p0
ordertime<2015-04-01 #p1
ordertime<2015-07-01 #p2
ordertime<2015-10-01 #p3
ordertime<2016-01-01 #p4
按照時間分區。大部分只查詢最近的訂單數據，那麼大部分只訪問一個分區，比整個表小多了，資料庫可以更加好的緩存，性能也提高了。這個是資料庫分的，應用程序透明，無需修改。

2，數據處理上
①、分表後，數據都是存放在分表裡，總表只是一個外殼，存取數據發生在一個一個的分表裡面。看下面的例子：

select * from alluser where id='12'表面上看，是對表alluser進行操作的，其實不是的。是對alluser裡面的分表進行了操作。

②、分區呢，不存在分表的概念，分區只不過把存放數據的文件分成了許多小塊，分區後的表呢，還是一張表。數據處理還是由自己來完成。

3、提高性能上

①、分表後，單表的並發能力提高了，磁碟I/O性能也提高了。並發能力為什麼提高了呢，因為查尋一次所花的時間變短了，如果出現高並發的話，總表可以根據不同 的查詢，將並發壓力分到不同的小表裡面。磁碟I/O性能怎麼搞高了呢，本來一個非常大的.MYD文件現在也分攤到各個小表的.MYD中去了。

②、mysql提出了分區的概念，我覺得就想突破磁碟I/O瓶頸，想提高磁碟的讀寫能力，來增加mysql性能。
在這一點上，分區和分表的測重點不同，分表重點是存取數據時，如何提高mysql並發能力上；而分區呢，如何突破磁碟的讀寫能力，從而達到提高mysql性能的目的。

4、實現的難易度上

①、分表的方法有很多，用merge來分表，是最簡單的一種方式。這種方式根分區難易度差不多，並且對程序代碼來說可以做到透明的。如果是用其他分表方式就比分區麻煩了。

②、分區實現是比較簡單的，建立分區表，根建平常的表沒什麼區別，並且對開代碼端來說是透明的。

三、mysql分表和分區有什麼聯系呢

1、都能提高mysql的性高，在高並發狀態下都有一個良好的表面。

2、分表和分區不矛盾，可以相互配合的，對於那些大訪問量，並且表數據比較多的表，我們可以採取分表和分區結合的方式（如果merge這種分表方式，不能和分區配合的話，可以用其他的分表試），訪問量不大，但是表數據很多的表，我們可以採取分區的方式等。

分庫分表區別：

1、什麼是分庫分表？

從字面上簡單理解，就是把原本存儲於一個庫的數據分塊存儲到多個庫上，把原本存儲於一個表的數據分塊存儲到多個表上。

2、為什麼要分庫分表？

資料庫中的數據量不一定是可控的，在未進行分庫分表的情況下，隨著時間和業務的發展，庫中的表會越來越多，表中的數據量也會越來越大，相應地，數據操作，增刪改查的開銷也會越來越大；另外，一台伺服器的資源（CPU、磁碟、內存、IO等）是有限的，最終資料庫所能承載的數據量、數據處理能力都將遭遇瓶頸,。

3、分庫分表的實施策略。
如果你的單機性能很低了，那可以嘗試分庫。分庫，業務透明，在物理實現上分成多個伺服器，不同的分庫在不同伺服器上。分區可以把表分到不同的硬碟上，但不能分配到不同伺服器上。一台機器的性能是有限制的，用分庫可以解決單台伺服器性能不夠，或者成本過高問題。
當分區之後，表還是很大，處理不過來，這時候可以用分庫。
orderid,userid,ordertime,.....
userid%4=0，用分庫1
userid%4=1，用分庫2
userid%4=2, 用分庫3
userid%4=3，用分庫4
上面這個就是一個簡單的分庫路由，根據userid選擇分庫，即不同的伺服器

分庫分表有垂直切分和水平切分兩種。
3.1、何謂垂直切分，即將表按照功能模塊、關系密切程度劃分出來，部署到不同的庫上。例如，我們會建立定義資料庫workDB、商品資料庫payDB、用戶資料庫userDB、日誌資料庫logDB等，分別用於存儲項目數據定義表、商品定義表、用戶數據表、日誌數據表等。

如userid,name,addr一個表，為了防止表過大，分成2個表。
userid,name
userid,addr

3.2、何謂水平切分，當一個表中的數據量過大時，我們可以把該表的數據按照某種規則，例如userID散列、按性別、按省，進行劃分，然後存儲到多個結構相同的表，和不同的庫上。

例如，我們的userDB中的用戶數據表中，每一個表的數據量都很大，就可以把userDB切分為結構相同的多個userDB：part0DB、part1DB等，再將userDB上的用戶數據表userTable，切分為很多userTable：userTable0、userTable1等，然後將這些表按照一定的規則存儲到多個userDB上。

3.3、應該使用哪一種方式來實施資料庫分庫分表，這要看資料庫中數據量的瓶頸所在，並綜合項目的業務類型進行考慮。

如果資料庫是因為表太多而造成海量數據，並且項目的各項業務邏輯劃分清晰、低耦合，那麼規則簡單明了、容易實施的垂直切分必是首選。

而如果資料庫中的表並不多，但單表的數據量很大、或數據熱度很高，這種情況之下就應該選擇水平切分，水平切分比垂直切分要復雜一些，它將原本邏輯上屬於一體的數據進行了物理分割，除了在分割時要對分割的粒度做好評估，考慮數據平均和負載平均，後期也將對項目人員及應用程序產生額外的數據管理負擔。

在現實項目中，往往是這兩種情況兼而有之，這就需要做出權衡，甚至既需要垂直切分，又需要水平切分。我們的游戲項目便綜合使用了垂直與水平切分，我們首先對資料庫進行垂直切分，然後，再針對一部分表，通常是用戶數據表，進行水平切分。

4 分庫分表存在的問題。

4.1 事務問題。

在執行分庫分表之後，由於數據存儲到了不同的庫上，資料庫事務管理出現了困難。如果依賴資料庫本身的分布式事務管理功能去執行事務，將付出高昂的性能代價；如果由應用程序去協助控制，形成程序邏輯上的事務，又會造成編程方面的負擔。

4.2 跨庫跨表的join問題。

在執行了分庫分表之後，難以避免會將原本邏輯關聯性很強的數據劃分到不同的表、不同的庫上，這時，表的關聯操作將受到限制，我們無法join位於不同分庫的表，也無法join分表粒度不同的表，結果原本一次查詢能夠完成的業務，可能需要多次查詢才能完成。

4.3 額外的數據管理負擔和數據運算壓力。

額外的數據管理負擔，最顯而易見的就是數據的定位問題和數據的增刪改查的重復執行問題，這些都可以通過應用程序解決，但必然引起額外的邏輯運算，例如，對於一個記錄用戶成績的用戶數據表userTable，業務要求查出成績最好的100位，在進行分表之前，只需一個order by語句就可以搞定，但是在進行分表之後，將需要n個order by語句，分別查出每一個分表的前100名用戶數據，然後再對這些數據進行合並計算，才能得出結果。

⑶ oracle分區表的分區有幾種類型

oracle分區表的分區有四種類型：范圍分區、散列分區、列表分區和復合分區。

特點如下：

1、范圍分區

就是根據資料庫表中某一欄位的值的范圍來劃分分區。

數據中有空值，Oracle機制會自動將其規劃到maxvalue的分區中。

2、散列分區

根據欄位的hash值進行均勻分布，盡可能地實現各分區所散列的數據相等。

散列分區即為哈希分區，Oracle採用哈希碼技術分區，具體分區如何由Oracle說的算，也可能我下一次搜索就不是這個數據了。

3、列表分區

列表分區明確指定了根據某欄位的某個具體值進行分區，而不是像范圍分區那樣根據欄位的值范圍來劃分的。

4、復合分區

根據范圍分區後，每個分區內的數據再散列地分布在幾個表空間中，這樣我們就要使用復合分區。復合分區是先使用范圍分區，然後在每個分區同再使用散列分區的一種分區方法。

比如將part_date的記錄按時間分區，然後每個分區中的數據分三個子分區，將數據散列地存儲在三個指定的表空間中。

(3)資料庫的分區表擴展閱讀：

分區的恢復方法：

如果資料庫運行在archive 模式下，那麼一旦資料庫損壞則可以通過冷備份(熱備份)和歸檔備份將資料庫恢復到斷點狀態。

資料庫控制文件恢復（假設所有控制文件均被破壞）：

資料庫基於文件系統： 利用操作系統的tar、cp等命令即可。

資料庫基於裸設備：dd if=$ORACLE_BASE/con.bak of=/dev/rdrd/drd1 seek=12

⑷ 璋堣皥鎬庝箞瀹炵幇Oracle鏁版嵁搴撳垎鍖鴻〃

Oracle鏁版嵁搴撳垎鍖烘槸浣滀負Oracle鏁版嵁搴撴ц兘浼樺寲鐨勪竴縐嶉噸瑕佺殑鎵嬫靛拰鏂規硶錛屽仛鎵嬪ご鐨勯」鐩浠ュ墠錛屽彧鑱嗗惉榪囧垎鍖虹殑澶у悕錛屾劅瑙夌壒紲炵橈紝鐪嬭



Oracle鏁版嵁搴撳垎鍖烘槸浣滀負Oracle鏁版嵁搴撴ц兘浼樺寲鐨勪竴縐嶉噸瑕佺殑鎵嬫靛拰鏂規硶錛屽仛鎵嬪ご鐨勯」鐩浠ュ墠錛屽彧鑱嗗惉榪囧垎鍖虹殑澶у悕錛屾劅瑙夌壒紲炵橈紝鐪嬭佹煇鏌愰珮鎵嬪湪璁ㄨ轟細涓婂じ澶稿叾璋堟椂錛岀湡鏄楠傝嚜宸卞﹁壓涓嶇簿錛屾渶榪戜綔GPS鏂歸潰鐨勯」鐩錛屽勭悊鐨勬暟鎹閲忚揪鍒頒簡鍑犲嶮GB錛屼負浜嗘弧瓚崇郴緇熺殑瀹炴椂鎬ц佹眰錛屽繀欏繪彁楂樻暟鎹鐨勬煡璇㈡晥鐜囷紝榪欐牱灝卞繀欏婚氳繃鍒嗗尯錛屼互瑙ｇ噧鐪変箣鎬ワ紒
鍏堣磋村垎鍖虹殑濂藉勫惂錛
1) 澧炲己鍙鐢ㄦэ細濡傛灉琛ㄧ殑鏌愪釜鍒嗗尯鍑虹幇鏁呴殰錛岃〃鍦ㄥ叾浠栧垎鍖虹殑鏁版嵁浠嶇劧鍙鐢錛
2) 緇存姢鏂逛究錛氬傛灉琛ㄧ殑鏌愪釜鍒嗗尯鍑虹幇鏁呴殰錛岄渶瑕佷慨澶嶆暟鎹錛屽彧淇澶嶈ュ垎鍖哄嵆鍙錛
3) 鍧囪I/O錛氬彲浠ユ妸涓嶅悓鐨勫垎鍖烘槧灝勫埌紓佺洏浠ュ鉤琛I/O錛屾敼鍠勬暣涓緋葷粺鎬ц兘錛
4) 鏀瑰杽鏌ヨ㈡ц兘錛氬瑰垎鍖哄硅薄鐨勬煡璇㈠彲浠ヤ粎鎼滅儲鑷宸卞叧蹇冪殑鍒嗗尯錛屾彁楂樻緔㈤熷害銆
Oracle鏁版嵁搴撴彁渚涘硅〃鎴栫儲寮曠殑鍒嗗尯鏂規硶鏈変笁縐嶏細
眉 鑼冨洿鍒嗗尯
眉 Hash鍒嗗尯錛堟暎鍒楀垎鍖猴級
眉 澶嶅悎鍒嗗尯
涓銆佽寖鍥村垎鍖鴻︾粏璇存槑
鑼冨洿鍒嗗尯灝辨槸瀵規暟鎹琛ㄤ腑鐨勬煇涓鍊肩殑鑼冨洿榪涜屽垎鍖猴紝鏍規嵁鏌愪釜鍊肩殑鑼冨洿錛屽喅瀹氬皢璇ユ暟鎹瀛樺偍鍦ㄥ摢涓鍒嗗尯涓娿傚傛牴鎹搴忓彿鍒嗗尯錛屾牴鎹鏃墮棿絳夋潵榪涜屽垎鍖恆傛牴鎹搴忓彿錛屾瘮濡傚皬浜2000000鐨勬斁鍦╬art01, 2000000~4000000鐨勬斁鍦╬art02銆傘
create table AAA
(
id number primary key,
indate date not null
)
partition by range(indate)
(
partition part_01 values less than(to_date(񟭆-01-01','yyyy-mm-dd')) tablespace space01,
partition part_02 values less than(to_date(񟭊-01-01','yyyy-mm-dd')) tablespace space02,
partition part_03 values less than(maxvalue) tablespace space03
);
space01 space02 space03涓哄緩絝嬬殑涓変釜琛ㄧ┖闂達紝鐩稿綋浜庢妸寤虹珛鐨勪竴涓澶х殑琛ㄥ垎鍦ㄤ簡3涓涓嶅悓鐨勮〃絀洪棿鐨勫垎鍖轟笂浜嗐
浜屻丠ash鍒嗗尯錛堟暎鍒楀垎鍖猴級璇︾粏璇存槑
鏁ｅ垪鍒嗗尯涓洪氳繃鎸囧畾鍒嗗尯緙栧彿鏉ュ潎鍖鍒嗗竷鏁版嵁鐨勪竴縐嶅垎鍖虹被鍨嬶紝鍥犱負閫氳繃鍦↖/O璁懼囦笂榪涜屾暎鍒楀垎鍖猴紝浣垮緱榪欎簺鍒嗗尯澶у皬涓鑷淬備篃灝辨槸鍙鍛藉悕鍒嗗尯鍚嶇О錛岃繖鏍峰潎鍖榪涜屾暟鎹鍒嗗竷銆
涓夈佸嶅悎鍒嗗尯璇︾粏璇存槑
鏈夋椂鍊欐垜浠闇瑕佹牴鎹鑼冨洿鍒嗗尯鍚庯紝姣忎釜鍒嗗尯鍐呯殑鏁版嵁鍐嶆暎鍒楀湴鍒嗗竷鍦ㄥ嚑涓琛ㄧ┖闂翠腑錛岃繖鏍鋒垜浠灝辮佷嬌鐢ㄥ嶅悎鍒嗗尯銆傚嶅悎鍒嗗尯鏄鍏堜嬌鐢ㄨ寖鍥村垎鍖猴紝鐒跺悗鍦ㄦ瘡涓鍒嗗尯鍐呭啀浣跨敤鏁ｅ垪鍒嗗尯鐨勪竴縐嶅垎鍖烘柟娉曘
partition by range(indate)subpartition by hash(id)
subpartitions 3 store in (space01, space02, space03)
(
partition part_01 values less than(to_date(鈥2006-01-01鈥,鈥檡yyy-mm-dd鈥)),
partition part_02 values less than(to_date(鈥2010-01-01鈥,鈥檡yyy-mm-dd鈥)),
partition part_03 values less than(maxvalue)
);
鍥涖佸垎鍖鴻〃鎿嶄綔
1銆佹彃鍏ヨ板綍錛歩nsert into AAA values(1 ,sysdate);
2銆佹煡璇㈠垎鍖鴻〃璁板綍錛歴elect * from AAA partition(part_01);
3銆佹洿鏂板垎鍖鴻〃鐨勮板綍錛歶pdate AAA partition(part_01) t set indate=鈥欌檞here id=1; 浣嗘槸褰撴洿鏂扮殑鏃跺欐寚瀹氫簡鍒嗗尯錛岃屾牴鎹鏌ヨ㈢殑璁板綍涓嶅湪璇ュ垎鍖轟腑鏃訛紝灝嗕笉浼氭洿鏂版暟鎹
4銆佸垹闄ゅ垎鍖鴻〃璁板綍錛歞elete from AAA partition(part_02) t where id=4; 濡傛灉鎸囧畾浜嗗垎鍖猴紝鑰屾潯浠朵腑鐨勬暟鎹鍙堜笉鍦ㄨュ垎鍖轟腑鏃訛紝灝嗕笉浼氬垹闄や換浣曟暟鎹銆
5銆佸炲姞涓涓鍒嗗尯錛歛lter table AAA add partition part_04 values less than(to_date(鈥2012-01-01鈥,鈥檡yyy-mm-dd鈥)) tablespace dinya_spa ce03; 澧炲姞涓涓鍒嗗尯鐨勬椂鍊欙紝錛屽炲姞鐨勫垎鍖虹殑鏉′歡蹇呴』澶т簬鐜版湁鍒嗗尯鐨勬渶澶у礆紝鍚﹀垯緋葷粺灝嗘彁紺篛RA-14074 partition bound must collate higher than that of the last partition 閿欒銆
6銆佸悎騫朵竴涓鍒嗗尯錛歛lter table AAA merge partitions part_01,part_02 into partition part_02; ,濡傛灉鍦ㄥ悎騫剁殑鏃跺欐妸鍚堝苟鍚庣殑鍒嗗尯瀹氫負part_01鐨勬椂鍊欙紝緋葷粺灝嗘彁紺篛RA-14275 cannot reuse lower-bound partition as resulting partition 閿欒銆
7銆佸垹闄ゅ垎鍖猴細alter table AAA drop partition part_01; 鍒犻櫎鍒嗗尯琛ㄧ殑涓涓鍒嗗尯鍚庯紝鏌ヨ㈣ヨ〃鐨勬暟鎹鏃舵樉紺猴紝璇ュ垎鍖轟腑鐨勬暟鎹宸插叏閮ㄤ涪澶憋紝鎵浠ユ墽琛屽垹闄ゅ垎鍖哄姩浣滄椂瑕佹厧閲嶏紝紜淇濆厛澶囦喚鏁版嵁鍚庡啀鎵ц岋紝鎴栧皢鍒嗗尯鍚堝苟銆
浜斻佸緩絝嬬儲寮
鍒嗗尯琛ㄥ拰涓鑸琛ㄤ竴鏍峰彲浠ュ緩絝嬬儲寮曪紝鍒嗗尯琛ㄥ彲浠ュ壋寤哄矓閮ㄧ儲寮曞拰鍏ㄥ矓緔㈠紩銆傚綋鍒嗗尯涓鍑虹幇璁稿氫簨鍔″苟涓旇佷繚璇佹墍鏈夊垎鍖轟腑鐨勬暟鎹璁板綍鐨勫敮涓鎬ф椂閲囩敤鍏ㄥ矓緔㈠紩銆
1. 灞閮ㄧ儲寮曞垎鍖虹殑寤虹珛錛歝reate index idx_t on AAA(id)
local
(
partition idx_1 tablespace space01,
partition idx_2 tablespace space02,
partition idx_3 tablespace space03
);
2. 鍏ㄥ矓緔㈠紩寤虹珛鏃秅lobal 瀛愬彞鍏佽告寚瀹氱儲寮曠殑鑼冨洿鍊礆紝榪欎釜鑼冨洿鍊間負緔㈠紩瀛楁電殑鑼冨洿鍊礆細create index idx_t on AAA(id)
global partition by range(id)
(
partition idx_1 values less than (1000) tablespace space01,
partition idx_2 values less than (10000) tablespace space02,
partition idx_3 values less than (maxvalue) tablespace space03
);
褰撶劧涔熷彲浠ヤ笉鎸囧畾緔㈠紩鍒嗗尯鍚嶇洿鎺ュ規暣涓琛ㄥ緩絝嬬儲寮: create index idx_t on AAA(id);

⑸ sqlserver中分表和分庫有什麼區別

MS SQL Server：分區表、分區索引 詳解

1. 分區表簡介
使用分區表的主要目的，是為了改善大型表以及具有各種訪問模式的表的可伸縮性和可管理性。

 大型表：數據量巨大的表。
 訪問模式：因目的不同，需訪問的不同的數據行集，每種目的的訪問可以稱之為一種訪問模式。

分區一方面可以將數據分為更小、更易管理的部分，為提高性能起到一定的作用；另一方面，對於如果具有多個CPU的系統，分區可以是對表的操作通過並行的方式進行，這對於提升性能是非常有幫助的。

注意：只能在 SQL Server Enterprise Edition 中創建分區函數。只有 SQL Server Enterprise Edition 支持分區。
2. 創建分區表或分區索引的步驟
可以分為以下步驟：
1. 確定分區列和分區數
2. 確定是否使用多個文件組
3. 創建分區函數
4. 創建分區架構（Schema）
5. 創建分區表
6. 創建分區索引

下面詳細描述的創建分區表、分區索引的步驟。
2.1. 確定分區列和分區數
在開始做分區操作之前，首先要確定待分區表的訪問模式，該模式決定了什麼列適合做分區鍵。例如，對於銷售數據，一般會先根據日期把數據范圍限定在一個范圍內，然後在這個基礎上做進一步的查詢，這樣，就可以把日期作為分區列。

確定了分區列之後，需要進一步確定分區數，亦即分區表中需要包含多少數據，每個分區的數據應該限定在哪個范圍。

2.2. 確定是否使用多個文件組
為了有助於優化性能和維護，應該使用文件組分離數據。一般情況下，如果經常對分區的整個數據集操作，則文件組數最好與分區數相同，並且這些文件組通常應該位於不同的磁碟上，再配合多個CPU，則SQL Server 可以並行處理多個分區，從而大大縮短處理大量復雜報表和分析的總體時間。

2.3. 創建分區函數
分區函數用於定義分區的邊界條件，創建分區函數的語法如下：
CREATE PARTITION FUNCTION partition_function_name ( input_parameter_type )
AS RANGE [ LEFT | RIGHT ]
FOR VALUES ( [ boundary_value [ ,...n ] ] )
[ ; ]

參數說明：
 partition_function_name
是分區函數的名稱。分區函數名稱在資料庫內必須唯一，並且符合標識符的規則。

 input_parameter_type
是用於分區的列的數據類型。當用作分區列時，除 text、ntext、image、xml、timestamp、varchar(max)、nvarchar(max)、varbinary(max)、別名數據類型或 CLR 用戶定義數據類型外，所有數據類型均有效。

實際列（也稱為分區列）是在 CREATE TABLE 或 CREATE INDEX 語句中指定的。

 boundary_value
為使用 partition_function_name 的已分區表或索引的每個分區指定邊界值。如果 boundary_value 為空，則分區函數使用 partition_function_name 將整個表或索引映射到單個分區。只能使用 CREATE TABLE 或 CREATE INDEX 語句中指定的一個分區列。

boundary_value 是可以引用變數的常量表達式。這包括用戶定義類型變數，或函數以及用戶定義函數。它不能引用 Transact-SQL 表達式。boundary_value 必須與 input_parameter_type 中提供的數據類型相匹配或者可隱式轉換為該數據類型，並且如果該值的大小和小數位數與 input_parameter_type 中相應的值的大小和小數位數不匹配，則在隱式轉換過程中該值不能被截斷。

注意：
如果 boundary_value 包含 datetime 或 smalldatetime 文字值，則為這些文字值在計算時假設 us_english 是會話語言。不推薦使用此行為。要確保分區函數定義對於所有會話語言都具有預期的行為，建議使用對於所有語言設置都以相同方式進行解釋的常量，例如 yyyymmdd 格式；或者將文字值顯式轉換為特定樣式。有關詳細信息，請參閱編寫國際化 Transact-SQL 語句。若要確定伺服器的語言會話，請運行 SELECT @@LANGUAGE。

 ...n
指定 boundary_value 提供的值的數目，不能超過 999。所創建的分區數等於 n + 1。不必按順序列出各值。如果值未按順序列出，則 Microsoft SQL Server 2005 資料庫引擎將對它們進行排序，創建函數並返回一個警告，說明未按順序提供值。如果 n 包括任何重復的值，則資料庫引擎將返回錯誤。

 LEFT | RIGHT
指定當間隔值由 資料庫引擎 按升序從左到右排序時，boundary_value [ ,...n ] 屬於每個邊界值間隔的哪一側（左側還是右側）。如果未指定，則默認值為 LEFT。

創建分區函數示例：
CREATE PARTITION FUNCTION PF_Left(int)
AS RANGE LEFT
FOR VALUES(10, 20)
GO

CREATE PARTITION FUNCTION PF_Right(int)
AS RANGE LEFT
FOR VALUES(10, 20)
GO

PF_Left 和 PF_Right 分區函數的區分：
分區函數 分區1 分區2 分區3
PF_Left <= 10 > 10 and <= 20 > 20
PF_Right < 10 >= 10 and < 20 >= 20

2.4. 創建分區架構（Schema）
創建分區函數後，必須將其與分區架構（Schema）相關聯，以便將分區定向至特定的文件組。定義分區架構師，即使多個分區位於同一個文件組中，也必須為每個分區指定一個文件組。

創建分區架構的語法如下：
GOCREATE PARTITION SCHEME partition_scheme_name
AS PARTITION partition_function_name
[ ALL ] TO ( { file_group_name | [ PRIMARY ] } [ ,...n ] )
[ ; ]

參數：
 partition_scheme_name
分區方案的名稱。分區方案名稱在資料庫中必須是唯一的，並且符合標識符規則。

 partition_function_name
使用分區方案的分區函數的名稱。分區函數所創建的分區將映射到在分區方案中指定的文件組。partition_function_name 必須已經存在於資料庫中。

 ALL
指定所有分區都映射到在 file_group_name 中提供的文件組，或映射到主文件組（如果指定了 [PRIMARY]。如果指定了 ALL，則只能指定一個 file_group_name。

 file_group_name | [ PRIMARY ] [ ,...n]
指定用來持有由 partition_function_name 指定的分區的文件組的名稱。file_group_name 必須已經存在於資料庫中。

如果指定了 [PRIMARY]，則分區將存儲於主文件組中。如果指定了 ALL，則只能指定一個 file_group_name。分區分配到文件組的順序是從分區 1 開始，按文件組在 [,...n] 中列出的順序進行分配。在 [,...n] 中，可以多次指定同一個 file_group_name。如果 n 不足以擁有在 partition_function_name 中指定的分區數，則 CREATE PARTITION SCHEME 將失敗，並返回錯誤。

如果 partition_function_name 生成的分區數少於文件組數，則第一個未分配的文件組將標記為 NEXT USED，並且出現顯示命名 NEXT USED 文件組的信息。如果指定了 ALL，則單獨的 file_group_name 將為該 partition_function_name 保持它的 NEXT USED 屬性。如果在 ALTER PARTITION FUNCTION 語句中創建了一個分區，則 NEXT USED 文件組將再接收一個分區。若要再創建一個未分配的文件組來擁有新的分區，請使用 ALTER PARTITION SCHEME。

在 file_group_name[ 1,...n] 中指定主文件組時，必須像在 [PRIMARY] 中那樣分隔 PRIMARY，因為它是關鍵字。

創建分區架構示例：
CREATE PARTITION FUNCTION myRangePF1 (int)
AS RANGE LEFT FOR VALUES (1, 100, 1000);
GO
CREATE PARTITION SCHEME myRangePS1
AS PARTITION myRangePF1
TO (test1fg, test2fg, test3fg, test4fg);
GO

2.5. 創建分區表
定義了分區函數（邏輯結構）和分區架構（物理結構）後，既可以創建分區表來利用它們。分區表定義應使用的分區架構，而分區架構又定義其使用的分區函數。要將這三者結合起來，必須指定應用於分區函數的列 。范圍分區始終只映射到表中的一列。

CREATE TABLE 語法如下：
CREATE TABLE
[ database_name . [ schema_name ] . | schema_name . ] table_name
( { <column_definition> | <computed_column_definition> }
[ <table_constraint> ] [ ,...n ] )
[ ON { partition_scheme_name ( partition_column_name ) | filegroup
| "default" } ]
[ { TEXTIMAGE_ON { filegroup | "default" } ]
[ ; ]

示例如下：
CREATE TABLE myRangePT1
(
ID int not null,
AGE int,
PRIMARY KEY (ID)
) ON myRangePS1(myRangePF1)
GO

2.6. 創建分區索引
索引對於提高查詢性能非常有效，因此，一般應該考慮應該考慮為分區表建立索引，為分區表建立索引與為普通表建立索引的語法一直，但是，其行為與普通索引有所差異。

默認情況下，分區表中創建的索引使用與分區表相同分區架構和分區列，這樣，索引將於表對齊。將表與其索引對齊，可以使管理工作更容易進行，對於滑動窗口方案尤其如此。若要啟動分區切換，表的所有索引都必須對齊。

在創建索引時，也可以指定不同的分區方案（Schema）或單獨的文件組（FileGroup）來存儲索引，這樣SQL Server 不會將索引與表對齊。

在已分區的表上創建索引（分區索引）時，應該注意以下事項：
 唯一索引
建立唯一索引（聚集或者非聚集）時，分區列必須出現在索引列中。此限制將使SQL Server只調查單個分區，並確保表中寵物的新鍵值。如果分區依據列不可能包含在唯一鍵中，則必須使用DML觸發器，而不是強制實現唯一性。

 非唯一索引
對非唯一的聚集索引進行分區時，如果未在聚集鍵中明確指定分區依據列，默認情況下SQL Server 將在聚集索引列中添加分區依據列。
對非唯一的非聚集索引進行分區時，默認情況下SQL Server 將分區依據列添加為索引的包含性列，以確保索引與基表對齊，若果索引中已經存在分區依據列，SQL Server 將不會像索引中添加分區依據列。

3. 分區操作
分區適用於可以縮放的大型表，所以隨著時間和環境的變化，就會產生對分區的拆分、合並、移動的需求。
3.1. 拆分與合並分區
通過拆分或合並邊界值更改分區函數。通過執行 ALTER PARTITION FUNCTION，可以將使用分區函數的任何錶或索引的某個分區拆分為兩個分區，也可以將兩個分區合並為一個分區。

注意：多個表或索引可以使用同一分區函數。ALTER PARTITION FUNCTION 在單個事務中影響所有這些表或索引。

ALTER PARTITION FUNCTION 語法如下：
ALTER PARTITION FUNCTION partition_function_name()
{
SPLIT RANGE ( boundary_value )
| MERGE RANGE ( boundary_value )
} [ ; ]

參數說明：
 partition_function_name
要修改的分區函數的名稱。

 SPLIT RANGE ( boundary_value )
在分區函數中添加一個分區。boundary_value 確定新分區的范圍，因此它必須不同於分區函數的現有邊界范圍。根據 boundary_value，Microsoft SQL Server 2005 資料庫引擎將某個現有范圍拆分為兩個范圍。在這兩個范圍中，新 boundary_value 所在的范圍被視為是新分區。

重要提示：
文件組必須處於聯機狀態，並且必須由使用此分區函數的分區方案標記為 NEXT USED，以保存新分區。在 CREATE PARTITION SCHEME 語句中，將把文件組分配給分區。如果 CREATE PARTITION SCHEME 語句分配了多餘的文件組（在 CREATE PARTITION FUNCTION 語句中創建的分區數少於用於保存它們的文件組），則存在未分配的文件組，分區方案將把其中的某個文件組標記為 NEXT USED。該文件組將保存新的分區。如果分區方案未將任何文件組標記為 NEXT USED，則必須使用 ALTER PARTITION SCHEME 添加一個文件組或指定一個現有文件組來保存新分區。可以指定已保存分區的文件組來保存附加分區。由於一個分區函數可以參與多個分區方案，因此所有使用分區函數（您向其中添加了分區）的分區方案都必須擁有一個 NEXT USED 文件組。否則，ALTER PARTITION FUNCTION 將失敗並出現錯誤，該錯誤顯示缺少 NEXT USED 文件組的一個或多個分區方案。

 MERGE [ RANGE ( boundary_value) ]
刪除一個分區並將該分區中存在的所有值都合並到剩餘的某個分區中。RANGE (boundary_value) 必須是一個現有邊界值，已刪除分區中的值將合並到該值中。如果最初保存 boundary_value 的文件組沒有被剩餘分區使用，也沒有使用 NEXT USED 屬性進行標記，則將從分區方案中刪除該文件組。合並的分區駐留在最初不保存 boundary_value 的文件組中。boundary_value 是一個可以引用變數（包括用戶定義類型變數）或函數（包括用戶定義函數）的常量表達式。它無法引用 Transact-SQL 表達式。boundary_value 必須匹配或可以隱式轉換為其對應列的數據類型，並且當值的大小和小數位數不匹配其對應 input_parameter_type 時，將無法在隱式轉換過程中被截斷。

⑹ 資料庫分區和分表的區別

分區、分表、分庫的詳細理解
一、什麼是分區、分表、分庫
分區
就是把一張表的數據分成N個區塊，在邏輯上看最終只是一張表，但底層是由N個物理區塊組成的

分表
就是把一張表按一定的規則分解成N個具有獨立存儲空間的實體表。系統讀寫時需要根據定義好的規則得到對應的字表明，然後操作它。

分庫
一旦分表，一個庫中的表會越來越多

將整個資料庫比作圖書館，一張表就是一本書。當要在一本書中查找某項內容時，如果不分章節，查找的效率將會下降。而同理，在資料庫中就是分區。

二、常用的單機資料庫的瓶頸
問題描述
單個表數據量越大，讀寫鎖，插入操作重新建立索引效率越低。
單個庫數據量太大（一個資料庫數據量到就是極限）
單個資料庫伺服器壓力過大
讀寫速度遇到瓶頸（並發量幾百）
三、分區
什麼時候考慮使用分區？
一張表的查詢速度已經慢到影響使用的時候。

sql經過優化

數據量大

表中的數據是分段的
對數據的操作往往只涉及一部分數據，而不是所有的數據

分區解決的問題
主要可以提升查詢效率

分區的實現方式（簡單）
mysql5 開始支持分區功能

四、分表
什麼時候考慮分表？
一張表的查詢速度已經慢到影響使用的時候。

sql經過優化

數據量大
當頻繁插入或者聯合查詢時，速度變慢

分表解決的問題
分表後，單表的並發能力提高了，磁碟I/O性能也提高了，寫操作效率提高了

查詢一次的時間短了
數據分布在不同的文件，磁碟I/O性能提高
讀寫鎖影響的數據量變小
插入資料庫需要重新建立索引的數據減少
分表的實現方式（復雜）
需要業務系統配合遷移升級，工作量較大

分區和分表的區別與聯系
分區和分表的目的都是減少資料庫的負擔，提高表的增刪改查效率。

分區只是一張表中的數據的存儲位置發生改變，分表是將一張表分成多張表。
當訪問量大，且表數據比較大時，兩種方式可以互相配合使用。
當訪問量不大，但表數據比較多時，可以只進行分區。

常見分區分表的規則策略（類似）
Range（范圍）
Hash（哈希）
按照時間拆分
Hash之後按照分表個數取模
在認證庫中保存資料庫配置，就是建立一個DB，這個DB單獨保存user_id到DB的映射關系

⑺ mysql表分區使用及詳細介紹

一、分區概念

分區是將一個表分成多個區塊進行操作和保存，從而降低每次操作的數據，提高性能。而對於應用來說則是透明的，從邏輯上看只有一張表，但在物理上這個表可能是由多個物理分區組成的，每個分區都是獨立的對象，可以進行獨立處理。

二、分區作用

1.可以邏輯數據分割，分割數據能夠有多個不同的物理文件路徑。

2.可以存儲更多的數據，突破系統單個文件最大限制。

3.提升性能，提高每個分區的讀寫速度，提高分區范圍查詢的速度。

4.可以通過刪除相關分區來快速刪除數據

5.通過跨多個磁碟來分散數據查詢，從而提高磁碟I/O的性能。

6.涉及到例如SUM()、COUNT()這樣聚合函數的查詢，可以很容易的進行並行處理。

7.可以備份和恢復獨立的分區，這對大數據量很有好處。

三、分區能支持的引擎

MySQL支持大部分引擎創建分區，入MyISAM、InnoDB等；不支持MERGE和CSV等來創建分區。同一個分區表中的所有分區必須是同一個存儲引擎。值得注意的是，在MySQL8版本中，MyISAM表引擎不支持分區。

四、確認MySQL支持分區

從MySQL5.1開始引入分區功能，可以如下方式查看是否支持：

老版本用：SHOW VARIABLES LIKE '%partition%'

新版本用：show plugins;

五、分區類型

1. RANGE分區：基於屬於一個給定連續區間的列值，把多行分配給分區。

例如，可以將一個表通過年份劃分成兩個分區，2001 -2010年、2011-2020。

2. LIST分區：類似於RANGE分區，LIST是列值匹配一個離散值集合中的某個值來進行選擇。

比如 根據欄位 把值為1、3、5的放到一起，2、4、6的另外放到一起 等等...

3. HASH分區：基於用戶定義的表達式的返回值來進行選擇分區，該表達式使用將要插入到表中的這些行的列值來進行計算，這個函數必須產生非負整數值。

通過HASH運算來進行分區，分布的比較均勻

4. KEY分區：類似於按HASH分區，由MySQL伺服器提供其自身的哈希函數。

按照KEY進行分區類似於按照HASH分區

六、分區創建注意事項

1. 如果表中存在primary key 或者 unique key 時，分區的列必須是paimary key或者unique key的一個組成部分，也就是說，分區函數的列只能從pk或者uk這些key中取子集

2. 如果表中不存在任何的paimary key或者unique key，則可以指定任何一個列作為分區列

3. 5.5版本前的RANGE、LIST、HASH分區要求分區鍵必須是int；MySQL5.5及以上，支持非整形的RANGE和LIST分區，即：range columns 和 list columns (可以用字元串來進行分區)。

七、分區命名

1. 分區的名字基本上遵循其他MySQL 標識符應當遵循的原則，例如用於表和資料庫名字的標識符。應當注意的是， 分區的名字是不區分大小寫的 。

2. 無論使用何種類型的分區，分區總是在創建時就自動的順序編號，且從0開始記錄。

八、 創建分區

1. RANGE分區：

CREATE TABLE `test01` (

`dayid` int(11) DEFAULT NULL,

`mac` varchar(32) NOT NULL DEFAULT '',

`dtype` varchar(50) NOT NULL DEFAULT ''

) ENGINE=InnoDB DEFAULT CHARSET=utf8

/*!50100 PARTITION BY LIST (dayid)

(PARTITION p20171205 VALUES IN (20171205) ENGINE = InnoDB,

PARTITION p20171204 VALUES IN (20171204) ENGINE = InnoDB,

PARTITION p20171206 VALUES IN (20171206) ENGINE = InnoDB,

PARTITION p20171207 VALUES IN (20171207) ENGINE = InnoDB) */

解讀：以上為 uuid小於5時放到p0分區下，uuid大於5且小於10放到p1分區下，uuid大於10且小於15放到p2分區下，uuid大於15 一直到最大值的存在p3分區下

2. LIST分區：

CREATE TABLE tbl_test (

uuid INT NOT NULL,

title VARCHAR(20)

)

)

PARTITION BY List (uuid) (

PARTITION p0 VALUES in (1,2,3,5),

PARTITION p1 VALUES in (7,9,10),

PARTITION p2 VALUES in (11,15)

)

);

解讀：以上為uuid 等於1/2/3/5時放到p0分區，7/9/10放到p1分區，11/15放到p2分區。當時用insert into時 如果uuid的值不存在p0/p1/p2分區時，則會插入失敗而報錯。

3. HASH分區:

HASH分區主要用來確保數據在預先確定數目的分區中平均分布。在RANGE分區和LIST分區中必須明確指定一個指定的列值或列值集合以指定應該保存在哪個分區中。而在HASH分區中，MySQL會自動完成這些工作，要做的只是基於將要被哈希的列值指定一個表達式，以及指定被分區的表將要被分割成的分區數量，如：

CREATE TABLE tbl_test (

uuid INT NOT NULL,

title VARCHAR(20)

))

PARTITION BY HASH (uuid) (

PARTITIONS 3

));

解讀：MySQL自動創建3個分區，在執行insert into時，根據插入的uuid通過演算法來自動分配區間。

注意：

(1) 由於每次插入、更新、刪除一行，這個表達式都要計算一次，這意味著非常復雜的表達式可能會引起性能問題，尤其是在執行同時影響大量行的運算（例如批量插入）的時候。

(2) 最有效率的哈希函數是只對單個表列進行計算，並且它的值隨列值進行一致的增大或減小，因為這考慮了在分區范圍上的「修剪」。也就是說，表達式值和它所基於的列的值變化越接近，就越能有效地使用該表達式來進行HASH分區。

3.1：線性HASH分區

線性HASH分區在「PARTITION BY」子句中添加「LINEAR」關鍵字。

線性HASH分區的有點在於增加、刪除、合並和拆分分區將變得更加快捷，有利於處理含有及其大量數據的表。它的缺點在於各個分區間數據的分布不大可能均衡。

4. KEY分區

類似於HASH分區，HASH分區允許用戶自定義的表達式，而KEY分區則不允許使用用戶自定義的表達式；HASH分區只支持整數分區，KEY分區支持除了blob和text類型之外的其他數據類型分區。

與HASH分區不同，創建KEY分區表的時候，可以不指定分區鍵，默認會選擇使用主鍵或唯一鍵作為分區鍵，沒有主鍵或唯一鍵，就必須指定分區鍵。

CREATE TABLE tbl_test (

uuid INT NOT NULL,

title VARCHAR(20)

))

PARTITION BY LINEAR Key (uuid)

PARTITIONS 3;

解讀：根據分區鍵來進行分區

5. 子分區

子分區是分區表中，每個分區的再次分割，適合保存非常大量的數據。

CREATE TABLE tbl_test (

registerTime Date

))

PARTITION BY GANGE(YEAR(registerTime))

SUBPARTITION BY HASH (TO_DAYS(registerTime))

SUBPARTITIONS 2

(

PARTITION p0 VALUES LESS THAN (2017),

PARTITION p1 VALUES LESS THAN (2020),

PARTITION p2 VALUES LESS THAN MAXVALUE

);

解讀：主分區使用RANGE按照年來進行分區，有3個RANGE分區。這3個分區中又被進一步分成了2個子分區，實際上，整個表被分成了3 * 2 = 6個分區。每個子分區按照天進行HASH分區。小於2017的放在一起，2017-2020的放在一起，大於2020的放在一起。

注意：

(1) 在MySQL5.1中，對於已經通過RANGE或LIST分區了的表在進行子分區是可能的。子分區既可以使用HASH分區，也可以使用KEY分區。這也被稱為復合分區。

(2) 每個分區必須有相同數量的子分區。

(3) 如果在一個分區表上的任何分區上使用SUBPARTITION來明確定義任何子分區，那麼就必須定義所有的子分區。

(4) 每個SUBPARTITION子句必須包含（至少）子分區的一個名字。

(5) 在每個子分區內，子分區的名字必須是惟一的，目前在整個表中，也要保持唯一。例如：

PARTITION BY RANGE(YEAR(registerTime))

SUBPARTITION BY HASH(TO_DAYS(registerTime))

(

PARTITION p0 VALUES LESS THAN (2017) (

SUBPARTITION s0,

SUBPARTITION s1

),

PARTITION p1 VALUES LESS THAN (2020) (

SUBPARTITION s2,

SUBPARTITION s3

),

PARTITION p2 VALUES LESS THAN MAXVALUE (

SUBPARTITION s4,

SUBPARTITION s5

)

)

子分區可以用於特別大的表，可以在多個磁碟間分配數據和索引。例如：

SUBPARTITION s0

DATA DIRECTORY = '/disk0/data'

INDEX DIRECTORY = '/disk0/idx'

,

,

SUBPARTITION s1

DATA DIRECTORY = '/disk1/data'

INDEX DIRECTORY = '/disk1/idx'

九、MySQL分區處理NULL值的方式

MySQL中的分區禁止空值NULL上沒有進行處理，無論它是一個列值還是一個用戶定義表達式的值，一般而言，在這種情況下MySQL把NULL視為0。如果你希望迴避這種做法，你應該在設計表時聲明列「NOT NULL」。

十、分區管理概述

可以對分區進行添加、刪除、重新定義、合並或拆分等管理操作。

① RANGE和LIST分區的管理

1. 刪除分區語句如：alter table tbl_test drop partition p0;

注意：

(1) 當刪除了一個分區，也同時刪除了該分區中所有的數據。

(2) 可以通過show create table tbl_test;來查看新的創建表的語句。

(3) 如果是LIST分區的話，刪除的數據不能新增進來，因為這些行的列值包含在已經刪除了的分區的值列表中。

2. 添加分區語句如：alter table tbl_test add partition(partition p3 values less than(50));

注意：

(1) 對於RANGE分區的表，只可以添加新的分區到分區列表的最高端。

(2) 對於LIST分區的表，不能添加已經包含在現有分區值列表中的任意值。

3. 如果希望能不丟失數據的條件下重新定義分區，可以使用如下語句：

ALTER TABLE tbl_name REORGANIZE PARTITION partition_list INTO(partition_definitions)

(1) 拆分分區如：

ALTER TABLE tbl_name REORGANIZE PARTITION partition_list INTO(partition s0 values less than(5),partition s1 values less than(10));

或者如：

ALTER TABLE tbl_name REORGANIZE PARTITION p0 INTO(partition s0 values in(1,2,3), partition s1 values in(4,5));

(2) 合並分區如：ALTER TABLE tbl_name REORGANIZE PARTITION s0,s1 INTO(partition p0 values in(1,2,3,4,5));

4. 刪除所有分區，但保留數據，形式：ALTER TABLE tbl_name remove partitioning;

② HASH和KEY分區的管理

1. 減少分區數量語句如：ALTER TABLE tbl_name COALESCE PARTITION 2;

2. 添加分區數量語句如：ALTER TABLE tbl_name add PARTITION partitions 2;

③ 其他分區管理語句

1. 重建分區 ：類似於先刪除保存在分區中的所有記錄，然後重新插入它們，可用於整理分區碎片。如：ALTER table tbl_name REBUILD PARTITION p2,p3;

2. 優化分區 ：如果從分區中刪除了大量的行，或者對一個帶有可變長度的行（也就是說，有VARCHAR，BLOB或TEXT類型的列）做了許多修改，可以使用 ALTER TABLE tbl_name OPTIMIZE PARTITION來收回沒有使用的空間，並整理分區數據文件的碎片。如：ALTER TABLE tbl_name OPTIMIZE PARTITION p2,p3;

3. 分析分區 ：讀取並保存分區的鍵分布，如：ALTER TABLE tbl_name ANALYZE PARTITION p2,p3;

4. 檢查分區 ：檢查分區中的數據或索引是否已經被破壞，如：ALTER TABLE tbl_name CHECK PARTITION p2,p3;

5. 修補分區 ：修補被破壞的分區，如：ALTER TABLE tbl_name REPAIR PARTITION p2,p3;

十、查看分區信息

1. 查看分區信息：select * from information_schema.partitions where table_schema='arch1' and table_name = 'tbl_test' G;

2. 查看分區上的數據：select * from tbl_test partition(p0);

3. 查看MySQL會操作的分區：explain partitions select * from tbl_test where uuid = 2;

十一、 局限性

1. 最大分區數目不能超過1024，一般建議對單表的分區數不要超過50個。

2. 如果含有唯一索引或者主鍵，則分區列必須包含在所有的唯一索引或者主鍵在內。

3. 不支持外鍵。

4. 不支持全文索引，對分區表的分區鍵創建索引，那麼這個索引也將被分區。

5. 按日期進行分區很合適，因為很多日期函數可以用。但是對字元串來說合適的分區函數不太多。

6. 只有RANGE和LIST分區能進行子分區，HASH和KEY分區不能進行子分區。

7. 臨時表不能被分區。

8. 分區表對於單條記錄的查詢沒有優勢。

9. 要注意選擇分區的成本，沒插入一行數據都需要按照表達式篩選插入的分區。

10. 分區欄位盡量不要可以為null