189 8069 5689
所谓按天，不过是日期精确到天而已。
创新互联建站专注为客户提供全方位的互联网综合服务，包含不限于成都做网站、成都网站建设、丹徒网络推广、微信小程序、丹徒网络营销、丹徒企业策划、丹徒品牌公关、搜索引擎seo、人物专访、企业宣传片、企业代运营等，从售前售中售后，我们都将竭诚为您服务，您的肯定，是我们最大的嘉奖；创新互联建站为所有大学生创业者提供丹徒建站搭建服务，24小时服务热线：13518219792，官方网址：www.cdcxhl.com
错误的按日期分区例子
最直观的方法，就是直接用年月日这种日期格式来进行常规的分区：
mysql create table rms (d date)
- partition by range (d)
- (partition p0 values less than ('1995-01-01'),
- partition p1 VALUES LESS THAN ('2010-01-01'));
上面的例子中，就是直接用"Y-m-d"的格式来对一个table进行分区，可惜想当然往往不能奏效，会得到一个错误信息:
ERROR 1064 (42000): VALUES value must be of same type as partition function near '),
partition p1 VALUES LESS THAN ('2010-01-01'))' at line 3
上述分区方式没有成功，而且明显的不经济，老练的DBA会用整型数值来进行分区：
mysql CREATE TABLE part_date1
- ( c1 int default NULL,
- c2 varchar(30) default NULL,
- c3 date default NULL) engine=myisam
- partition by range (cast(date_format(c3,'%Y%m%d') as signed))
- (PARTITION p0 VALUES LESS THAN (19950101),
- PARTITION p1 VALUES LESS THAN (19960101) ,
- PARTITION p2 VALUES LESS THAN (19970101) ,
- PARTITION p3 VALUES LESS THAN (19980101) ,
- PARTITION p4 VALUES LESS THAN (19990101) ,
- PARTITION p5 VALUES LESS THAN (20000101) ,
- PARTITION p6 VALUES LESS THAN (20010101) ,
- PARTITION p7 VALUES LESS THAN (20020101) ,
- PARTITION p8 VALUES LESS THAN (20030101) ,
- PARTITION p9 VALUES LESS THAN (20040101) ,
- PARTITION p10 VALUES LESS THAN (20100101),
- PARTITION p11 VALUES LESS THAN MAXVALUE );
Query OK, 0 rows affected (0.01 sec)
搞定？接着往下分析
mysql explain partitions
- select count(*) from part_date1 where
- c3 '1995-01-01' and c3 '1995-12-31'\G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: part_date1
partitions: p0,p1,p2,p3,p4,p5,p6,p7,p8,p9,p10,p11
type: ALL
possible_keys: NULL
key: NULL
key_len: NULL
ref: NULL
rows: 8100000
Extra: Using where
1 row in set (0.00 sec)
万恶的mysql居然对上面的sql使用全表扫描，而不是按照我们的日期分区分块查询。原文中解释到MYSQL的优化器并不认这种日期形式的分区，花了大量的篇幅来引诱俺走上歧路，过分。
正确的日期分区例子
mysql优化器支持以下两种内置的日期函数进行分区：
TO_DAYS()
YEAR()
看个例子：
mysql CREATE TABLE part_date3
- ( c1 int default NULL,
- c2 varchar(30) default NULL,
- c3 date default NULL) engine=myisam
- partition by range (to_days(c3))
- (PARTITION p0 VALUES LESS THAN (to_days('1995-01-01')),
- PARTITION p1 VALUES LESS THAN (to_days('1996-01-01')) ,
- PARTITION p2 VALUES LESS THAN (to_days('1997-01-01')) ,
- PARTITION p3 VALUES LESS THAN (to_days('1998-01-01')) ,
- PARTITION p4 VALUES LESS THAN (to_days('1999-01-01')) ,
- PARTITION p5 VALUES LESS THAN (to_days('2000-01-01')) ,
- PARTITION p6 VALUES LESS THAN (to_days('2001-01-01')) ,
- PARTITION p7 VALUES LESS THAN (to_days('2002-01-01')) ,
- PARTITION p8 VALUES LESS THAN (to_days('2003-01-01')) ,
- PARTITION p9 VALUES LESS THAN (to_days('2004-01-01')) ,
- PARTITION p10 VALUES LESS THAN (to_days('2010-01-01')),
- PARTITION p11 VALUES LESS THAN MAXVALUE );
Query OK, 0 rows affected (0.00 sec)
以to_days()函数分区成功，我们分析一下看看：
mysql explain partitions
- select count(*) from part_date3 where
- c3 date '1995-01-01' and c3 date '1995-12-31'\G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: part_date3
partitions: p1
type: ALL
possible_keys: NULL
key: NULL
key_len: NULL
ref: NULL
rows: 808431
Extra: Using where
1 row in set (0.00 sec)
可以看到，mysql优化器这次不负众望，仅仅在p1分区进行查询。在这种情况下查询，真的能够带来提升查询效率么？下面分别对这次建立的part_date3和之前分区失败的part_date1做一个查询对比：
mysql select count(*) from part_date3 where
- c3 date '1995-01-01' and c3 date '1995-12-31';
+----------+
| count(*) |
+----------+
| 805114 |
+----------+
1 row in set (4.11 sec)
mysql select count(*) from part_date1 where
- c3 date '1995-01-01' and c3 date '1995-12-31';
+----------+
| count(*) |
+----------+
| 805114 |
+----------+
1 row in set (40.33 sec)
可以看到，分区正确的话query花费时间为4秒，而分区错误则花费时间40秒（相当于没有分区），效率有90％的提升！所以我们千万要正确的使用分区功能，分区后务必用explain验证，这样才能获得真正的性能提升。
注意：
在mysql5.1中建立分区表的语句中，只能包含下列函数：
ABS()
CEILING() and FLOOR() （在使用这2个函数的建立分区表的前提是使用函数的分区键是INT类型），例如
mysql CREATE TABLE t (c FLOAT) PARTITION BY LIST( FLOOR(c) )( - PARTITION p0 VALUES IN (1,3,5), - PARTITION p1 VALUES IN (2,4,6) - );; ERROR 1491 (HY000): The PARTITION function returns the wrong type mysql CREATE TABLE t (c int) PARTITION BY LIST( FLOOR(c) )( - PARTITION p0 VALUES IN (1,3,5), - PARTITION p1 VALUES IN (2,4,6) - ); Query OK, 0 rows affected (0.01 sec)
DAY()
DAYOFMONTH()
DAYOFWEEK()
DAYOFYEAR()
DATEDIFF()
EXTRACT()
HOUR()
MICROSECOND()
MINUTE()
MOD()
MONTH()
QUARTER()
SECOND()
TIME_TO_SEC()
TO_DAYS()
WEEKDAY()
YEAR()
YEARWEEK()
以下是创建一张测试表TEST并且按照时间CREATE_TIME创建RANGE分区，并使用ID创建hash分区，组成复合分区。
CREATE TABLE TEST (
CREATE_TIME DATETIME DEFAULT NULL, ID BIGINT(15) DEFAULT NULL
) ENGINE=INNODB DEFAULT CHARSET=utf8
PARTITION BY RANGE(TO_DAYS(CREATE_TIME)) PARTITIONS 7 SUBPARTITION BY HASH(ID) SUBPARTITIONS 16
(PARTITION P1710 VALUES LESS THAN (TO_DAYS ('2017-10-01'))
(SUBPARTITION P1710sp0 ,SUBPARTITION P1710sp1 ,
SUBPARTITION P1710sp2 ,SUBPARTITION P1710sp3 ,
SUBPARTITION P1710sp4 ,SUBPARTITION P1710sp5 ,
SUBPARTITION P1710sp6 ,SUBPARTITION P1710sp7 ,
SUBPARTITION P1710sp8 ,SUBPARTITION P1710sp9 ,
SUBPARTITION P1710sp10 ,SUBPARTITION P1710sp11 ,
SUBPARTITION P1710sp12 ,SUBPARTITION P1710sp13 ,
SUBPARTITION P1710sp14 ,SUBPARTITION P1710sp15 ),
PARTITION P1711 VALUES LESS THAN (TO_DAYS ('2017-11-01'))
(SUBPARTITION P1711sp0 ,SUBPARTITION P1711sp1 ,
SUBPARTITION P1711sp2 , SUBPARTITION P1711sp3 ,
SUBPARTITION P1711sp4 , SUBPARTITION P1711sp5 ,
SUBPARTITION P1711sp6 , SUBPARTITION P1711sp7 ,
SUBPARTITION P1711sp8 , SUBPARTITION P1711sp9 ,
SUBPARTITION P1711sp10 , SUBPARTITION P1711sp11 ,
SUBPARTITION P1711sp12 , SUBPARTITION P1711sp13 ,
SUBPARTITION P1711sp14 , SUBPARTITION P1711sp15 ),
用mysql的表分区功能（逻辑上还是一个表，对程序来说是透明的），通过分区函数可实现自动分表。如果想实现根据数据每月或每周动态的再分区，可以写一个存储过程实现分区调整逻辑，最后写一个mysql event（自动化作业）按周期调用这个存储过程就行了。
分表是将一个大表按照一定的规则分解成多张具有独立存储空间的实体表，我们可以称为子表，每个表都对应三个文件，MYD数据文件，.MYI索引文件，.frm表结构文件。这些子表可以分布在同一块磁盘上，也可以在不同的机器上。app读写的时候根据事先定义好的规则得到对应的子表名，然后去操作它。
分表和分区的区别：
一、什么是mysql分表，分区
分表：从表面意思上看呢，就是把一张表分成N多个小表，具体请看:mysql分表的3种方法
分区：分区呢就是把一张表的数据分成N多个区块，这些区块可以在同一个磁盘上，也可以在不同的磁盘上，具体请参考mysql分区功能详细介绍，以及实例
二、mysql分表和分区有什么区别呢
1、实现方式上
①mysql的分表是真正的分表，一张表分成很多表后，每一个小表都是完正的一张表，都对应三个文件，一个.MYD数据文件，.MYI索引文件，.frm表结构文件。
[root@BlackGhost test]# ls |grep user
alluser.MRG
alluser.frm
user1.MYD
user1.MYI
user1.frm
user2.MYD
user2.MYI
user2.frm
简单说明一下，上面的分表呢是利用了merge存储引擎（分表的一种），alluser是总表，下面有二个分表，user1，user2。他们二个都是独立的表，取数据的时候，我们可以通过总表来取。这里总表是没有.MYD,.MYI这二个文件的，也就是说，总表他不是一张表，没有数据，数据都放在分表里面。我们来看看.MRG到底是什么东西
[root@BlackGhost test]# cat alluser.MRG |more
user1
user2
#INSERT_METHOD=LAST
从上面我们可以看出，alluser.MRG里面就存了一些分表的关系，以及插入数据的方式。可以把总表理解成一个外壳，或者是联接池。
②分区不一样，一张大表进行分区后，他还是一张表，不会变成二张表，但是他存放数据的区块变多了。
[root@BlackGhost test]# ls |grep aa
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,.....
ordertime2015-01-01 #p0
ordertime2015-04-01 #p1
ordertime2015-07-01 #p2
ordertime2015-10-01 #p3
ordertime2016-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名用户数据，然后再对这些数据进行合并计算，才能得出结果。