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名用戶數據，然后再對這些數據進行合並計算，才能得出結果。
上述整理於互聯網
3.數據庫優化有哪些? 分別需要注意什么?
1. SQL優化的原則是：將一次操作需要讀取的BLOCK數減到最低,即在最短的時間達到最大的數據吞吐量。
調整不良SQL通常可以從以下幾點切入：
檢查不良的SQL，考慮其寫法是否還有可優化內容
檢查子查詢 考慮SQL子查詢是否可以用簡單連接的方式進行重新書寫
檢查優化索引的使用
考慮數據庫的優化器
2. 避免出現SELECT * FROM table 語句，要明確查出的字段。
3. 在一個SQL語句中，如果一個where條件過濾的數據庫記錄越多，定位越准確，則該where條件越應該前移。
4. 查詢時盡可能使用索引覆蓋。即對SELECT的字段建立復合索引，這樣查詢時只進行索引掃描，不讀取數據塊。
5. 在判斷有無符合條件的記錄時建議不要用SELECT COUNT （*）和select top 1 語句。
6. 使用內層限定原則，在拼寫SQL語句時，將查詢條件分解、分類，並盡量在SQL語句的最里層進行限定，以減少數據的處理量。
7. 應絕對避免在order by子句中使用表達式。
8. 如果需要從關聯表讀數據，關聯的表一般不要超過7個。
9. 小心使用 IN 和 OR，需要注意In集合中的數據量。建議集合中的數據不超過200個。
10. <> 用 < 、 > 代替，>用>=代替，<用<=代替，這樣可以有效的利用索引。
11. 在查詢時盡量減少對多余數據的讀取包括多余的列與多余的行。
12. 對於復合索引要注意，例如在建立復合索引時列的順序是F1，F2，F3，則在where或order by子句中這些字段出現的順序要與建立索引時的字段順序一致，且必須包含第一列。只能是F1或F1，F2或F1，F2，F3。否則不會用到該索引。
13. 多表關聯查詢時，寫法必須遵循以下原則，這樣做有利於建立索引，提高查詢效率。格式如下select sum（table1.je） from table1 table1, table2 table2, table3 table3 where (table1的等值條件（=）) and (table1的非等值條件) and (table2與table1的關聯條件) and (table2的等值條件) and (table2的非等值條件) and (table3與table2的關聯條件) and (table3的等值條件) and (table3的非等值條件)。
注:關於多表查詢時from 后面表的出現順序對效率的影響還有待研究。
14. 子查詢問題。對於能用連接方式或者視圖方式實現的功能，不要用子查詢。例如：select name from customer where customer_id in ( select customer_id from order where money>1000)。應該用如下語句代替：select name from customer inner join order on customer.customer_id=order.customer_id where order.money>100。
15. 在WHERE 子句中，避免對列的四則運算，特別是where 條件的左邊，嚴禁使用運算與函數對列進行處理。比如有些地方 substring 可以用like代替。
16. 如果在語句中有not in（in）操作，應考慮用not exists（exists）來重寫,最好的辦法是使用外連接實現。
17. 對一個業務過程的處理，應該使事物的開始與結束之間的時間間隔越短越好，原則上做到數據庫的讀操作在前面完成，數據庫寫操作在后面完成，避免交叉。
18. 請小心不要對過多的列使用列函數和order by,group by等，謹慎使用disti軟件開發t。
19. 用union all 代替 union，數據庫執行union操作，首先先分別執行union兩端的查詢，將其放在臨時表中，然后在對其進行排序，過濾重復的記錄。
當已知的業務邏輯決定query A和query B中不會有重復記錄時，應該用union all代替union，以提高查詢效率。
數據更新的效率
1. 在一個事物中，對同一個表的多個insert語句應該集中在一起執行。
2. 在一個業務過程中，盡量的使insert,update,delete語句在業務結束前執行，以減少死鎖的可能性。
數據庫物理規划的效率
為了避免I/O的沖突，我們在設計數據庫物理規划時應該遵循幾條基本的原則(以ORACLE舉例)：
table和index分離：table和index應該分別放在不同的tablespace中。
Rollback Segment的分離：Rollback Segment應該放在獨立的Tablespace中。
System Tablespace的分離：System Tablespace中不允許放置任何用戶的object。（mssql中primary filegroup中不允許放置任何用戶的object）
Temp Tablesace的分離：建立單獨的Temp Tablespace，並為每個user指定default Temp Tablespace
避免碎片：但segment中出現大量的碎片時，會導致讀數據時需要訪問的block數量的增加。對經常發生DML操作的segemeng來說，碎片是不能完全避免的。所以，我們應該將經常做DML操作的表和很少發生變化的表分離在不同的Tablespace中。
當我們遵循了以上原則后，仍然發現有I/O沖突存在，我們可以用數據分離的方法來解決。
連接Table的分離：在實際應用中經常做連接查詢的Table，可以將其分離在不同的Taclespace中，以減少I/O沖突。
使用分區：對數據量很大的Table和Index使用分區，放在不同的Tablespace中。
在實際的物理存儲中，建議使用RAID。日志文件應放在單獨的磁盤中。