######################
一、大數據量：
什么叫大數據量？至少有千萬行級別的大表，或者數據庫schema的占空空間有T級別的數據量，
如果數據量少於500G且qps或並發量小則使用mysql
二、高並發量：
數十萬QPS也不再話下
不用再分庫分表了，也不再使用中間件了
三、dba運維簡單：
因為tidb自動維護數據的強一致性和高可用，解脫了dba
四、實時HTAP場景：
mysql與tidb的區別：
自增id：tidb的自增id只能保證唯一性，不保證自增性和連續性，也不支持在線添加列auto_increment屬性
索引區別：tidb的主鍵索引和唯一索引的存儲方式相同，不支持全文索引、空間索引、
字符集支持：僅支持utf8/utf8mb4/ascii/latin1/binary幾個字符集
視圖：tidb只支持讀，不支持insert、update、delete等其他操作
外鍵：tidb不支持
觸發器：tidb不支持
存儲過程：tidb不支持
自定義函數：tidb不支持
sql_mode區別：部分選項有差別
ddl區別：不支持將整型改為字符串，不支持同時修改多個字段，不支持有損更改，比如bigint改為int
執行計划：tidb有區別
悲觀事務區別：沒有gap lock，tidb的ddl語句會打斷正在執行的悲觀事務，讓悲觀事務提交失敗，而mysql則會阻塞ddl語句，autocommit事務優先采用樂觀事務，即使全局采用了悲觀事務模型，不支持select xxx from yyy lock in share mode,語句不會報錯，但是加鎖操作無效。tidb樂觀事務的affectted_row值不准，業務千萬不要依賴這個做業務邏輯。
加鎖處理邏輯
1）是否需要加數據鎖？
2）對加鎖超時進行什么處理？重試？拋出？
tidb架構：
一個 TiDB 集群由不同的模塊組成，包括：TiDB 服務器、TiKV 服務器、Placement Driver (PD) 服務器。
TiDB 的架構非常簡單，首先是 Load Balancer，可以將用戶的 SQL 請求打散，發送到 TiDB Server 中。TiDB Server 是一個無狀態的計算層，可以隨意擴展，實際的數據存儲在分布式 KV 存儲 TiKV 中。此外，還有一個 PD 組件來對這些數據進行調度以及規整。 這一套架構最突出的部分是擴容，以擴容作為第一要義。擴容體現在兩個方面，
一是存儲擴容，傳統的單機數據庫無法承載的數據量，TiDB 可以將其存儲到分布式存儲中。
二是計算上，傳統數據庫單機無法承受較高的 QPS， 通過這種擴容的方式，QPS 可以打散到不同的計算節點上。
TiDB 集群主要分為三個組件：
TiDB Server：請求處理和計算處理（業務請求量大，那就增加tidb節點）
TiDB Server 負責接收 SQL 請求，處理 SQL 相關的邏輯，並通過 PD 找到存儲計算所需數據的 TiKV 地址，與 TiKV 交互獲取數據，最終返回結果。
TiDB Server 是無狀態的，其本身並不存儲數據，只負責計算，可以無限水平擴展，可以通過負載均衡組件（如LVS、HAProxy 或 F5）對外提供統一的接入地址。
PD Server：存儲集群元數據、分配全局事務id、對tikv集群調度和負載均衡
Placement Driver (簡稱 PD) 是整個集群的管理模塊，其主要工作有三個： 一是存儲集群的元信息（某個 Key 存儲在哪個 TiKV 節點）；二是對 TiKV 集群進行調度和負載均衡（如數據的遷移、Raft group leader 的遷移等）；三是分配全局唯一且遞增的事務 ID。
PD 是一個集群，需要部署奇數個節點，一般線上推薦至少部署 3 個節點。
TiKV Server：多副本存儲數據（業務數據量暴增，那就增加tikv節點）
TiKV Server 負責存儲數據，從外部看 TiKV 是一個分布式的提供事務的 Key-Value 存儲引擎。存儲數據的基本單位是 Region，每個 Region 負責存儲一個 Key Range （從 StartKey 到 EndKey 的左閉右開區間）的數據，每個 TiKV 節點會負責多個 Region 。
TiKV 使用 Raft 協議做復制，保持數據的一致性和容災。副本以 Region 為單位進行管理，不同節點上的多個 Region 構成一個 Raft Group，互為副本。數據在多個 TiKV 之間的負載均衡由 PD 調度，這里也是以 Region 為單位進行調度。
核心特性
水平擴展
無限水平擴展是 TiDB 的一大特點，這里說的水平擴展包括兩方面：計算能力和存儲能力。TiDB Server 負責處理 SQL 請求，隨着業務的增長，可以簡單的添加 TiDB Server 節點，提高整體的處理能力，提供更高的吞吐。
TiKV 負責存儲數據，隨着數據量的增長，可以部署更多的 TiKV Server 節點解決數據 Scale 的問題。PD 會在 TiKV 節點之間以 Region 為單位做調度，將部分數據遷移到新加的節點上。所以在業務的早期，可以只部署少量的服務實例（推薦至少部署 3 個 TiKV， 3 個 PD，2 個 TiDB），隨着業務量的增長，按照需求添加 TiKV 或者 TiDB 實例。
高可用
高可用是 TiDB 的另一大特點，TiDB/TiKV/PD 這三個組件都能容忍部分實例失效，不影響整個集群的可用性。下面分別說明這三個組件的可用性、單個實例失效后的后果以及如何恢復。
TiDB
TiDB 是無狀態的，推薦至少部署兩個實例，前端通過負載均衡組件對外提供服務。當單個實例失效時，會影響正在這個實例上進行的 Session，從應用的角度看，會出現單次請求失敗的情況，重新連接后即可繼續獲得服務。單個實例失效后，可以重啟這個實例或者部署一個新的實例。
PD
PD 是一個集群，通過 Raft 協議保持數據的一致性，單個實例失效時，如果這個實例不是 Raft 的 leader，那么服務完全不受影響；如果這個實例是 Raft 的 leader，會重新選出新的 Raft leader，自動恢復服務。PD 在選舉的過程中無法對外提供服務，這個時間大約是3秒鍾。推薦至少部署三個 PD 實例，單個實例失效后，重啟這個實例或者添加新的實例。
TiKV
TiKV 是一個集群，通過 Raft 協議保持數據的一致性（副本數量可配置，默認保存三副本），並通過 PD 做負載均衡調度。單個節點失效時，會影響這個節點上存儲的所有 Region。對於 Region 中的 Leader 結點，會中斷服務，等待重新選舉；對於 Region 中的 Follower 節點，不會影響服務。當某個 TiKV 節點失效，並且在一段時間內（默認 30 分鍾）無法恢復，PD 會將其上的數據遷移到其他的 TiKV 節點上。
tidb-server組件目錄結構：/home/work/tidb/tidb-4000
[work@10.10.10.10 tidb-4000]$ tree . ├── bin │ └── tidb-server ├── conf │ ├── cluster.conf │ └── tidb.toml ├── log │ ├── tidb.log │ ├── tidb_slow_query.log │ └── tidb_stderr.log ├── scripts │ └── run_tidb.sh └── tmp-storage └── 10000_tidb └── MC4wLjAuMDo0MDAwLzAuMC4wLjA6MTAwODA= └── tmp-storage ├── _dir.lock └── record
#####################
######################