数据库存储与分区

⑴ 数据库分区的分类

分区主要有两种形式：//这里一定要注意行和列的概念（row是行，column是列）
水平分区（Horizontal Partitioning）
这种形式分区是对表的行进行分区，通过这样的方式不同分组里面的物理列分割的数据集得以组合，从而进行个体分割（单分区）或集体分割（1个或多个分区）。所有在表中定义的列在每个数据集中都能找到，所以表的特性依然得以保持。
举个简单例子：一个包含十年发票记录的表可以被分区为十个不同的分区，每个分区包含的是其中一年的记录。（朋奕注：这里具体使用的分区方式我们后面再说，可以先说一点，一定要通过某个属性列来分割，譬如这里使用的列就是年份）
垂直分区（Vertical Partitioning）
这种分区方式一般来说是通过对表的垂直划分来减少目标表的宽度，使某些特定的列被划分到特定的分区，每个分区都包含了其中的列所对应的行。
举个简单例子：一个包含了大text和BLOB列的表，这些text和BLOB列又不经常被访问，这时候就要把这些不经常使用的text和BLOB了划分到另一个分区，在保证它们数据相关性的同时还能提高访问速度。
在数据库供应商开始在他们的数据库引擎中建立分区（主要是水平分区）时，DBA和建模者必须设计好表的物理分区结构，不要保存冗余的数据（不同表中同时都包含父表中的数据）或相互联结成一个逻辑父对象（通常是视图）。这种做法会使水平分区的大部分功能失效，有时候也会对垂直分区产生影响。

⑵ 浠涔堟槸鍒呜〃鍜屽垎鍖篗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)
);

⑶ 数据库分区和分表的区别

分区、分表、分库的详细理解
一、什么是分区、分表、分库
分区
就是把一张表的数据分成N个区块，在逻辑上看最终只是一张表，但底层是由N个物理区块组成的

分表
就是把一张表按一定的规则分解成N个具有独立存储空间的实体表。系统读写时需要根据定义好的规则得到对应的字表明，然后操作它。

分库
一旦分表，一个库中的表会越来越多

将整个数据库比作图书馆，一张表就是一本书。当要在一本书中查找某项内容时，如果不分章节，查找的效率将会下降。而同理，在数据库中就是分区。

二、常用的单机数据库的瓶颈
问题描述
单个表数据量越大，读写锁，插入操作重新建立索引效率越低。
单个库数据量太大（一个数据库数据量到就是极限）
单个数据库服务器压力过大
读写速度遇到瓶颈（并发量几百）
三、分区
什么时候考虑使用分区？
一张表的查询速度已经慢到影响使用的时候。

sql经过优化

数据量大

表中的数据是分段的
对数据的操作往往只涉及一部分数据，而不是所有的数据

分区解决的问题
主要可以提升查询效率

分区的实现方式（简单）
mysql5 开始支持分区功能

四、分表
什么时候考虑分表？
一张表的查询速度已经慢到影响使用的时候。

sql经过优化

数据量大
当频繁插入或者联合查询时，速度变慢

分表解决的问题
分表后，单表的并发能力提高了，磁盘I/O性能也提高了，写操作效率提高了

查询一次的时间短了
数据分布在不同的文件，磁盘I/O性能提高
读写锁影响的数据量变小
插入数据库需要重新建立索引的数据减少
分表的实现方式（复杂）
需要业务系统配合迁移升级，工作量较大

分区和分表的区别与联系
分区和分表的目的都是减少数据库的负担，提高表的增删改查效率。

分区只是一张表中的数据的存储位置发生改变，分表是将一张表分成多张表。
当访问量大，且表数据比较大时，两种方式可以互相配合使用。
当访问量不大，但表数据比较多时，可以只进行分区。

常见分区分表的规则策略（类似）
Range（范围）
Hash（哈希）
按照时间拆分
Hash之后按照分表个数取模
在认证库中保存数据库配置，就是建立一个DB，这个DB单独保存user_id到DB的映射关系

⑷ 什么是数据库部署什么又是数据库分区的部署分区的管理、操作、恢复又是什么大概说一下就好

分区存储提高了数据库的性能，被分区存储的数据物理上是多个文件，但逻辑上任然是一个表，对表的任何操作都跟没分区之前一样。插入、删除、查询、更新等操作的时候，数据库会自动为你找到对应的分区，然后执行操作。另外的话 把多个数据文件、日志文件都分别部署在不同的高性能物理盘上，也能大大提高性能.

⑸ 数据库为什么要分库分表

1 基本思想之什么是分库分表？
从字面上简单理解，就是把原本存储于一个库的数据分块存储到多个库上，把原本存储于一个表的数据分块存储到多个表上。
2 基本思想之为什么要分库分表？

数
据库中的数据量不一定是可控的，在未进行分库分表的情况下，随着时间和业务的发展，库中的表会越来越多，表中的数据量也会越来越大，相应地，数据操作，增
删改查的开销也会越来越大；另外，由于无法进行分布式式部署，而一台服务器的资源（CPU、磁盘、内存、IO等）是有限的，最终数据库所能承载的数据量、
数据处理能力都将遭遇瓶颈。
3 分库分表的实施策略。

分库分表有垂直切分和水平切分两种。
3.1
何谓垂直切分，即将表按照功能模块、关系密切程度划分出来，部署到不同的库上。例如，我们会建立定义数据库workDB、商品数据库payDB、用户数据
库userDB、日志数据库logDB等，分别用于存储项目数据定义表、商品定义表、用户数据表、日志数据表等。
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名用户数据，然后再对这些数据进行合并计算，才能得出结果。