所謂按天，不過是日期精確到天而已。
創(chuàng)新互聯建站專注為客戶提供全方位的互聯網綜合服務，包含不限于成都做網站、成都網站建設、丹徒網絡推廣、微信小程序、丹徒網絡營銷、丹徒企業(yè)策劃、丹徒品牌公關、搜索引擎seo、人物專訪、企業(yè)宣傳片、企業(yè)代運營等，從售前售中售后，我們都將竭誠為您服務，您的肯定，是我們最大的嘉獎；創(chuàng)新互聯建站為所有大學生創(chuàng)業(yè)者提供丹徒建站搭建服務，24小時服務熱線：13518219792，官方網址：www.cdcxhl.com
錯誤的按日期分區(qū)例子
最直觀的方法，就是直接用年月日這種日期格式來進行常規(guī)的分區(qū)：
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進行分區(qū)，可惜想當然往往不能奏效，會得到一個錯誤信息:
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
上述分區(qū)方式沒有成功，而且明顯的不經濟，老練的DBA會用整型數值來進行分區(qū)：
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使用全表掃描，而不是按照我們的日期分區(qū)分塊查詢。原文中解釋到MYSQL的優(yōu)化器并不認這種日期形式的分區(qū)，花了大量的篇幅來引誘俺走上歧路，過分。
正確的日期分區(qū)例子
mysql優(yōu)化器支持以下兩種內置的日期函數進行分區(qū)：
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()函數分區(qū)成功，我們分析一下看看：
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優(yōu)化器這次不負眾望，僅僅在p1分區(qū)進行查詢。在這種情況下查詢，真的能夠帶來提升查詢效率么？下面分別對這次建立的part_date3和之前分區(qū)失敗的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)
可以看到，分區(qū)正確的話query花費時間為4秒，而分區(qū)錯誤則花費時間40秒（相當于沒有分區(qū)），效率有90％的提升！所以我們千萬要正確的使用分區(qū)功能，分區(qū)后務必用explain驗證，這樣才能獲得真正的性能提升。
注意：
在mysql5.1中建立分區(qū)表的語句中，只能包含下列函數：
ABS()
CEILING()?and?FLOOR()?（在使用這2個函數的建立分區(qū)表的前提是使用函數的分區(qū)鍵是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()
以下是創(chuàng)建一張測試表TEST并且按照時間CREATE_TIME創(chuàng)建RANGE分區(qū)，并使用ID創(chuàng)建hash分區(qū)，組成復合分區(qū)。
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的表分區(qū)功能（邏輯上還是一個表，對程序來說是透明的），通過分區(qū)函數可實現自動分表。如果想實現根據數據每月或每周動態(tài)的再分區(qū)，可以寫一個存儲過程實現分區(qū)調整邏輯，最后寫一個mysql event（自動化作業(yè)）按周期調用這個存儲過程就行了。
分表是將一個大表按照一定的規(guī)則分解成多張具有獨立存儲空間的實體表，我們可以稱為子表，每個表都對應三個文件，MYD數據文件，.MYI索引文件，.frm表結構文件。這些子表可以分布在同一塊磁盤上，也可以在不同的機器上。app讀寫的時候根據事先定義好的規(guī)則得到對應的子表名，然后去操作它。
分表和分區(qū)的區(qū)別：
一、什么是mysql分表，分區(qū)?
分表：從表面意思上看呢，就是把一張表分成N多個小表，具體請看:mysql分表的3種方法
分區(qū)：分區(qū)呢就是把一張表的數據分成N多個區(qū)塊，這些區(qū)塊可以在同一個磁盤上，也可以在不同的磁盤上，具體請參考mysql分區(qū)功能詳細介紹，以及實例?
二、mysql分表和分區(qū)有什么區(qū)別呢?
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里面就存了一些分表的關系，以及插入數據的方式?？梢园芽偙砝斫獬梢粋€外殼，或者是聯接池。?
②分區(qū)不一樣，一張大表進行分區(qū)后，他還是一張表，不會變成二張表，但是他存放數據的區(qū)塊變多了。
[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這張表，分為二個區(qū)，p1和p3，本來是三個區(qū)，被我刪了一個區(qū)。我們都知道一張表對應三個文件.MYD,.MYI,.frm。分 區(qū)呢根據一定的規(guī)則把數據文件和索引文件進行了分割，還多出了一個.par文件，打開.par文件后你可以看出他記錄了，這張表的分區(qū)信息，根分表中的.MRG有點像。分區(qū)后，還是一張，而不是多張表。?
如orderid,userid,ordertime,.....
ordertime2015-01-01 #p0
ordertime2015-04-01 #p1
ordertime2015-07-01 #p2
ordertime2015-10-01 #p3
ordertime2016-01-01 #p4
按照時間分區(qū)。大部分只查詢最近的訂單數據，那么大部分只訪問一個分區(qū)，比整個表小多了，數據庫可以更加好的緩存，性能也提高了。這個是數據庫分的，應用程序透明，無需修改。
2，數據處理上?
①、分表后，數據都是存放在分表里，總表只是一個外殼，存取數據發(fā)生在一個一個的分表里面?？聪旅娴睦樱?
select * from alluser where id='12'表面上看，是對表alluser進行操作的，其實不是的。是對alluser里面的分表進行了操作。?
②、分區(qū)呢，不存在分表的概念，分區(qū)只不過把存放數據的文件分成了許多小塊，分區(qū)后的表呢，還是一張表。數據處理還是由自己來完成。?
3、提高性能上?
①、分表后，單表的并發(fā)能力提高了，磁盤I/O性能也提高了。并發(fā)能力為什么提高了呢，因為查尋一次所花的時間變短了，如果出現高并發(fā)的話，總表可以根據不同 的查詢，將并發(fā)壓力分到不同的小表里面。磁盤I/O性能怎么搞高了呢，本來一個非常大的.MYD文件現在也分攤到各個小表的.MYD中去了。?
②、mysql提出了分區(qū)的概念，我覺得就想突破磁盤I/O瓶頸，想提高磁盤的讀寫能力，來增加mysql性能。?
在這一點上，分區(qū)和分表的測重點不同，分表重點是存取數據時，如何提高mysql并發(fā)能力上；而分區(qū)呢，如何突破磁盤的讀寫能力，從而達到提高mysql性能的目的。?
4、實現的難易度上?
①、分表的方法有很多，用merge來分表，是最簡單的一種方式。這種方式根分區(qū)難易度差不多，并且對程序代碼來說可以做到透明的。如果是用其他分表方式就比分區(qū)麻煩了。?
②、分區(qū)實現是比較簡單的，建立分區(qū)表，根建平常的表沒什么區(qū)別，并且對開代碼端來說是透明的。?
三、mysql分表和分區(qū)有什么聯系呢?
1、都能提高mysql的性高，在高并發(fā)狀態(tài)下都有一個良好的表面。?
2、分表和分區(qū)不矛盾，可以相互配合的，對于那些大訪問量，并且表數據比較多的表，我們可以采取分表和分區(qū)結合的方式（如果merge這種分表方式，不能和分區(qū)配合的話，可以用其他的分表試），訪問量不大，但是表數據很多的表，我們可以采取分區(qū)的方式等。
分庫分表區(qū)別：
1、什么是分庫分表？
從字面上簡單理解，就是把原本存儲于一個庫的數據分塊存儲到多個庫上，把原本存儲于一個表的數據分塊存儲到多個表上。
2、為什么要分庫分表？
數據庫中的數據量不一定是可控的，在未進行分庫分表的情況下，隨著時間和業(yè)務的發(fā)展，庫中的表會越來越多，表中的數據量也會越來越大，相應地，數據操作，增刪改查的開銷也會越來越大；另外，一臺服務器的資源（CPU、磁盤、內存、IO等）是有限的，最終數據庫所能承載的數據量、數據處理能力都將遭遇瓶頸,。
3、分庫分表的實施策略。
如果你的單機性能很低了，那可以嘗試分庫。分庫，業(yè)務透明，在物理實現上分成多個服務器，不同的分庫在不同服務器上。分區(qū)可以把表分到不同的硬盤上，但不能分配到不同服務器上。一臺機器的性能是有限制的，用分庫可以解決單臺服務器性能不夠，或者成本過高問題。
當分區(qū)之后，表還是很大，處理不過來，這時候可以用分庫。
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、何謂水平切分，當一個表中的數據量過大時，我們可以把該表的數據按照某種規(guī)則，例如userID散列、按性別、按省，進行劃分，然后存儲到多個結構相同的表，和不同的庫上。
例如，我們的userDB中的用戶數據表中，每一個表的數據量都很大，就可以把userDB切分為結構相同的多個userDB：part0DB、part1DB等，再將userDB上的用戶數據表userTable，切分為很多userTable：userTable0、userTable1等，然后將這些表按照一定的規(guī)則存儲到多個userDB上。
3.3、應該使用哪一種方式來實施數據庫分庫分表，這要看數據庫中數據量的瓶頸所在，并綜合項目的業(yè)務類型進行考慮。
如果數據庫是因為表太多而造成海量數據，并且項目的各項業(yè)務邏輯劃分清晰、低耦合，那么規(guī)則簡單明了、容易實施的垂直切分必是首選。
而如果數據庫中的表并不多，但單表的數據量很大、或數據熱度很高，這種情況之下就應該選擇水平切分，水平切分比垂直切分要復雜一些，它將原本邏輯上屬于一體的數據進行了物理分割，除了在分割時要對分割的粒度做好評估，考慮數據平均和負載平均，后期也將對項目人員及應用程序產生額外的數據管理負擔。
在現實項目中，往往是這兩種情況兼而有之，這就需要做出權衡，甚至既需要垂直切分，又需要水平切分。我們的游戲項目便綜合使用了垂直與水平切分，我們首先對數據庫進行垂直切分，然后，再針對一部分表，通常是用戶數據表，進行水平切分。
4 分庫分表存在的問題。
4.1 事務問題。
在執(zhí)行分庫分表之后，由于數據存儲到了不同的庫上，數據庫事務管理出現了困難。如果依賴數據庫本身的分布式事務管理功能去執(zhí)行事務，將付出高昂的性能代價；如果由應用程序去協助控制，形成程序邏輯上的事務，又會造成編程方面的負擔。
4.2 跨庫跨表的join問題。
在執(zhí)行了分庫分表之后，難以避免會將原本邏輯關聯性很強的數據劃分到不同的表、不同的庫上，這時，表的關聯操作將受到限制，我們無法join位于不同分庫的表，也無法join分表粒度不同的表，結果原本一次查詢能夠完成的業(yè)務，可能需要多次查詢才能完成。
4.3 額外的數據管理負擔和數據運算壓力。
額外的數據管理負擔，最顯而易見的就是數據的定位問題和數據的增刪改查的重復執(zhí)行問題，這些都可以通過應用程序解決，但必然引起額外的邏輯運算，例如，對于一個記錄用戶成績的用戶數據表userTable，業(yè)務要求查出成績最好的100位，在進行分表之前，只需一個order by語句就可以搞定，但是在進行分表之后，將需要n個order by語句，分別查出每一個分表的前100名用戶數據，然后再對這些數據進行合并計算，才能得出結果。
重慶分公司
重慶分公司
