個人的觀點，這種大表的優化，不一定上來就要分庫分表，因為表一旦被拆分，開發、運維的復雜度會直線上升，而大多數公司是欠缺這種能力的。所以MySQL中幾百萬甚至小幾千萬的表，先考慮做單表的優化。
單表優化
單表優化可以從這幾個角度出發：
表分區：MySQL在5.1之後才有的，可以看做是水平拆分，分區表需要在建表的需要加上分區參數，用戶需要在建表的時候加上分區參數；分區表底層由多個物理子表組成，但是對於代碼來說，分區表是透明的；SQL中的條件中最好能帶上分區條件的列，這樣可以定位到少量的分區上，否則就會掃描全部分區。
讀寫分離：最常用的櫻桐優化手段，寫主庫讀從庫；
增加緩存：主要的思想就是減少對資料庫的訪問，緩存可以在整個架構中的很多地方，比如：資料庫本身有就緩存，客戶端緩存，資料庫訪問層對SQL語句的緩存，應用程序內的緩存，第三方緩存（如Redis等）；
欄位設計：單表不要有太多欄位；VARCHAR的長度盡量只分配真正需要的空間；盡量使用TIMESTAMP而非DATETIME；避免使用NULL，可以通過設置默認值解決。
索引優化：索引不是越多越好，針對性地建立索引，索引會加速查詢，但是對新增、修改、刪除會造成一定的影響；值域很少的欄位不適合建索引；盡量不用UNIQUE，不要設置外鍵，由程序保證；
SQL優化：盡量使用索引，也要保證不要因為錯誤的寫法導致索引失效；比如：避免前導模糊查詢，避免隱式轉換，避免等號左邊做函數運算，in中的元素不宜過多等等；
NoSQL：有一些場景，可以拋棄MySQL等關系型資料庫，擁抱NoSQL；比如：統計類、日誌類、弱結構化的數據；事務要求低的場景。
表拆分
數據量進一步增大的時候，就不得不考慮表拆分的問題了：
垂直拆分：垂直拆分的意思就是把一個欄位較多的表，拆分成多個欄位較少的表；上文中也說過單表的欄位不宜過多，如果初期的表結構設計的就很好，就不會有垂直拆分的問題了；一般來說，MySQL單表的欄位最好不要超過二三十個。
水平拆分：就是我們常說的分庫分表了；分表，解決了單表數據過大的問題，但是畢竟還在同一台資料庫伺服器上，所以明頌裂IO、CPU、網路方面的壓力，並不會得到徹底的緩解，這個可以通過分庫來解決。水平拆分優點很明顯，可以利用多台資料庫伺服器的資源，提高了系統的負載能力；缺點是邏輯會變得復雜，跨節點的數據關聯性能差，維護難度大（特別是擴容的時候）。
希望我的回答，能夠幫助到你！我將持續分享Java開發、架構激閉設計、程序員職業發展等方面的見解。
㈡ 如何設計一個帶有多級別的資料庫表結構
表結構如下：
ID(int，主鍵，自動生成)
name(varchar20，省名或城市名)
parentID(int，父ID：為省時此列為0，為市時此列對應省的ID列的指)
sortNum(int，排序編號：可以按照編號值有小到大排列)
舉例：
ID name parentID sortNum
1 山東 0 0
2 浙江 0 0
3 濟南 1 0
4 青島 1 0
5 杭州 2 0
....
㈢ 大型資料庫的設計原則與開發技巧
隨著計算機技術越來越廣泛地應用於國民經濟的各個領域 在計算機硬體不斷微型化的同時 應用系統向著復雜化 大型化的方向發展 資料庫是整個系統的核心 它的設計直接關系系統執行的效率和系統的穩定性 因此在軟體系統開發中 資料庫設計應遵循必要的資料庫範式理論 以減少冗餘 保證數據的完整性與正確性 只有在合適的資料庫產品上設計出合理的資料庫模型 才能降低整個系統的編程和維護難度 提高系統的實際運行效率 雖然對於小項目或中等規模的項目開發人員可以很容易地利用範式理論設計出一套符合要求的資料庫 但對於一個包含大型資料庫的軟體項目 就必須有一套完整的設計原則與技巧
一 成立數據小組
大型資料庫數據元素多 在設計上有必要成立專門的數據小組 由於資料庫設計者不一定是使用者 對系統設計中的數據元素不可能考慮周全 資料庫設計出來後 往往難以找到所需的庫表 因此數據小組最好由熟悉業務的項目骨幹組成
數據小組的職能並非是設計資料庫 而是通過需求分析 在參考其他相似系顫腔統的基礎上 提取系統的基本數據元素 擔負對資料庫的審核 審核內容包括審核新的資料庫元素是否完全 能否實現全部業務需求 對舊資料庫（如果存在舊系統）的分析及數據轉換 資料庫設計的審核 控制及必要調整
二 設計原沖遲則
規范命名 所有的庫名 表名 域名必須遵循統一的命名規則 並進行必要說明 以方便設計 維護 查詢
控制欄位的引用 在設計時 可以選擇適當的資料庫設計管理工具 以方便開發人員的分布式設計和數據小組的集中審核管理 採用統一的命名規則 如果設計的欄位已經存在 可直接引用 否則 應重新設計
庫表重復控制 在設計過程中 如果發現大部分欄位都已存在 開發人員應懷疑所設計的庫表是否已存在 通過對欄位所在庫表及相應設計人員的查詢 可以確認庫表是否確實重復
並發控制 設計中應進行並發控制 即對於同一個庫表 在茄判衫同一時間只有一個人有控制權 其他人只能進行查詢
必要的討論 資料庫設計完成後 數據小組應與相關人員進行討論 通過討論來熟悉資料庫 從而對設計中存在的問題進行控制或從中獲取資料庫設計的必要信息
數據小組的審核 庫表的定版 修改最終都要通過數據小組的審核 以保證符合必要的要求
頭文件處理 每次數據修改後 數據小組要對相應的頭文件進行修改（可由管理軟體自動完成） 並通知相關的開發人員 以便進行相應的程序修改
三 設計技巧
分類拆分數據量大的表 對於經常使用的表（如某些參數表或代碼對照表） 由於其使用頻率很高 要盡量減少表中的記錄數量 例如 銀行的戶主賬表原來設計成一張表 雖然可以方便程序的設計與維護 但經過分析發現 由於數據量太大 會影響數據的迅速定位 如果將戶主賬表分別設計為活期戶主賬 定期戶主賬及對公戶主賬等 則可以大大提高查詢效率
索引設計 對於大的資料庫表 合理的索引能夠提高整個資料庫的操作效率 在索引設計中 索引欄位應挑選重復值較少的欄位 在對建有復合索引的欄位進行檢索時 應注意按照復合索引欄位建立的順序進行 例如 如果對一個 萬多條記錄的流水表以日期和流水號為序建立復合索引 由於在該表中日期的重復值接近整個表的記錄數 用流水號進行查詢所用的時間接近 秒 而如果以流水號為索引欄位建立索引進行相同的查詢 所用時間不到 秒 因此在大型資料庫設計中 只有進行合理的索引欄位選擇 才能有效提高整個資料庫的操作效率
數據操作的優化 在大型資料庫中 如何提高數據操作效率值得關注 例如 每在資料庫流水表中增加一筆業務 就必須從流水控製表中取出流水號 並將其流水號的數值加一 正常情況下 單筆操作的反應速度尚屬正常 但當用它進行批量業務處理時 速度會明顯減慢 經過分析發現 每次對流水控製表中的流水號數值加一時都要鎖定該表 而該表卻是整個系統操作的核心 有可能在操作時被其他進程鎖定 因而使整個事務操作速度變慢 對這一問題的解決的辦法是 根據批量業務的總筆數批量申請流水號 並對流水控製表進行一次更新 即可提高批量業務處理的速度 另一個例子是對插表的優化 對於大批量的業務處理 如果在插入資料庫表時用普通的Insert語句 速度會很慢 其原因在於 每次插表都要進行一次I/O操作 花費較長的時間 改進後 可以用Put語句等緩沖區形式等滿頁後再進行I/O操作 從而提高效率 對大的資料庫表進行刪除時 一般會直接用Delete語句 這個語句雖然可以進行小表操作 但對大表卻會因帶來大事務而導致刪除速度很慢甚至失敗 解決的方法是去掉事務 但更有效的辦法是先進行Drop操作再進行重建
資料庫參數的調整 資料庫參數的調整是一個經驗不斷積累的過程 應由有經驗的系統管理員完成 以Informix資料庫為例 記錄鎖的數目太少會造成鎖表的失敗 邏輯日誌的文件數目太少會造成插入大表失敗等 這些問題都應根據實際情況進行必要的調整
必要的工具 在整個資料庫的開發與設計過程中 可以先開發一些小的應用工具 如自動生成庫表的頭文件 插入數據的初始化 數據插入的函數封裝 錯誤跟蹤或自動顯示等 以此提高資料庫的設計與開發效率
避免長事務 對單個大表的刪除或插入操作會帶來大事務 解決的辦法是對參數進行調整 也可以在插入時對文件進行分割 對於一個由一系列小事務順序操作共同構成的長事務（如銀行交易系統的日終交易） 可以由一系列操作完成整個事務 但其缺點是有可能因整個事務太大而使不能完成 或者 由於偶然的意外而使事務重做所需的時間太長 較好的解決方法是 把整個事務分解成幾個較小的事務 再由應用程序控制整個系統的流程 這樣 如果其中某個事務不成功 則只需重做該事務 因而既可節約時間 又可避免長事務
適當超前 計算機技術發展日新月異 資料庫的設計必須具有一定前瞻性 不但要滿足當前的應用要求 還要考慮未來的業務發展 同時必須有利於擴展或增加應用系統的處理功能
lishixin/Article/program/SQL/201311/16498
㈣ mysql千萬或者上億的數據怎麼設計資料庫
單表一億？還是全庫1億？
1.首先可以考慮業務層面優化，即垂直分表。
垂直分表就是把一個數據量很大的表,可以按某個欄位的屬性或使用頻繁程度分類,拆分為多個表。
如有多種業務類型，每種業務類型入不同的表，table1,table2,table3.
如果日常業務不需要使用所有數據，可以按時間分表，比如說月表。每個表只存一個月記錄。
2.架構上的優化，即水平分表。
水平分表就是根據一列或多列數據的值把數據行放到多個獨立的表裡，這里不具備業務意義。
如按照id分表，末尾是0-9的數據分別插入到10個表裡面。
可能你要問，這樣看起來和剛才說的垂直分表沒什麼區別。只不過是否具備業務意義的差異，都是按欄位的值來分表。
實際上，水平分表現在最流行的實現方式，是通過水平分庫來實現的。即剛才所說的10個表，分布在10個mysql資料庫上。這樣可以通過多個低配置主機整合起來，實現高性能。
最常見的解決方案是cobar，這個帖子介紹的比較完善，可以看看。
http://blog.csdn.net/shagoo/article/details/8191346
cobar的邏輯層次圖：
不過這種分庫方式也是有一定局限性的，需要應用程序做相應的配合，比如說分庫的情況下，雖然可以實現跨庫查詢，但是不能進行相關的group by計算。
另外，之前關於水平分表的實現方式，也可以通過表分區來實現。
mysql優化的方式有很多，選擇上主要還是要考慮個人的實際情況，如代碼不可控的情況下，就不適合選擇按欄位屬性分表的情況，這樣可能會帶來大量的重構以及很多不可預期的風險。
而架構的優化，雖然對應用是透明的，但對sql的寫法有很多局限性，比如說不能使用聚合函數等等，同時也需要有充足的硬體資源，只有一台伺服器的情況下是沒有意義的。
相比起來，代價最低的是按時間分表或分區，這兩種辦法對應用來說都是透明的。
分區只需要一次本地數據遷移的操作。
而通過分表把現網數據和歷史數據分離，唯一的代價是定期的數據維護。
一般如果表裡面有1億數據的情況下，索引的問題應該是常識了，這方面我就不說了。
㈤ 數據量大，列比較多，請問資料庫表該如何設計
基本的建立主鍵，索引什麼的，我就不說了，
表設計可以採取拆分表的方式
縱向拆分表：根據欄位拆分為多個表，每個表都有關聯欄位，可以將他們關聯起來
（例如：訂單表，幾個根據欄位拆分的表中都有1個訂單號欄位）
橫向拆分表：不知道你具體什麼數據，假定其中有時間欄位，根據時間來拆分
（例如：1年有12個月，1個月的數據放入一個表中）