資料庫分割試
Mysql是目前互聯網使用最廣的關系資料庫，關系資料庫的本質是將問題分解為多個分類然後通過關系來查詢。 一個經典的問題是用戶借書，三張表，一個用戶，一個書，一個借書的關系表。當需要查詢某個用戶借書情況或者是書被那些人借了，就用關系查詢來實現。
關系資料庫範式
來自英文Normal form，簡稱NF。要想設計—個好的關系，必須使關系滿足一定的約束條件，滿足這些規范的資料庫是簡潔的、結構明晰的，同時，不會發生插入(insert)、刪除(delete)和更新(update)操作異常。總共有六種範式：第一範式（1NF）、第二範式（2NF）、 第三範式 （3NF）、巴斯-科德範式（BCNF）、 第四範式 (4NF）和 第五範式 （5NF，又稱完美範式）。
1NF是指資料庫表的每一列都是不可分割的原子數據項。2NF必須滿足1NF，要求資料庫表中的每行記錄必須可以被唯一地區分。3NF在2NF基礎上，任何非主 屬性 不依賴於其它非主屬性（在2NF基礎上消除傳遞依賴）。BCNF是在3NF基礎上，任何非主屬性不能對主鍵子集依賴（在3NF基礎上消除對主碼子集的依賴）， 滿足BCNF不再會有任何由於函數依賴導致的異常，但是我們還可能會遇到由於多值依賴導致的異常。4NF的定義很簡單：已經是BC範式，並且不包含多值依賴關系。5NF處理的是無損連接問題，這個範式基本沒有實際意義，因為無損連接很少出現，而且難以察覺。而域鍵範式試圖定義一個終極範式，該範式考慮所有的依賴和約束類型，但是實用價值也是最小的，只存在理論研究中。
Catalog和Schema
是資料庫對象命名空間中的層次，主要用來解決命名沖突的問題。從概念上說，一個資料庫系統包含多個Catalog，每個Catalog又包含多個Schema，而每個Schema又包含多個資料庫對象（表、視圖、欄位等）。但是Mysql的資料庫名就是Schema，不支持Catalog。
Mysql的資料庫引擎主要有兩種MyISAM和InnoDB，MyISAM支持全文檢索，InnoDB支持事務。
SQL中的通配符『%』代表任意字元出現任意次數。『_』代表任意字元出現一次。SQL與正則表達式結合查詢一般用在WHERE table_name REGEXP '^12.34'。子查詢是從里到外執行。
資料庫聯結（join）涉及到外鍵，外鍵是指一個表的列是另一個表的主鍵，那麼它就是外鍵。笛卡爾積聯結（不指定聯結條件時）生成的記錄條目是單純的第一個表的行乘以第二個表的列數。用得最多的是等值聯結也叫內部聯結。
高級聯結還有自連接，是指查詢中的兩張表是同一張表，它通常作為外部語句用來代替從相同表中檢索數據時使用的子查詢。自然聯結使每個列只返回一次。外部聯結是指聯結包含了那些在相關表中沒有關聯行的行。例如列出所有產品及其訂購數量，包括沒有人訂購的產品。LEFT OUTER JOIN指選擇左邊表的所有行。
組合查詢是指採用UNION等將兩個查詢結果取並集。
視圖是查看存儲在別處的數據的一種工具，它本身並不包含數據，因此表的數據修改了，視圖返回的數據也將隨之修改，因此如果使用了復雜或嵌套視圖會對性能有較大的影響。視圖的作用之一是隱藏復雜的SQL通常會涉及到聯結查詢。
存儲過程類似於批處理，包含了一條或多條SQL語句。語法：
CREATE PROCEDURE name（）
BEGIN
SQL
END
-------------------------
CALL name（）//來調用存儲過程
游標有DECLARE定義，游標與存儲過程是綁定的，存儲過程處理完成，游標就會消失。游標被打開後可以使用FETCH語句訪問每一行。
觸發器是在某個時間發生時自動執行某條SQL語句。語法：
CREATE TRIGGER name AFTER INSERT ON talbe_name FOR EACH ROW
事務處理可以維護資料庫的完整性，保證批量的操作要麼完全執行，要麼完全不執行。包括事務、回退、提交、保留點幾個關鍵術語。ROLLBACK只能在一個事務處理內使用。他不能回退CREATE和DROP操作。使用COMMIT保證事務提交。復雜的事務處理需要部分提交或回退，因此我們需要使用保留點SAVEPOINT。可以使用ROLLBACK TO savepoint_name。保留點越多越好。保留點在事務執行完成後自動釋放。
B. 資料庫三大範式究竟是什麼
資料庫範式1NF 2NF 3NF BCNF(實例）
設計範式（範式,資料庫設計範式,資料庫的設計範式）是符合某一種級別的關系模式的集合。構造資料庫必須遵循一定的規則。在關系資料庫中，這種規則就是範式。關系資料庫中的關系必須滿足一定的要求，即滿足不同的範式。目前關系資料庫有六種範式：第一範式（1NF）、第二範式（2NF）、第三範式（3NF）、第四範式（4NF）、第五範式（5NF）和第六範式（6NF）。滿足最低要求的範式是第一範式（1NF）。在第一範式的基礎上進一步滿足更多要求的稱為第二範式（2NF），其餘範式以次類推。一般說來，資料庫只需滿足第三範式（3NF）就行了。下面我們舉例介紹第一範式（1NF）、第二範式（2NF）和第三範式（3NF）。
在創建一個資料庫的過程中，范化是將其轉化為一些表的過程，這種方法可以使從資料庫得到的結果更加明確。這樣可能使資料庫產生重復數據，從而導致創建多餘的表。范化是在識別資料庫中的數據元素、關系，以及定義所需的表和各表中的項目這些初始工作之後的一個細化的過程。
下面是范化的一個例子 Customer Item purchased Purchase price Thomas Shirt $40 Maria Tennis shoes $35 Evelyn Shirt $40 Pajaro Trousers $25
如果上面這個表用於保存物品的價格，而你想要刪除其中的一個顧客，這時你就必須同時刪除一個價格。范化就是要解決這個問題，你可以將這個表化為兩個表，一個用於存儲每個顧客和他所買物品的信息，另一個用於存儲每件產品和其價格的信息，這樣對其中一個表做添加或刪除操作就不會影響另一個表。
關系資料庫的幾種設計範式介紹
1 第一範式（1NF）
在任何一個關系資料庫中，第一範式（1NF）是對關系模式的基本要求，不滿足第一範式（1NF）的資料庫就不是關系資料庫。
所謂第一範式（1NF）是指資料庫表的每一列都是不可分割的基本數據項，同一列中不能有多個值，即實體中的某個屬性不能有多個值或者不能有重復的屬性。如果出現重復的屬性，就可能需要定義一個新的實體，新的實體由重復的屬性構成，新實體與原實體之間為一對多關系。在第一範式（1NF）中表的每一行只包含一個實例的信息。例如，對於圖3-2 中的員工信息表，不能將員工信息都放在一列中顯示，也不能將其中的兩列或多列在一列中顯示；員工信息表的每一行只表示一個員工的信息，一個員工的信息在表中只出現一次。簡而言之，第一範式就是無重復的列。
2 第二範式（2NF）
第二範式（2NF）是在第一範式（1NF）的基礎上建立起來的，即滿足第二範式（2NF）必須先滿足第一範式（1NF）。第二範式（2NF）要求資料庫表中的每個實例或行必須可以被惟一地區分。為實現區分通常需要為表加上一個列，以存儲各個實例的惟一標識。如圖3-2 員工信息表中加上了員工編號（emp_id）列，因為每個員工的員工編號是惟一的，因此每個員工可以被惟一區分。這個惟一屬性列被稱為主關鍵字或主鍵、主碼。
第二範式（2NF）要求實體的屬性完全依賴於主關鍵字。所謂完全依賴是指不能存在僅依賴主關鍵字一部分的屬性，如果存在，那麼這個屬性和主關鍵字的這一部分應該分離出來形成一個新的實體，新實體與原實體之間是一對多的關系。為實現區分通常需要為表加上一個列，以存儲各個實例的惟一標識。簡而言之，第二範式就是非主屬性非部分依賴於主關鍵字。
3 第三範式（3NF）
滿足第三範式（3NF）必須先滿足第二範式（2NF）。簡而言之，第三範式（3NF）要求一個資料庫表中不包含已在其它表中已包含的非主關鍵字信息。例如，存在一個部門信息表，其中每個部門有部門編號（dept_id）、部門名稱、部門簡介等信息。那麼在圖3-2的員工信息表中列出部門編號後就不能再將部門名稱、部門簡介等與部門有關的信息再加入員工信息表中。如果不存在部門信息表，則根據第三範式（3NF）也應該構建它，否則就會有大量的數據冗餘。簡而言之，第三範式就是屬性不依賴於其它非主屬性。
資料庫設計三大範式應用實例剖析
資料庫的設計範式是資料庫設計所需要滿足的規范，滿足這些規范的資料庫是簡潔的、結構明晰的，同時，不會發生插入（insert）、刪除（delete）和更新（update）操作異常。反之則是亂七八糟，不僅給資料庫的編程人員製造麻煩，而且面目可憎，可能存儲了大量不需要的冗餘信息。
設計範式是不是很難懂呢？非也，大學教材上給我們一堆數學公式我們當然看不懂，也記不住。所以我們很多人就根本不按照範式來設計資料庫。
實質上，設計範式用很形象、很簡潔的話語就能說清楚，道明白。本文將對範式進行通俗地說明，並以筆者曾經設計的一個簡單論壇的資料庫為例來講解怎樣將這些範式應用於實際工程。
範式說明
第一範式（1NF）：資料庫表中的欄位都是單一屬性的，不可再分。這個單一屬性由基本類型構成，包括整型、實數、字元型、邏輯型、日期型等。
例如，如下的資料庫表是符合第一範式的：
欄位1 欄位2 欄位3 欄位4
而這樣的資料庫表是不符合第一範式的：
欄位1 欄位2 欄位3 欄位4
欄位3.1 欄位3.2
很顯然，在當前的任何關系資料庫管理系統（DBMS）中，傻瓜也不可能做出不符合第一範式的資料庫，因為這些DBMS不允許你把資料庫表的一列再分成二列或多列。因此，你想在現有的DBMS中設計出不符合第一範式的資料庫都是不可能的。
第二範式（2NF）：資料庫表中不存在非關鍵欄位對任一候選關鍵欄位的部分函數依賴（部分函數依賴指的是存在組合關鍵字中的某些欄位決定非關鍵欄位的情況），也即所有非關鍵欄位都完全依賴於任意一組候選關鍵字。
假定選課關系表為SelectCourse(學號, 姓名, 年齡, 課程名稱, 成績, 學分)，關鍵字為組合關鍵字(學號, 課程名稱)，因為存在如下決定關系：
(學號, 課程名稱) → (姓名, 年齡, 成績, 學分)
這個資料庫表不滿足第二範式，因為存在如下決定關系：
(課程名稱) → (學分)
(學號) → (姓名, 年齡)
即存在組合關鍵字中的欄位決定非關鍵字的情況。
由於不符合2NF，這個選課關系表會存在如下問題：
(1) 數據冗餘：
同一門課程由n個學生選修，"學分"就重復n-1次；同一個學生選修了m門課程，姓名和年齡就重復了m-1次。
(2) 更新異常：
若調整了某門課程的學分，數據表中所有行的"學分"值都要更新，否則會出現同一門課程學分不同的情況。
(3) 插入異常：
假設要開設一門新的課程，暫時還沒有人選修。這樣，由於還沒有"學號"關鍵字，課程名稱和學分也無法記錄入資料庫。
(4) 刪除異常：
假設一批學生已經完成課程的選修，這些選修記錄就應該從資料庫表中刪除。但是，與此同時，課程名稱和學分信息也被刪除了。很顯然，這也會導致插入異常。
把選課關系表SelectCourse改為如下三個表：
學生：Student(學號, 姓名, 年齡)；
課程：Course(課程名稱, 學分)；
選課關系：SelectCourse(學號, 課程名稱, 成績)。
這樣的資料庫表是符合第二範式的， 消除了數據冗餘、更新異常、插入異常和刪除異常。
另外，所有單關鍵字的資料庫表都符合第二範式，因為不可能存在組合關鍵字。
第三範式（3NF）：在第二範式的基礎上，數據表中如果不存在非關鍵欄位對任一候選關鍵欄位的傳遞函數依賴則符合第三範式。所謂傳遞函數依賴，指的是如果存在"A → B → C"的決定關系，則C傳遞函數依賴於A。因此，滿足第三範式的資料庫表應該不存在如下依賴關系：
關鍵欄位 → 非關鍵欄位x → 非關鍵欄位y
假定學生關系表為Student(學號, 姓名, 年齡, 所在學院, 學院地點, 學院電話)，關鍵字為單一關鍵字"學號"，因為存在如下決定關系：
(學號) → (姓名, 年齡, 所在學院, 學院地點, 學院電話)
這個資料庫是符合2NF的，但是不符合3NF，因為存在如下決定關系：
(學號) → (所在學院) → (學院地點, 學院電話)
即存在非關鍵欄位"學院地點"、"學院電話"對關鍵欄位"學號"的傳遞函數依賴。
它也會存在數據冗餘、更新異常、插入異常和刪除異常的情況，讀者可自行分析得知。
把學生關系表分為如下兩個表：
學生：(學號, 姓名, 年齡, 所在學院)；
學院：(學院, 地點, 電話)。
這樣的資料庫表是符合第三範式的，消除了數據冗餘、更新異常、插入異常和刪除異常。
鮑依斯-科得範式（BCNF）：在第三範式的基礎上，資料庫表中如果不存在任何欄位對任一候選關鍵欄位的傳遞函數依賴則符合第三範式。
假設倉庫管理關系表為StorehouseManage(倉庫ID, 存儲物品ID, 管理員ID, 數量)，且有一個管理員只在一個倉庫工作；一個倉庫可以存儲多種物品。這個資料庫表中存在如下決定關系：
(倉庫ID, 存儲物品ID) →(管理員ID, 數量)
(管理員ID, 存儲物品ID) → (倉庫ID, 數量)
所以，(倉庫ID, 存儲物品ID)和(管理員ID, 存儲物品ID)都是StorehouseManage的候選關鍵字，表中的唯一非關鍵欄位為數量，它是符合第三範式的。但是，由於存在如下決定關系：
(倉庫ID) → (管理員ID)
(管理員ID) → (倉庫ID)
即存在關鍵欄位決定關鍵欄位的情況，所以其不符合BCNF範式。它會出現如下異常情況：
(1) 刪除異常：
當倉庫被清空後，所有"存儲物品ID"和"數量"信息被刪除的同時，"倉庫ID"和"管理員ID"信息也被刪除了。
(2) 插入異常：
當倉庫沒有存儲任何物品時，無法給倉庫分配管理員。
(3) 更新異常：
如果倉庫換了管理員，則表中所有行的管理員ID都要修改。
把倉庫管理關系表分解為二個關系表：
倉庫管理：StorehouseManage(倉庫ID, 管理員ID)；
倉庫：Storehouse(倉庫ID, 存儲物品ID, 數量)。
這樣的資料庫表是符合BCNF範式的，消除了刪除異常、插入異常和更新異常。
範式應用
我們來逐步搞定一個論壇的資料庫，有如下信息：
（1） 用戶：用戶名，email，主頁，電話，聯系地址
（2） 帖子：發帖標題，發帖內容，回復標題，回復內容
第一次我們將資料庫設計為僅僅存在表：
用戶名 email 主頁 電話 聯系地址 發帖標題 發帖內容 回復標題 回復內容
這個資料庫表符合第一範式，但是沒有任何一組候選關鍵字能決定資料庫表的整行，唯一的關鍵欄位用戶名也不能完全決定整個元組。我們需要增加"發帖ID"、"回復ID"欄位，即將表修改為：
用戶名 email 主頁 電話 聯系地址 發帖ID 發帖標題 發帖內容 回復ID 回復標題 回復內容
這樣數據表中的關鍵字(用戶名，發帖ID，回復ID)能決定整行：
(用戶名,發帖ID,回復ID) → (email,主頁,電話,聯系地址,發帖標題,發帖內容,回復標題,回復內容)
但是，這樣的設計不符合第二範式，因為存在如下決定關系：
(用戶名) → (email,主頁,電話,聯系地址)
(發帖ID) → (發帖標題,發帖內容)
(回復ID) → (回復標題,回復內容)
即非關鍵欄位部分函數依賴於候選關鍵欄位，很明顯，這個設計會導致大量的數據冗餘和操作異常。
我們將資料庫表分解為（帶下劃線的為關鍵字）：
（1） 用戶信息：用戶名，email，主頁，電話，聯系地址
（2） 帖子信息：發帖ID，標題，內容
（3） 回復信息：回復ID，標題，內容
（4） 發貼：用戶名，發帖ID
（5） 回復：發帖ID，回復ID
這樣的設計是滿足第1、2、3範式和BCNF範式要求的，但是這樣的設計是不是最好的呢？
不一定。
觀察可知，第4項"發帖"中的"用戶名"和"發帖ID"之間是1：N的關系，因此我們可以把"發帖"合並到第2項的"帖子信息"中；第5項"回復"中的"發帖ID"和"回復ID"之間也是1：N的關系，因此我們可以把"回復"合並到第3項的"回復信息"中。這樣可以一定量地減少數據冗餘，新的設計為：
（1） 用戶信息：用戶名，email，主頁，電話，聯系地址
（2） 帖子信息：用戶名，發帖ID，標題，內容
（3） 回復信息：發帖ID，回復ID，標題，內容
資料庫表1顯然滿足所有範式的要求；
資料庫表2中存在非關鍵欄位"標題"、"內容"對關鍵欄位"發帖ID"的部分函數依賴，即不滿足第二範式的要求，但是這一設計並不會導致數據冗餘和操作異常；
資料庫表3中也存在非關鍵欄位"標題"、"內容"對關鍵欄位"回復ID"的部分函數依賴，也不滿足第二範式的要求，但是與資料庫表2相似，這一設計也不會導致數據冗餘和操作異常。
由此可以看出，並不一定要強行滿足範式的要求，對於1：N關系，當1的一邊合並到N的那邊後，N的那邊就不再滿足第二範式了，但是這種設計反而比較好！
對於M：N的關系，不能將M一邊或N一邊合並到另一邊去，這樣會導致不符合範式要求，同時導致操作異常和數據冗餘。
對於1：1的關系，我們可以將左邊的1或者右邊的1合並到另一邊去，設計導致不符合範式要求，但是並不會導致操作異常和數據冗餘。
結論
滿足範式要求的資料庫設計是結構清晰的，同時可避免數據冗餘和操作異常。這並意味著不符合範式要求的設計一定是錯誤的，在資料庫表中存在1：1或1：N關系這種較特殊的情況下，合並導致的不符合範式要求反而是合理的。
在我們設計資料庫的時候，一定要時刻考慮範式的要求。
__________________________________________________________________
應該是第二種說法，只聽說過1NF,2NF,3NF這么分的，我大學教科書上也這么寫的
C. 資料庫中表分割和表分區的區別是什麼
個人認為理論上使用表分割在性能上應該和建立表分區查不多，但是，表分割對於所有的資料庫都適用，而表分區只能用於oracle這樣的特定的資料庫；表分區屬於資料庫物理設計，表分割屬於邏輯設計。
表分區：
表分區是ORACLE對於非常大的表進行優化的一種有效方法, 是非常有效的一種手段, 在很多情況下,比你說的表分割更有效,比如,有一個代碼表,使用分區表把100萬紀錄分在10個分區中(ID 每從1到10萬為一個分區),那樣寫查詢語句的時候,只要給出查詢條件中所需要的代碼,ORACLE自動會定位到對應的分區進行查詢,大大降低的查詢時間. 而採用表分割,那必須先根據查詢的代碼指定所要查詢的表,才能找到相應的紀錄. 而且,如果有下面這樣的語句,查詢的條件是跨分區的:
SELECT * FROM MYTABLE WHERE ID BETWEEN 99000 AND 10111;
在分區表中是非常容易實現的,ORACLE會自動在兩個分區中查詢;而採用表分割的話是否必須寫成兩個查詢語句在UNION ALL。
事實上,大型的資料庫都有對大表的特殊處理方式(類似於分區表),如果太強調可移植性而放棄這些最重要的特性的話,那性能很可能受到很大的影響.
即便是oracle資料庫，當數據量很大時，用分表比用表分區要快些，尤其是在表用到group by求和等操作。
我也認為表分區要好一些，也就是一般說來的分區表，對這些表操作起來有很多強大的功能，說他強大主要是體現在對與表中有海量數據的情況之下的，試問大家一個其中有1億條記錄的表你是否會經常的將其移植到其他資料庫系統當中去呢？
表分區基於物理存儲，還有就是基於分區的索引可以使用，很不錯的，當然，這些都是在海量數據情況之下的比較，但是如果真要是數據量不大的情況下比較，我想要比較分區表和表分割就沒什麼意思了。
表分區的效果對硬體有所依賴，而且效果恐怕不如諸位想像中那麼好。我做過一點測試，很失望。
而表分割的效率提升在很多時候（不是所有時候）是很明顯的。
當然這都是在巨型表的前提下討論，縮小表和索引的規模有利於提高效率，這正是分割表的特點。
表分割：
1、水平分割：根據一列或多列數據的值把數據行放到兩個獨立的表中。
水平分割通常在下面的情況下使用:A 表很大，分割後可以降低在查詢時需要讀的數據和索引的頁數，同時也降低了索引的層數，提高查詢速度。B 表中的數據本來就有獨立性，例如表中分別記錄各個地區的數據或不同時期的數據，特別是有些數據常用，而另外一些數據不常用。C需要把數據存放到多個介質上。
例如法規表law就可以分成兩個表active－law和 inactive－law。activea－authors表中的內容是正生效的法規，是經常使用的，而inactive－law表則使已經作廢的法規，不常被查詢。水平分割會給應用增加復雜度，它通常在查詢時需要多個表名，查詢所有數據需要union操作。在許多資料庫應用中，這種復雜性會超過它帶來的優點，因為只要索引關鍵字不大，則在索引用於查詢時，表中增加兩到三倍數據量，查詢時也就增加讀一個索引層的磁碟次數。
2、垂直分割：把主碼和一些列放到一個表，然後把主碼和另外的列放到另一個表中。
如果一個表中某些列常用，而另外一些列不常用，則可以採用垂直分割，另外垂直分割可以使得數據行變小，一個數據頁就能存放更多的數據，在查詢時就會減少I/O 次數。其缺點是需要管理冗餘列，查詢所有數據需要join操作。
D. 資料庫為什麼要分庫分表
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名用戶數據，然後再對這些數據進行合並計算，才能得出結果。
E. 資料庫中視圖的好處是什麼
1、視點集中：
視圖集中即是使用戶只關心它感興趣的某些特定數據和他們所負責的特定任務。
2.、簡化用戶的相關操作：
因為在定義視圖時，若視圖本身就是一個復雜查詢的結果集，這樣在每一次執行相同的查詢時，不必重新寫這些復雜的查詢語句，只要一條簡單的查詢視圖語句即可。可見視圖向用戶隱藏了表與表之間的復雜的連接操作。
3、定製數據：
視圖能夠實現讓不同的用戶以不同的方式看到不同或相同的數據集。因此，當有許多不同水平的用戶共用同一資料庫時，這顯得極為重要。
4、合並分割數據：
視圖可以重新保持原有的結構關系，從而使外模式保持不變，原有的應用程序仍可以通過視圖來重載數據。
5、安全性高：
視圖可以作為一種安全機制。通過視圖用戶只能查看和修改他們所能看到的數據，如果某一用戶想要訪問視圖的結果集，必須授予其訪問許可權。視圖所引用表的訪問許可權與視圖許可權的設置互不影響。
(5)資料庫分割試擴展閱讀：
視圖的特點：
1、視圖通常也被稱為子查詢，是從一個或多個表導出的虛擬的表，其內容由查詢定義。具有普通表的結構，但是不實現數據存儲；
2、對視圖的修改：單表視圖一般用於查詢和修改，會改變基本表的數據；
3、多表視圖一般用於查詢，不會改變基本表的數據；
4、視圖可以使應用程序和資料庫表在一定程度上獨立。如果沒有視圖，應用一定是建立在表上的，有了視圖之後，程序可以建立在視圖之上，從而程序與資料庫表被視圖分割開來。