系統有哪些庫哪些表？對應的是哪些業務？核心的表每天新增的資料量有多少？
目前已經積累了多少資料？單錶是百萬級？還是千萬級？是什麼時候分的表？
什麼時候分的庫？
在沒有分表之前，sql的效能大概如何？分表之後sql的效能又如何？分庫之前每個資料庫伺服器上
放多少gb的資料？一台伺服器可以抗多少資料？分庫之後拆分到幾台資料庫伺服器上去？
每台伺服器現在放多少gb的資料？
基本原理？
技術方案？
技術在專案落地的各種細節如何設計的？
聯機事務處理（oltp）
聯機分析處理（olap）
通過多維的方式對資料進行分析、查詢和報表，可以同資料探勘工具、統計分析工具配合使用，增強決策分析功能。簡單地說，主要是對海量資料的查詢統計分析
oltp
olap
系統功能
日常交易處理
統計、分析、報表
db設計
面向實時交易類應用
面向統計分析類應用
資料處理
當前的、最新細節的、二維的分立的
歷史的、聚集的、多維整合的、統一的
實時性實時讀寫要求高
實時讀寫要求低
事物強一致性
弱事物分析要求
低、簡單
高、複雜
傳統資料庫：
oracle、mysql、sqlserver、db2
nosql資料庫：
臨時性鍵值儲存——redis、memcached
永久性鍵值儲存——redis、roma
面向文件儲存——mongodb、couchdb
面向列儲存——cassandra、hbase
傳統資料庫與nosql資料庫對比：
傳統資料庫
nosql資料庫
特點資料關係模型基於關係模型、結構化儲存、完整性約束。
基於二維表及其之間的聯絡，需要連線、並、交、差、除等資料操作。
採用結構化的查詢語言（sql）做資料讀寫。
操作需要資料的一致性，需要事物甚至是強一致性。
非結構化的儲存。
基於多維關係模型。
具有特定的使用場景。
優點保持資料的一致性（事物處理）。
可以進行join等複雜查詢。
通用化，技術成熟。
高併發，大資料下讀寫分離能力較強。
基本支援分布式，易於擴充套件，可伸縮。
簡單，弱結構化儲存。
缺點資料讀寫需要經過sql解析，大量資料、高併發下讀寫效能不足。
對資料做讀寫，或修改資料結構時需要加鎖，影響併發操作。
無法適應非結構化儲存。
擴充套件困難。昂貴、複雜。
join等複雜操作能力較弱。
事物支援較弱。
通用性差。
無法完整約束複雜業務場景支援較差。
把原本儲存於乙個庫的資料分塊儲存到多個庫上，把原本儲存於乙個表的資料分塊儲存於多個表上
分庫分表的目的：分散單台裝置的負載
分庫分表的基本思想：資料切分
資料切分（sharding）根據其切分規則的型別，可以分為兩種切分模式：
垂直（縱向）切分：
將不同的表（或者schema）拆分到不同的資料庫（主機）上。
說明：這種切分方式是根據業務來切分的，比如我有2個系統，分別是訂單支付系統和使用者資訊系統，在之前所有的表都是在乙個庫裡面，現在做業務拆分，就把訂單支付相關的表都放在訂單支付的庫裡面，使用者資訊相關的表都放在使用者資訊的庫裡面
水平（橫向）切分：
根據表中資料的邏輯關係，將同一張表中的資料安裝某種條件拆分到多台資料庫（主機）的同一表結構的表中。
說明：這種拆分方式是拆表的，簡單的說，就是根據表中的某個欄位對錶進行拆分，比如我有乙個訂單表，隨著年份的變化資料量越來越大，這個時候就需要根據年份來把表中的資料拆分到不同資料庫（主機）的訂單表裡面去了
垂直（縱向）切分與水平（橫向）切分的比較：
垂直切分
水平切分
特點規則簡單，實施方便。
業務之間耦合度非常低，相互影響很小。
根據不同的表來進行拆分，對應用程式的影響也更小。
將同乙個表中的不同資料拆分到不同的資料庫。
對應用程式來說，表的命名比垂直拆分更複雜。
後期的資料維護也會複雜。
優點系統之間的整合或擴充套件容易。
拆分後業務清晰，拆分規則明確。
資料維護簡單。
拆分規則抽象好，join操作基本可以資料庫做。
不存在單庫大資料和高併發效能瓶頸。
應用端改造較少。
提高了系統的穩定性跟負載能力。
缺點部分業務無法join，只能通過介面方式解決，提高了系統複雜度。
受每種業務不同的限制存在單庫效能瓶頸，不易資料擴充套件跟效能提高。
事務處理複雜。
拆分規則難以抽象。
分片事物一致性難以解決。
資料多次擴充套件跟維護量極大。
跨庫join效能較差。
解決方法：
1）資料庫自增：針對同一張表，在每個資料庫建表的時候設定步長（step）
2）uuid/guid
3）redis increment
4）mongodb objectid（類似uuid的方式）
5）zookeeper分布式鎖
6）twitter的snowflake（又叫雪花演算法）
7）ticket server（資料庫生存方式，flickr採用的就是這種方式）
1）分片欄位的選擇
2）分片規則
3）資料遷移，容量規劃，擴容等
1）跨分片的排序分頁 limit 1 5
2）跨分片函式處理
3）跨分片join
1）強一致性問題
2）弱一致性問題/最終一致性
1）cobar
cobar是來自阿里的mysql中介軟體,但是現在已經很久沒有更新了，它可以在分布式的環境下看上去像傳統資料庫一樣為您提供海量資料服務
2）sharding jdbc
噹噹應用框架ddframe中，從關係型資料庫模組dd-rdb中分離出來的資料庫水平分片框架，實現透明化資料庫分庫分表訪問
3）tddl
**根據自身業務需求研發了tddl（taobao distributed data layer 外號頭都大了）框架，主要用於解決分庫分表場景下的訪問路由（持久層與資料訪問層的配合）以及異構資料庫之間的資料同步，它是乙個基於集中式配置的jdbc datasource實現，具有分庫分表、讀寫分離（master/salve）、動態資料來源配置等功能。
4）mycat
乙個開源的分布式資料庫系統，實現了mysql協議的伺服器。前端使用者可以把它看作是乙個資料庫**，用mysql客戶端工具和命令列訪問，而其後端可以用mysql原生協議與多個mysql伺服器通訊，也可以用jdbc協議與大多數主流資料庫伺服器通訊
這幾種中介軟體的對比：
多種分布式全域性唯一id的實現方式
多種分片規則和策略，甚至可以自定義
多種分片規則和策略，甚至可以自定義
單庫內保證事物的完整性，跨庫事物弱xa（最終一致性）
mycat其他特點：
1）可以通過mycat統一管理所有資料來源，後端資料庫集群對前端應用程式透明
2）獨創的er關係分片，解決er分片難處理問題
3）採用全域性分片技術，每個節點同時併發插入和更新資料，每個節點都可以讀取資料
4）通過人工智慧的catlet支援分片複雜sql實現以及儲存過程支援等
Mysql系列四 資料庫分庫分表基礎理論
聯機事務處理 oltp 聯機分析處理 olap 通過多維的方式對資料進行分析 查詢和報表，可以同資料探勘工具 統計分析工具配合使用，增強決策分析功能。簡單地說，主要是對海量資料的查詢統計分析 oltp olap 系統功能 日常交易處理 統計 分析 報表 db設計 面向實時交易類應用 面向統計分析類應...
mysql資料庫分庫分表實踐
一 背景 隨著零售門店數量的增長，庫存表，優惠劵表，訊息表，訂單表資料量不斷的增多，目前一主 寫 多從的mysql 架構難於支撐公司業務的爆發式增長 二 調研 前期在於重點解決 mysql 的單機效能和容量無法線性和靈活擴充套件的問題，最終選擇了 mycat，在調研階段，對以下技術特性進行了重點考慮...
資料庫分庫分表
1 基本思想之什麼是分庫分表？從字面上簡單理解，就是把原本儲存於乙個庫的資料分塊儲存到多個庫上，把原本儲存於乙個表的資料分塊儲存到多個表上。2 基本思想之為什麼要分庫分表？資料庫中的資料量不一定是可控的，在未進行分庫分表的情況下，隨著時間和業務的發展，庫中的表會越來越多，表中的資料量也會越來越大，相...