① sql中什麼情況下用分組
你指的應該是「group by」吧？
其實可以這樣理解，舉個例子：
比如，一張「學生成績表」，現在要求你分別求出（注意是「分別」）男生和女生的平均成績（註：指的是「所有男生的平均成績」和「所有女生的平均成績」），此時，你就必須通過「性別」欄位進行分組，然後才可以分別求出男生和女生平均成績！
【個人感覺學習這些語句的時候最好賦予實際的環境中去理解，這樣更清楚也更好理解。希望我的回答對你有所幫助!】
② 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 時，將無法在隱式轉換過程中被截斷。
③ mysql 什麼時候分區 什麼時候分表
一，什麼是mysql分表，分區
什麼是分表，從表面意思上看呢，就是把一張表分成N多個小表，具體請看mysql分表的3種方法
什麼是分區，分區呢就是把一張表的數據分成N多個區塊，這些區塊可以在同一個磁碟上，也可以在不同的磁碟上
一，先說一下為什麼要分表
當一張的數據達到幾百萬時，你查詢一次所花的時間會變多，如果有聯合查詢的話，我想有可能會死在那兒了。分表的目的就在於此，減小資料庫的負擔，縮短查詢時間。
根據個人經驗，mysql執行一個sql的過程如下：
1,接收到sql;2,把sql放到排隊隊列中 ;3,執行sql;4,返回執行結果。在這個執行過程中最花時間在什麼地方呢？第一，是排隊等待的時間，第二，sql的執行時間。其實這二個是一回事，等待的同時，肯定有sql在執行。所以我們要縮短sql的執行時間。
mysql中有一種機制是表鎖定和行鎖定，為什麼要出現這種機制，是為了保證數據的完整性，我舉個例子來說吧，如果有二個sql都要修改同一張表的同一條數據，這個時候怎麼辦呢，是不是二個sql都可以同時修改這條數據呢？很顯然mysql對這種情況的處理是，一種是表鎖定（myisam存儲引擎），一個是行鎖定（innodb存儲引擎）。表鎖定表示你們都不能對這張表進行操作，必須等我對表操作完才行。行鎖定也一樣，別的sql必須等我對這條數據操作完了，才能對這條數據進行操作。如果數據太多，一次執行的時間太長，等待的時間就越長，這也是我們為什麼要分表的原因。
二，分表
1，做mysql集群，例如：利用mysql cluster ，mysql proxy，mysql replication，drdb等等
有人會問mysql集群，根分表有什麼關系嗎？雖然它不是實際意義上的分表，但是它啟到了分表的作用，做集群的意義是什麼呢？為一個資料庫減輕負擔，說白了就是減少sql排隊隊列中的sql的數量，舉個例子：有10個sql請求，如果放在一個資料庫伺服器的排隊隊列中，他要等很長時間，如果把這10個sql請求，分配到5個資料庫伺服器的排隊隊列中，一個資料庫伺服器的隊列中只有2個，這樣等待時間是不是大大的縮短了呢？這已經很明顯了。所以我把它列到了分表的范圍以內，我做過一些mysql的集群：
linux mysql proxy 的安裝，配置，以及讀寫分離
mysql replication 互為主從的安裝及配置，以及數據同步
優點：擴展性好，沒有多個分表後的復雜操作（php代碼）
缺點：單個表的數據量還是沒有變，一次操作所花的時間還是那麼多，硬體開銷大。
2，預先估計會出現大數據量並且訪問頻繁的表，將其分為若干個表
這種預估大差不差的，論壇裡面發表帖子的表，時間長了這張表肯定很大，幾十萬，幾百萬都有可能。 聊天室裡面信息表，幾十個人在一起一聊一個晚上，時間長了，這張表的數據肯定很大。像這樣的情況很多。所以這種能預估出來的大數據量表，我們就事先分出個N個表，這個N是多少，根據實際情況而定。以聊天信息表為例：
我事先建100個這樣的表，message_00,message_01,message_02..........message_98,message_99.然後根據用戶的ID來判斷這個用戶的聊天信息放到哪張表裡面，你可以用hash的方式來獲得，可以用求余的方式來獲得，方法很多，各人想各人的吧。下面用hash的方法來獲得表名：
查看復制列印?
<?php
function get_hash_table($table,$userid) {
$str = crc32($userid);
if($str<0){
$hash = "0".substr(abs($str), 0, 1);
}else{
$hash = substr($str, 0, 2);
}
return $table."_".$hash;
}
echo get_hash_table('message','user18991'); //結果為message_10
echo get_hash_table('message','user34523'); //結果為message_13
?>
說明一下，上面的這個方法，告訴我們user18991這個用戶的消息都記錄在message_10這張表裡，user34523這個用戶的消息都記錄在message_13這張表裡，讀取的時候，只要從各自的表中讀取就行了。
優點：避免一張表出現幾百萬條數據，縮短了一條sql的執行時間
缺點：當一種規則確定時，打破這條規則會很麻煩，上面的例子中我用的hash演算法是crc32，如果我現在不想用這個演算法了，改用md5後，會使同一個用戶的消息被存儲到不同的表中，這樣數據亂套了。擴展性很差。
3，利用merge存儲引擎來實現分表
我覺得這種方法比較適合，那些沒有事先考慮，而已經出現了得，數據查詢慢的情況。這個時候如果要把已有的大數據量表分開比較痛苦，最痛苦的事就是改代碼，因為程序裡面的sql語句已經寫好了，現在一張表要分成幾十張表，甚至上百張表，這樣sql語句是不是要重寫呢？舉個例子，我很喜歡舉子
mysql>show engines;的時候你會發現mrg_myisam其實就是merge。
查看復制列印?
mysql> CREATE TABLE IF NOT EXISTS `user1` (
-> `id` int(11) NOT NULL AUTO_INCREMENT,
-> `name` varchar(50) DEFAULT NULL,
-> `sex` int(1) NOT NULL DEFAULT '0',
-> PRIMARY KEY (`id`)
-> ) ENGINE=MyISAM DEFAULT CHARSET=utf8 AUTO_INCREMENT=1 ;
Query OK, 0 rows affected (0.05 sec)
mysql> CREATE TABLE IF NOT EXISTS `user2` (
-> `id` int(11) NOT NULL AUTO_INCREMENT,
-> `name` varchar(50) DEFAULT NULL,
-> `sex` int(1) NOT NULL DEFAULT '0',
-> PRIMARY KEY (`id`)
-> ) ENGINE=MyISAM DEFAULT CHARSET=utf8 AUTO_INCREMENT=1 ;
Query OK, 0 rows affected (0.01 sec)
mysql> INSERT INTO `user1` (`name`, `sex`) VALUES('張映', 0);
Query OK, 1 row affected (0.00 sec)
mysql> INSERT INTO `user2` (`name`, `sex`) VALUES('tank', 1);
Query OK, 1 row affected (0.00 sec)
mysql> CREATE TABLE IF NOT EXISTS `alluser` (
-> `id` int(11) NOT NULL AUTO_INCREMENT,
-> `name` varchar(50) DEFAULT NULL,
-> `sex` int(1) NOT NULL DEFAULT '0',
-> INDEX(id)
-> ) TYPE=MERGE UNION=(user1,user2) INSERT_METHOD=LAST AUTO_INCREMENT=1 ;
Query OK, 0 rows affected, 1 warning (0.00 sec)
mysql> select id,name,sex from alluser;
+----+--------+-----+
| id | name | sex |
+----+--------+-----+
| 1 | 張映 | 0 |
| 1 | tank | 1 |
+----+--------+-----+
2 rows in set (0.00 sec)
mysql> INSERT INTO `alluser` (`name`, `sex`) VALUES('tank2', 0);
Query OK, 1 row affected (0.00 sec)
mysql> select id,name,sex from user2
-> ;
+----+-------+-----+
| id | name | sex |
+----+-------+-----+
| 1 | tank | 1 |
| 2 | tank2 | 0 |
+----+-------+-----+
2 rows in set (0.00 sec)
從上面的操作中，我不知道你有沒有發現點什麼？假如我有一張用戶表user，有50W條數據，現在要拆成二張表user1和user2，每張表25W條數據，
INSERT INTO user1(user1.id,user1.name,user1.sex)SELECT (user.id,user.name,user.sex)FROM user where user.id <= 250000
INSERT INTO user2(user2.id,user2.name,user2.sex)SELECT (user.id,user.name,user.sex)FROM user where user.id > 250000
這樣我就成功的將一張user表，分成了二個表，這個時候有一個問題，代碼中的sql語句怎麼辦，以前是一張表，現在變成二張表了，代碼改動很大，這樣給程序員帶來了很大的工作量，有沒有好的辦法解決這一點呢？辦法是把以前的user表備份一下，然後刪除掉，上面的操作中我建立了一個alluser表，只把這個alluser表的表名改成user就行了。但是，不是所有的mysql操作都能用的
a，如果你使用 alter table 來把 merge 表變為其它表類型，到底層表的映射就被丟失了。取而代之的，來自底層 myisam 表的行被復制到已更換的表中，該表隨後被指定新類型。
b，網上看到一些說replace不起作用，我試了一下可以起作用的。暈一個先
mysql> UPDATE alluser SET sex=REPLACE(sex, 0, 1) where id=2;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1 Changed: 1 Warnings: 0
mysql> select * from alluser;
+----+--------+-----+
| id | name | sex |
+----+--------+-----+
| 1 | 張映 | 0 |
| 1 | tank | 1 |
| 2 | tank2 | 1 |
+----+--------+-----+
3 rows in set (0.00 sec)
c，一個 merge 表不能在整個表上維持 unique 約束。當你執行一個 insert，數據進入第一個或者最後一個 myisam 表（取決於 insert_method 選項的值）。mysql 確保唯一鍵值在那個 myisam 表裡保持唯一，但不是跨集合里所有的表。
d,當你創建一個 merge 表之時，沒有檢查去確保底層表的存在以及有相同的機構。當 merge 表被使用之時，mysql 檢查每個被映射的表的記錄長度是否相等，但這並不十分可靠。如果你從不相似的 myisam 表創建一個 merge 表，你非常有可能撞見奇怪的問題。
優點：擴展性好，並且程序代碼改動的不是很大
缺點：這種方法的效果比第二種要差一點
三，總結一下
上面提到的三種方法，我實際做過二種，第一種和第二種。第三種沒有做過，所以說的細一點。哈哈。做什麼事都有一個度，超過個度就過變得很差，不能一味的做資料庫伺服器集群，硬體是要花錢買的，也不要一味的分表，分出來1000表，mysql的存儲歸根到底還以文件的形勢存在硬碟上面，一張表對應三個文件，1000個分表就是對應3000個文件，這樣檢索起來也會變的很慢。我的建議是
方法1和方法2結合的方式來進行分表
方法1和方法3結合的方式來進行分表
我的二個建議適合不同的情況，根據個人情況而定，我覺得會有很多人選擇方法1和方法3結合的方式
二，mysql分表和分區有什麼區別呢
1，實現方式上
a），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
Php代碼
[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
Php代碼
[root@BlackGhost test]# cat alluser.MRG |more
user1
user2
#INSERT_METHOD=LAST
從上面我們可以看出，alluser.MRG裡面就存了一些分表的關系，以及插入數據的方式。可以把總表理解成一個外殼，或者是聯接池。
b），分區不一樣，一張大表進行分區後，他還是一張表，不會變成二張表，但是他存放數據的區塊變多了。
[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
Php代碼
[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有點像。分區後，還是一張，而不是多張表。
2，數據處理上
a），分表後，數據都是存放在分表裡，總表只是一個外殼，存取數據發生在一個一個的分表裡面。看下面的例子：
select * from alluser where id=』12′表面上看，是對表alluser進行操作的，其實不是的。是對alluser裡面的分表進行了操作。
b），分區呢，不存在分表的概念，分區只不過把存放數據的文件分成了許多小塊，分區後的表呢，還是一張表。數據處理還是由自己來完成。
3，提高性能上
a），分表後，單表的並發能力提高了，磁碟I/O性能也提高了。並發能力為什麼提高了呢，因為查尋一次所花的時間變短了，如果出現高並發的話，總表可以根據不同的查詢，將並發壓力分到不同的小表裡面。磁碟I/O性能怎麼搞高了呢，本來一個非常大的.MYD文件現在也分攤到各個小表的.MYD中去了。
b），mysql提出了分區的概念，我覺得就想突破磁碟I/O瓶頸，想提高磁碟的讀寫能力，來增加mysql性能。
在這一點上，分區和分表的測重點不同，分表重點是存取數據時，如何提高mysql並發能力上；而分區呢，如何突破磁碟的讀寫能力，從而達到提高mysql性能的目的。
4），實現的難易度上
a），分表的方法有很多，用merge來分表，是最簡單的一種方式。這種方式根分區難易度差不多，並且對程序代碼來說可以做到透明的。如果是用其他分表方式就比分區麻煩了。
b），分區實現是比較簡單的，建立分區表，根建平常的表沒什麼區別，並且對開代碼端來說是透明的。
三，mysql分表和分區有什麼聯系呢
1，都能提高mysql的性高，在高並發狀態下都有一個良好的表面。
2，分表和分區不矛盾，可以相互配合的，對於那些大訪問量，並且表數據比較多的表，我們可以採取分表和分區結合的方式（如果merge這種分表方式，不能和分區配合的話，可以用其他的分表試），訪問量不大，但是表數據很多的表，我們可以採取分區的方式等。
④ MySQL資料庫性能優化之分區分表分庫
分表是分散資料庫壓力的好方法。
分表，最直白的意思，就是將一個表結構分為多個表，然後，可以再同一個庫里，也可以放到不同的庫。
當然，首先要知道什麼情況下，才需要分表。個人覺得單表記錄條數達到百萬到千萬級別時就要使用分表了。
分表的分類
**1、縱向分表**
將本來可以在同一個表的內容，人為劃分為多個表。（所謂的本來，是指按照關系型資料庫的第三範式要求，是應該在同一個表的。）
分表理由：根據數據的活躍度進行分離，（因為不同活躍的數據，處理方式是不同的）
案例：
對於一個博客系統，文章標題，作者，分類，創建時間等，是變化頻率慢，查詢次數多，而且最好有很好的實時性的數據，我們把它叫做冷數據。而博客的瀏覽量，回復數等，類似的統計信息，或者別的變化頻率比較高的數據，我們把它叫做活躍數據。所以，在進行資料庫結構設計的時候，就應該考慮分表，首先是縱向分表的處理。
這樣縱向分表後：
首先存儲引擎的使用不同，冷數據使用MyIsam 可以有更好的查詢數據。活躍數據，可以使用Innodb ,可以有更好的更新速度。
其次，對冷數據進行更多的從庫配置，因為更多的操作時查詢，這樣來加快查詢速度。對熱數據，可以相對有更多的主庫的橫向分表處理。
其實，對於一些特殊的活躍數據，也可以考慮使用memcache ,redis之類的緩存，等累計到一定量再去更新資料庫。或者mongodb 一類的nosql 資料庫，這里只是舉例，就先不說這個。
**2、橫向分表**
字面意思，就可以看出來，是把大的表結構，橫向切割為同樣結構的不同表，如，用戶信息表，user_1,user_2等。表結構是完全一樣，但是，根據某些特定的規則來劃分的表，如根據用戶ID來取模劃分。
分表理由：根據數據量的規模來劃分，保證單表的容量不會太大，從而來保證單表的查詢等處理能力。
案例：同上面的例子，博客系統。當博客的量達到很大時候，就應該採取橫向分割來降低每個單表的壓力，來提升性能。例如博客的冷數據表，假如分為100個表，當同時有100萬個用戶在瀏覽時，如果是單表的話，會進行100萬次請求，而現在分表後，就可能是每個表進行1萬個數據的請求（因為，不可能絕對的平均，只是假設），這樣壓力就降低了很多很多。
延伸：為什麼要分表和分區？
日常開發中我們經常會遇到大表的情況，所謂的大表是指存儲了百萬級乃至千萬級條記錄的表。這樣的表過於龐大，導致資料庫在查詢和插入的時候耗時太長，性能低下，如果涉及聯合查詢的情況，性能會更加糟糕。分表和表分區的目的就是減少資料庫的負擔，提高資料庫的效率，通常點來講就是提高表的增刪改查效率。
什麼是分表？
分表是將一個大表按照一定的規則分解成多張具有獨立存儲空間的實體表，我們可以稱為子表，每個表都對應三個文件，MYD數據文件，.MYI索引文件，.frm表結構文件。這些子表可以分布在同一塊磁碟上，也可以在不同的機器上。app讀寫的時候根據事先定義好的規則得到對應的子表名，然後去操作它。
什麼是分區？
分區和分表相似，都是按照規則分解表。不同在於分表將大表分解為若干個獨立的實體表，而分區是將數據分段劃分在多個位置存放，可以是同一塊磁碟也可以在不同的機器。分區後，表面上還是一張表，但數據散列到多個位置了。app讀寫的時候操作的還是大表名字，db自動去組織分區的數據。
**MySQL分表和分區有什麼聯系呢？**
1、都能提高mysql的性高，在高並發狀態下都有一個良好的表現。
2、分表和分區不矛盾，可以相互配合的，對於那些大訪問量，並且表數據比較多的表，我們可以採取分表和分區結合的方式（如果merge這種分表方式，不能和分區配合的話，可以用其他的分表試），訪問量不大，但是表數據很多的表，我們可以採取分區的方式等。
3、分表技術是比較麻煩的，需要手動去創建子表，app服務端讀寫時候需要計運算元表名。採用merge好一些，但也要創建子表和配置子表間的union關系。
4、表分區相對於分表，操作方便，不需要創建子表。
我們知道對於大型的互聯網應用，資料庫單表的數據量可能達到千萬甚至上億級別，同時面臨這高並發的壓力。Master-Slave結構只能對資料庫的讀能力進行擴展，寫操作還是集中在Master中，Master並不能無限制的掛接Slave庫，如果需要對資料庫的吞吐能力進行進一步的擴展，可以考慮採用分庫分表的策略。
**1、分表**
在分表之前，首先要選中合適的分表策略（以哪個字典為分表欄位，需要將數據分為多少張表），使數據能夠均衡的分布在多張表中，並且不影響正常的查詢。在企業級應用中，往往使用org_id(組織主鍵)做為分表欄位，在互聯網應用中往往是userid。在確定分表策略後，當數據進行存儲及查詢時，需要確定到哪張表裡去查找數據，
數據存放的數據表 = 分表欄位的內容 % 分表數量
**2、分庫**
分表能夠解決單表數據量過大帶來的查詢效率下降的問題，但是不能給資料庫的並發訪問帶來質的提升，面對高並發的寫訪問，當Master無法承擔高並發的寫入請求時，不管如何擴展Slave伺服器，都沒有意義了。我們通過對資料庫進行拆分，來提高資料庫的寫入能力，即所謂的分庫。分庫採用對關鍵字取模的方式，對資料庫進行路由。
數據存放的資料庫=分庫欄位的內容%資料庫的數量
**3、即分表又分庫**
資料庫分表可以解決單表海量數據的查詢性能問題，分庫可以解決單台資料庫的並發訪問壓力問題。
當資料庫同時面臨海量數據存儲和高並發訪問的時候，需要同時採取分表和分庫策略。一般分表分庫策略如下：
中間變數 = 關鍵字%（資料庫數量*單庫數據表數量）
庫 = 取整（中間變數/單庫數據表數量）
表 = （中間變數%單庫數據表數量）
實例：
1、分庫分表
很明顯，一個主表（也就是很重要的表，例如用戶表）無限制的增長勢必嚴重影響性能，分庫與分表是一個很不錯的解決途徑，也就是性能優化途徑，現在的案例是我們有一個1000多萬條記錄的用戶表members,查詢起來非常之慢，同事的做法是將其散列到100個表中，分別從members0到members99，然後根據mid分發記錄到這些表中，牛逼的代碼大概是這樣子：
復制代碼 代碼如下:
<?php
for($i=0;$i< 100; $i++ ){
//echo "CREATE TABLE db2.members{$i} LIKE db1.members
";
echo "INSERT INTO members{$i} SELECT * FROM members WHERE mid%100={$i}
";
}
?>
2、不停機修改mysql表結構
同樣還是members表，前期設計的表結構不盡合理，隨著資料庫不斷運行，其冗餘數據也是增長巨大，同事使用了下面的方法來處理：
先創建一個臨時表：
/*創建臨時表*/
CREATE TABLE members_tmp LIKE members
然後修改members_tmp的表結構為新結構，接著使用上面那個for循環來導出數據，因為1000萬的數據一次性導出是不對的，mid是主鍵，一個區間一個區間的導，基本是一次導出5萬條吧，這里略去了
接著重命名將新表替換上去：
/*這是個頗為經典的語句哈*/
RENAME TABLE members TO members_bak,members_tmp TO members;
就是這樣，基本可以做到無損失，無需停機更新表結構，但實際上RENAME期間表是被鎖死的，所以選擇在線少的時候操作是一個技巧。經過這個操作，使得原先8G多的表，一下子變成了2G多。
⑤ 淺談mysql資料庫分庫分表那些事-億級數據存儲方案
mysql分庫分表一般有如下場景
其中1，2相對較容易實現,本文重點講講水平拆表和水平拆庫,以及基於mybatis插件方式實現水平拆分方案落地。
在 《聊一聊擴展欄位設計》 一文中有講解到基於KV水平存儲擴展欄位方案,這就是非常典型的可以水平分表的場景。主表和kv表是一對N關系,隨著主表數據量增長,KV表最大N倍線性增長。
這里我們以分KV表水平拆分為場景
對於kv擴展欄位查詢,只會根據id + key 或者 id 為條件的方式查詢,所以這里我們可以按照id 分片即可
分512張表(實際場景具體分多少表還得根據欄位增加的頻次而定)
分表後表名為kv_000 ~ kv_511
id % 512 = 1 .... 分到 kv_001,
id % 512 = 2 .... 分到 kv_002
依次類推!
水平分表相對比較容易,後面會講到基於mybatis插件實現方案
場景:以下我們基於博客文章表分庫場景來分析
目標:
表結構如下(節選部分欄位):
按照user_id sharding
假如分1024個庫,按照user_id % 1024 hash
user_id % 1024 = 1 分到db_001庫
user_id % 1024 = 2 分到db_002庫
依次類推
目前是2個節點,假如後期達到瓶頸,我們可以增加至4個節點
最多可以增加只1024個節點,性能線性增長
對於水平分表/分庫後,非shardingKey查詢首先得考慮到
基於mybatis分庫分表,一般常用的一種是基於spring AOP方式, 另外一種基於mybatis插件。其實兩種方式思路差不多。
為了比較直觀解決這個問題,我分別在Executor 和StatementHandler階段2個攔截器
實現動態數據源獲取介面
測試結果如下
由此可知,我們需要在Executor階段 切換數據源
對於分庫:
原始sql:
目標sql:
其中定義了三個註解
@useMaster 是否強制讀主
@shardingBy 分片標識
@DB 定義邏輯表名 庫名以及分片策略
1)編寫entity
Insert
select
以上順利實現mysql分庫,同樣的道理實現同時分庫分表也很容易實現。
此插件具體實現方案已開源: https://github.com/bytearch/mybatis-sharding
目錄如下:
mysql分庫分表,首先得找到瓶頸在哪裡(IO or CPU),是分庫還是分表,分多少？不能為了分庫分表而拆分。
原則上是盡量先垂直拆分 後 水平拆分。
以上基於mybatis插件分庫分表是一種實現思路,還有很多不完善的地方,
例如: