1.截至 4.0 版本，TiDB 與 MySQL 的區別總結
| 功能 | MySQL | TiDB |
| 隔離級別 | 支持讀未提交、讀已提交、可重復讀、串行化。【默認為可重復讀】 | 樂觀事務支持快照隔離，悲觀事務支持快照隔離和讀已提交 |
| 鎖機制 | 悲觀鎖 | 樂觀鎖、悲觀鎖 |
| 存儲過程 | 支持 | 不支持 |
| 觸發器 | 支持 | 不支持 |
| 事件 | 支持 | 不支持 |
| 自定義函數 | 支持 | 不支持 |
| 窗口函數 | 支持 | 部分支持 |
| JSON | 支持 | 不支持部分 MySQL 8.0 新增的函數 |
| 外鍵約束 | 支持 | 忽略外鍵約束 |
| 字符集 | 只支持 ascii、latin1、binary、utf8、utf8mb4 | |
| 增加/刪除主鍵 | 支持 | 通過 alter-primary-key 配置開關提供 |
| CREATE TABLE tblName AS SELECT stmt | 支持 | 不支持 |
| CREATE TEMPORARY TABLE | 支持 | TiDB 忽略 TEMPORARY 關鍵字，按照普通表創建 |
| DML affected rows | 支持 | 不支持 |
| AutoRandom 列屬性 | 不支持 | 支持 |
| Sequence 序列生成器 | 不支持 | 支持 |
2.TiDB DDL操作
TiDB 集群中，用戶執行的 DDL 操作分兩類：普通 DDL 操作和加索引操作。
增加字段
在執行 ADD COLUMN 類型 DDL 時，TIDB並沒有對數據進行回填，而是將最新添加的列的 default 值保存到 schema 的"原始默認值"字段中，在讀取階段如果 TiKV 發現該列值為 null 並且"原始默認字段"不為 null，則會使用"原始默認字段"對該 null 列進行填充，並將填充后的結果從 TiKV 返回。通過這種優化，該 DDL 操作不需要關心表中實際行數，可以更快的完成 DDL 變更，操作執行時間短，一般秒級就可以執行完成。
增加索引
加索引操作由於需要回填數據，因此執行時間略長。而在回填數據期間，需要將回填的數據寫入 TiKV，對 TiKV 會產生額外的寫入壓力，從而造成一些性能影響。
TiDB 提供了參數 tidb_ddl_reorg_worker_cnt 和 tidb_ddl_reorg_batch_size 用來控制回填數據的速度。通過調整參數，可以在業務訪問高峰到來時降低 DDL 速度，保證對業務的正常訪問無影響；而在業務訪問低峰增加 DDL 速度，從而更快的完成 DDL 任務。
3.Sequence
Sequence 是數據庫系統按照一定規則自增的數字序列，具有唯一和單調遞增的特性。可以實現並發應用需要獲取單調遞增的序列號；通過調用不同的Sequence ，在一張表里面需要有多個自增字段；更新數據表中一列值為連續自增的值。
4.AutoRandom
AutoRandom 是 TiDB 4.0 提供的一種擴展語法，用於解決整數類型主鍵通過 AutoIncrement 屬性隱式分配 ID 時的寫熱點問題。使用 AUTO_RANDOM 功能前，須在 TiDB 配置文件 experimental 部分設置 allow-auto-random = true。
- 唯一性：TiDB 始終保持填充數據在表范圍內的唯一性。
- 高性能：TiDB 能夠以較高的吞吐分配數據，並保證數據的隨機分布以配合
PRE_SPLIT_REGION語法共同使用，避免大量寫入時的寫熱點問題。 - 支持隱式分配和顯式寫入：類似列的 AutoIncrement 屬性，列的值既可以由 TiDB Server 自動分配，也可以由客戶端直接指定寫入。該需求來自於使用 Binlog 進行集群間同步時，保證上下游數據始終一致。
5. TiUP
在 TiDB 4.0 的生態系統里，TiUP 作為新的工具，承擔着包管理器的角色，管理着 TiDB 生態下眾多的組件（例如 TiDB、PD、TiKV）。用戶想要運行 TiDB 生態中任何東西的時候，只需要執行 TiUP 一行命令即可，相比以前，極大地降低了管理難度。
6.數據訂閱復制同步工具 CDC
TiCDC（TiDB Change Data Capture）是用來識別、捕捉和輸出 TiDB/TiKV 集群上數據變更的工具系統。它既可以作為 TiDB 增量數據同步工具，將 TiDB 集群的增量數據同步至下游數據庫，也提供開放數據協議，支持把數據發布到第三方系統。相較於 TiDB Binlog，TiCDC 不依賴 TiDB 事務模型保證數據同步的一致性，系統可水平擴展且天然支持高可用。在 TiCDC 工具出現之前，數據同步功能是由 TiDB-Tools 工具中的 TiDB-Binlog 來實現的。TiDB-Binlog 通過收集各個 TiDB 實例產生的 binlog，並按照事務提交的時間排序后同步到下游。
7.數據導入工具 Lightning
TiDB Lightning 是一個將全量數據高速導入到 TiDB 集群的工具，速度可達到傳統執行 SQL 導入方式的 3 倍以上、大約每小時 300 GB。Lightning 有以下兩個主要的使用場景：一是大量新數據的快速導入、二是全量數據的備份恢復。目前，Lightning 支持 Mydumper 或 CSV 輸出格式的數據源。
注意事項:一旦目標 TiKV 集群切換到導入模式，整個數據導入階段該集群將被 tidb-lightning 獨占，無法對外提供正常服務。數據導入完成后，tidb-lightning 會自動把 TiKV 集群切換回“普通模式”。
8.備份恢復工具 BR
BR(https://github.com/pingcap/br) 是分布式備份恢復工具，分布式意味着可以通過 BR 可以驅動集群中所有 TiKV 節點進行備份恢復工作，相比起 SQL dump 形式，這種分布式備份恢復的效率會有極大的提升。
注意（1）增量的實現也是全表掃，同樣有性能問題，這個和傳統數據庫的增量不一樣；(2)恢復耗時要高於備份耗時。
9.導出工具Dumpling
Dumpling 將提供以下幾個特性：
- 完全采用 Golang，與 TiDB 生態集成度高
- 能夠提供 Mydumper 類似的功能，且支持並發高速導出 MySQL 協議兼容數據庫數據
- 提供 SQL、CSV 等多種數據輸出格式，以便於快速導出及導入
- 支持直接導出數據到雲存儲系統，比如 S3
10.限制 SQL 內存使用和執行時間
限制SQL內存使用和執行時間主要是為限制消耗系統資源多的SQL，防止某條SQL造成OOM或影響到集群的整體性能。
類別 |
參數 |
說明 |
限制SQL內存使用 |
mem-quota-query | 單條 SQL 語句可以占用的最大內存閾值。【默認值32G】 |
| tidb_mem_quota_query | 設置一條查詢語句的內存使用閾值。【默認值32G】 | |
| tidb_mem_quota_hashjoin | 設置 HashJoin 算子的內存使用閾值。【默認值32G】 |
|
| tidb_mem_quota_mergejoin | 設置 MergeJoin 算子的內存使用閾值。【默認值32G】 |
|
| tidb_mem_quota_sort | 設置 Sort 算子的內存使用閾值。【默認值32G】 | |
| tidb_mem_quota_topn | 設置 TopN 算子的內存使用閾值。【默認值32G】 | |
| tidb_mem_quota_indexlookupreader | 設置 IndexLookupReader 算子的內存使用閾值。【默認值32G】 |
|
| tidb_mem_quota_indexlookupjoin | 設置 IndexLookupJoin 算子的內存使用閾值。【默認值32G】 |
|
| tidb_mem_quota_nestedloopapply | 設置 NestedLoopApply 算子的內存使用閾值。【默認值32G】 |
|
限制SQL執行時間 |
max_execution_time | 把查詢的執行時間限制在指定的 N 毫秒以內，超時后服務器會終止這條語句的執行。 【單位為：ms】 |
11.利用 GC 快照讀恢復數據
TiDB 事務的實現采用了 MVCC（多版本並發控制）機制，當更新/刪除數據時，不會做真正的數據刪除，只會添加一個新版本數據，並以時間戳來區分版本。當然歷史數據不會永久保留，超過一定時間的歷史數據將會被徹底刪除，以減小空間占用，同時避免因歷史版本過多引起的性能開銷。
TiDB 使用周期性運行的 GC（Garbage Collection，垃圾回收）來進行清理，默認情況下每 10 分鍾一次。每次 GC 時，TiDB 會計算一個稱為 safe point 的時間戳（默認為上次運行 GC 的時間減去 10 分鍾），接下來 TiDB 會在保證在 safe point 之后的快照都能夠讀取到正確數據的前提下，刪除更早的過期數據。
TiDB 的 GC 相關的配置存儲於 mysql.tidb 系統表中，可以通過 SQL 語句對這些參數進行查詢和更改。
讀取歷史版本數據前，需設定一個系統變量: tidb_snapshot ，這個變量是 Session 范圍有效級別，可以通過標准的 Set 語句修改其值。當這個變量被設置后，TiDB 會用這個時間戳建立 Snapshot（沒有開銷，只是創建數據結構），之后所有的查詢操作都會在這個 Snapshot 上讀取數據。當讀取歷史版本數據操作結束后，可以結束當前 Session 或者是通過 Set 語句將 tidb_snapshot 變量的值設為 “"，即可讀取最新版本的數據。
12.利用 Recover/Flashback 命令秒恢復誤刪表
Recover
TiDB 在刪除表時，實際上只刪除了表的元信息，並將需要刪除的表數據范圍（行數據和索引數據）寫一條數據到 mysql.gc_delete_range 表。TiDB 后台的 GC Worker 會定期從 mysql.gc_delete_range 表中取出超過 GC lifetime 相關范圍的 key 進行刪除。所以，RECOVER TABLE 只需要在 GC Worker 還沒刪除表數據前，恢復表的元信息並刪除 mysql.gc_delete_range 表中相應的行記錄就可以了。恢復表的元信息可以用 TiDB 的快照讀實現，TiDB 中表的恢復是通過快照讀獲取表的元信息后，再走一次類似於 CREATE TABLE 的建表流程，所以 RECOVER TABLE 實際上也是一種 DDL。
recover table 的一些使用限制：
- 只能用來恢復誤刪除表的 DDL 操作，例如 truncate table，delete 操作沒有辦法恢復。
- 只能在 GC 回收數據之前完成，超過 GC 時間后會報錯無法成功恢復。
- 如果在使用 binlog 的情況下，上游執行 recover table 可能會出現一些非預期的結果。例如下游是 MySQL 數據庫，對於這個語法不兼容。上下游的 GC 策略配置不同，再加上復制延遲可能會引起下游的數據在 apply recover table 的時候已經被 GC 了從而導致語句執行失敗。
Flashback
Flashback 的原理和 Recover table 比較類似，不過是 recover 的升級版，在覆蓋 recover 的所有功能之外，還可以支持 truncate table 的操作，未來也會逐漸取代 recover 命令。
參考學習
１.TiDB In Action: based on 4.0
２.走進TiDB社區
https://www.bilibili.com/video/av242591239
3.TiDB 數據庫開發規范