脚本宝典收集整理的这篇文章主要介绍了基于MySQL分区性能的详细介绍，脚本宝典觉得挺不错的，现在分享给大家，也给大家做个参考。

一，

分区概念

分区允许根据指定的规则，跨文件系统分配单个表的多个部分。表的不同部分在不同的位置被存储为单独的表。MysqL从5.1.3开始支持PartITion。

分区和手动分表对比

手动分表

分区

多张数据表 一张数据表 重复数据的风险 没有数据重复的风险 写入多张表 写入一张表 没有统一的约束限制 强制的约束限制

MysqL支持RANGE，LIST，HASH，KEY分区类型，其中以RANGE最为常用：

一个表通过年份划分成若干个分区。

一个或多个列的Hash Key进行计算，最后通过这个Hash码不同数值对应的数据区域进行分区。例如可以建立一个对表主键进行分区的表。

MysqL系统产生的。

二，分区能做什么

查询的速度

文件路径

一个表上的约束检查

三，分区的限制

(

截止

5.1.44

版

)

• 只能对数据表的整型列进行分区，或者数据列可以通过分区函数转化成整型列

• 最大分区数目不能超过1024

• 如果含有唯一索引或者主键，则分区列必须包含在所有的唯一索引或者主键在内

• 不支持外键

• 不支持全文索引（fulltext）

函数可以用。但是对于字符串来说合适的分区函数不太多

四，什么时候使用分区

• 海量数据表

• 历史表快速的查询，可以采用ArchIVE+PARTITION的方式。

• 数据表索引大于服务器有效内存

• 对于大表，特别是索引远远大于服务器有效内存时，可以不用索引，此时分区效率会更有效。

五，分区实验

实验一：

使用 US Bureau of Transportation statistics发布的数据(CSV格式).目前,包括 1.13 亿条记录，7.5 GB数据5.2 GB索引。时间从1987到2007。

服务器使用4GB内存，这样数据和索引的大小都超过了内存大小。设置为4GB原因是数据仓库大小远远超过可能内存的大小，可能达几TB。对普通OLTP数据库来说，索引缓存在内存中，可以快速检索。如果数据超出内存大小，需要使用不同的方式。

创建有主键的表，因为通常表都会有主键。表的主键太大导致索引无法读入内存，这样一般来说不是高效的，意味着要经常访问磁盘，访问速度完全取决于你的磁盘和处理器。目前在设计很大的数据仓库里，有一种普遍的做法是不使用索引。所以也会比较有和没有主键的性能。

测试方法：

使用三种数据引擘MyISam,InnoDB,Archive.
对于每一种引擘,创建一个带主键的未分区表 (除了archive) 和两个分区表，一个按月一个按年。分区表分区方式如下：

CREATE TABLE by_year (

d DATE

)

PARTITION BY RANGE (YEAR(d))

(

PARTITION P1 VALUES LESS THAN (2001),

PARTITION P2 VALUES LESS THAN (2002),

PARTITION P3 VALUES LESS THAN (2003),

PARTITION P4 VALUES LESS THAN (MAXVALUE)

)

CREATE TABLE by_month (

d DATE

)

PARTITION BY RANGE (TO_DAYS(d))

(

PARTITION P1 VALUES LESS THAN (to_days(‘2001-02-01′)),— January

PARTITION P2 VALUES LESS THAN (to_days(‘2001-03-01′)),— February

PARTITION P3 VALUES LESS THAN (to_days(‘2001-04-01′)),— March

PARTITION P4 VALUES LESS THAN (MAXVALUE)

)

每一个都在 MysqL服务器上的单独的实例上测试,每实例只有一个库一个表。每种引擘,都会启动服务,运行查询并记录结果,然后关闭服务。服务实例通过MysqL SandBox创建。

加载数据的情况如下：

ID

引擘

是否分区

数据

大小

备注

加载时间 (*)

1 MyISAM none 1.13亿 13 GB with PK 37 min 2 MyISAM by month 1.13亿 8 GB without PK 19 min 3 MyISAM by year 1.13亿 8 GB without PK 18 min 4 InnoDB none 1.13亿 16 GB with PK 63 min @H_605_304@5 InnoDB by month 1.13亿 10 GB without PK 59 min 6 InnoDB by year 1.13亿 10 GB without PK 57 min 7 Archive none 1.13亿 1.8 GB no keys 20 min 8 Archive by month 1.13亿 1.8 GB no keys 21 min 9 Archive by year 1.13亿 1.8 GB no keys 20min

*在dual-Xeon服务器上

为了对比分区在大的和小的数据集上的效果，创建了另外9个实例，每一个包含略小于2GB的数据。

查询语句有两种

查询

SELECT COUNT(*)

From table_name

WHERE date_column BETWEEN start_date and end_date

查询

SELECT column_list

From table_name

WHERE column1 = x and column2 = y and column3 = z

对于第一种查询，创建不同的日期范围的语句。对于每一个范围，创建一组额外的相同范围日期的查询。每个日期范围的第一个查询是冷查询，意味着是第一次命中，随后的在同样范围内的查询是暖查询，意味着至少部分被缓存。查询语句在the Forge上。

结果：

1

带主键的分区表

第一个测试使用复合主键，就像原始数据表使用的一样。主键索引文件达到5.5 GB. 可以看出，分区不仅没有提高性能，主键还减缓了操作。因为如果使用主键索引查询，而索引又不能读入内存，则表现很差。提示我们分区很有用，但是必须使用得当。

+——–+—————–+—————–+—————–+

| 状态 | myisam 不分区 | myisam 月分区 | myisam 年分区 |

+——–+—————–+—————–+—————–+

| cold | 2.6574570285714 | 2.9169642 | 3.0373419714286 |

| warm | 2.5720722571429 | 3.1249698285714 | 3.1294000571429 |

+——–+—————–+—————–+—————–+

ARCHIVE引擘

+——–+—————-+—————–+—————–+

| 状态 | archive不分区 | archive月分区| archive年分区 |

+——–+—————-+—————–+—————–+

| cold | 249.849563 | 1.2436211111111 | 12.632532527778 |

| warm | 235.814442 | 1.0889786388889 | 12.600520777778 |

+——–+—————-+—————–+—————–+

注意ARCHIVE引擘月分区的响应时间比使用MyISAM好。

2

不带主键的分区表

因为如果主键的大小超出了可用的key buffer，甚至全部内存，所有使用主键的查询都会使用磁盘。新的方式只使用分区，不要主键。性能有显著的提高。

按月分区表得到了70%-90%的性能提高。

+——–+——————+——————+——————+

| 状态 | myisam 不分区 | myisam 月分区 | myisam 年分区 |

+——–+——————+——————+——————+

| cold | 2.6864490285714 | 0.64206445714286 | 2.6343286285714 |

| warm | 2.8157905714286 | 0.18774977142857 | 2.2084743714286 |

+——–+——————+——————+——————+

为了使区别更明显,我使用了两个大规模查询，可以利用分区的分区消除功能。

# query 1 – 按年统计

SELECT year(FlightDate) as y,count(*)

FROM flightstats

WHERE FlightDate BETWEEN “2001-01-01″ and “2003-12-31″

group by y

# query 2 – 按月统计

SELECT date_format(FlightDate,”%Y-%m”) as m,count(*)

FROM flightstats

WHERE FlightDate BETWEEN “2001-01-01″ and “2003-12-31″

GROUP BY m

结果显示按月分区表有30%-60%，按年分区表有15%-30%性能提升。

+———-+———–+———–+———–+

| query_id | 不分 | 月分 | 年分 |

+———-+———–+———–+———–+

| 1 | 97.779958 | 36.296519 | 82.327554 |

| 2 | 69.61055 | 47.644986 | 47.60223 |

+———-+———–+———–+———–+

处理器因素

当以上测试在家用机(Intel Dual Core 2.3 MHz cpu)上测试的时候。对于原来的对于dual Xeon 2.66 MHz来说，发现新服务器更快！。

重复上面的测试，令人吃惊:

+——–+——————-+————-+—————–+

|状态 | myisam 不分区 |myisam 月分区| myisam 年分区 |

+——–+——————-+————-+—————–+

| cold | 0.051063428571429 | 0.6577062 | 1.6663527428571 |

| warm | 0.063645485714286 | 0.1093724 | 1.2369152285714 |

+——–+——————-+————-+—————–+

myisam 不分区带主键的表比分区表更快. 分区表的表现和原来一样，但未分区表性能提高了，使得分区显得不必要。既然这台服务器似乎充分利用了索引的好处，我在分区表的分区列上加入了索引。

# 原始表

create table flightstats (

airlineiD int not null,

uniqueCarrier char(3) not null,

Carrier char(3) not null,

FlightDate date not null,

FlightNum char(5) not null,

TailNum char(8) not null,

ArrDelay double not null,

ArrTime datetime not null,

DepDelay double not null,

DepTime datetime not null,

Origin char(3) not null,

Dest char(3) not null,

Distance int not null,

Cancelled char(1) default ‘n',

Primary key (FlightDate,AirlineID,Carrier,UniqueCarrier,FlightNum,Origin,DepTime,Dest)

)

# 分区表

create table flightstats (

AirlineID int not null,

KEY (FlightDate)

)

PARTITION BY RANGE …

结果是让人满意的,得到35% 性能提高。

+——–+——————-+——————-+——————-+

|状态 | myisam 不分区 |myisam 月分区 | myisam 年分区 |

+——–+——————-+——————-+——————-+

| cold | 0.075289714285714 | 0.025491685714286 | 0.072398542857143 |

| warm | 0.064401257142857 | 0.031563085714286 | 0.056638085714286 |

+——–+——————-+——————-+——————-+

结论：

1.

使用表分区并不是性能提高的保证。它依赖于以下因素：

函数，如果原始字段不是int型;

数量.

2.

在应用到生产系统前运行基准测试和性能测试

依赖于你的数据库的用途，你可能得到巨大的性能提高也可能一无所获。如果不小心，甚至有可能会降低性能。

比如：一个使用月分区的表，在总是进行日期范围查询时可以得到极优的速度。但如果没有日期查询，那么会进行全表扫描。

分区对于海量数据性能提高是一个关键的工具。什么才是海量的数据取决于部署的硬件。盲目使用分区不能保证提高性能，但是在前期基准测试和性能测试的帮助下，可以成为完美的解决方案。

3.

Archive

表可以成为一个很好的折衷方案

Archive 表分区后可以得到巨大的性能提高。当然也依赖于你的用途，没有分区时任何查询都是全表扫描。如果你有不需要变更的历史数据，还要进行按时间的分析统计，使用Archive引擘是极佳的选择。它会使用10-20％的原空间，对于聚集查询有比MyISAM /InnoDB表更好的性能。

虽然一个很好的优化的分区MyISAM 表性能可能好于对应的Archive表,但是需要10倍的空间。

实验二：

1.建两个表，一个按时间字段分区，一个不分区。

CREATE TABLE part_tab

(

c1 int default NULL,

c2 VARchar(30) default NULL,

c3 date default NULL

) engine=myisam

PARTITION BY RANGE (year(c3)) (PARTITION p0 VALUES LESS THAN (1995),

PARTITION p1 VALUES LESS THAN (1996),PARTITION p2 VALUES LESS THAN (1997),

PARTITION p3 VALUES LESS THAN (1998),PARTITION p4 VALUES LESS THAN (1999),

PARTITION p5 VALUES LESS THAN (2000),PARTITION p6 VALUES LESS THAN (2001),

PARTITION p7 VALUES LESS THAN (2002),PARTITION p8 VALUES LESS THAN (2003),

PARTITION p9 VALUES LESS THAN (2004),PARTITION p10 VALUES LESS THAN (2010),

PARTITION p11 VALUES LESS THAN MAXVALUE );

create table no_part_tab

(c1 int(11) default NULL,

c3 date default NULL) engine=myisam;

2.建一个存储过程,利用该过程向两个表插入各8百万条不同数据。

delimiter //

CREATE PROCEDURE load_part_tab()

begin

declare v int default 0;

while v <>

do

insert into part_tab

values (v,'testing partitions',adddate(‘1995-01-01′,(rand(v)*36520) mod 3652));

set v = v + 1;

end while;

end

//

然后执行

MysqL> delimiter ;

MysqL> call load_part_tab();

Query OK,1 row affected (8 min 17.75 sec)

MysqL> insert into no_part_tab select * from part_tab;

Query OK,8000000 rows affected (51.59 sec)

Records: 8000000 Duplicates: 0 Warnings: 0

3.开始对这两表中的数据进行简单的范围查询吧。并显示执行过程解析：

MysqL> select count(*) from no_part_tab where c3 > date ‘1995-01-01′ and c3 < date="">

+———-+

| count(*) |

+———-+

| 795181 |

+———-+

1 row in set (38.30 sec)

MysqL> select count(*) from part_tab where c3 > date ‘1995-01-01′ and c3 < date="">

+———-+

| count(*) |

+———-+

| 795181 |

+———-+

1 row in set (3.88 sec)

MysqL> explain select count(*) from no_part_tab where c3 > date ‘1995-01-01′ and c3 < date="">

*************************** 1. row ***************************

id: 1

select_tyPE: SIMPLE

table: no_part_tab

type: ALL

possible_keys: NULL

key: NULL

key_len: NULL

ref: NULL

rows: 8000000

Extra: Using where

1 row in set (0.00 sec)

MysqL> explain partitions select count(*) from part_tab where

-> c3 > date ‘1995-01-01′ and c3 < date="">

*************************** 1. row ***************************

id: 1

select_type: SIMPLE

table: part_tab

partitions: p1

type: ALL

possible_keys: NULL

key: NULL

key_len: NULL

ref: NULL

rows: 798458

Extra: Using where

1 row in set (0.00 sec)

从上面结果可以看出，使用表分区比非分区的减少90％的响应时间。命令解析Explain程序可以看出在对已分区的表的查询过程中仅对第一个分区进行了扫描，其余跳过。进一步测试：

– 增加日期范围

MysqL> select count(*) from no_part_tab where c3 > date ‘-01-01′and c3 < date="">

+———-+

| count(*) |

+———-+

| 2396524 |

+———-+

1 row in set (5.42 sec)

MysqL> select count(*) from part_tab where c3 > date ‘-01-01′and c3 < date="">

+———-+

| count(*) |

+———-+

| 2396524 |

+———-+

1 row in set (2.63 sec)

– 增加未索引字段查询

MysqL> select count(*) from part_tab where c3 > date ‘-01-01′and c3 <>

‘1996-12-31′ and c2='hello';

+———-+

| count(*) |

+———-+

| 0 |

+———-+

1 row in set (0.75 sec)

MysqL> select count(*) from no_part_tab where c3 > date ‘-01-01′and c3 <>

te ‘1996-12-31′ and c2='hello';

+———-+

| count(*) |

+———-+

| 0 |

+———-+

1 row in set (11.52 sec)

 

结论

：

文件空间大致相同 （数据和索引文件）

查询语句中有未建立索引字段，分区时间远远优于未分区时间

查询语句中字段建立了索引，分区和未分区的差别缩小，分区略优于未分区。

功能。

去除不必要的字段

增加myisam_max_sort_file_size 会增加分区性能

脚本宝典总结

以上是脚本宝典为你收集整理的基于MySQL分区性能的详细介绍全部内容，希望文章能够帮你解决基于MySQL分区性能的详细介绍所遇到的问题。

如果觉得脚本宝典网站内容还不错，欢迎将脚本宝典推荐好友。

本图文内容来源于网友网络收集整理提供，作为学习参考使用，版权属于原作者。
如您有任何意见或建议可联系处理。小编QQ：384754419，请注明来意。