TiDB使用的坑有哪些

這篇“TiDB使用的坑有哪些”文章的知識(shí)點(diǎn)大部分人都不太理解，所以小編給大家總結(jié)了以下內(nèi)容，內(nèi)容詳細(xì)，步驟清晰，具有一定的借鑒價(jià)值，希望大家閱讀完這篇文章能有所收獲，下面我們一起來(lái)看看這篇“TiDB使用的坑有哪些”文章吧。

原有數(shù)據(jù)庫(kù)架構(gòu)與數(shù)據(jù)庫(kù)評(píng)估模型

先看一下我們現(xiàn)在的數(shù)據(jù)庫(kù)架構(gòu)：

按照業(yè)務(wù)主要分為四層：

首先是業(yè)務(wù)層，業(yè)務(wù)層的含義就是指自身為具體的產(chǎn)品或者工藝模塊，需要調(diào)用核心電路或者核心平臺(tái)來(lái)實(shí)現(xiàn)自己的功能。這部分的架構(gòu)主要是采用了 X86 服務(wù)器和低端存儲(chǔ)介質(zhì)+MySQL、Redis 開(kāi)源的產(chǎn)品，這一層在實(shí)現(xiàn)業(yè)務(wù)注冊(cè)的同時(shí)會(huì)最大程度的減少成本。

第二層是核心支付鏈路層，是業(yè)務(wù)的核心層，如果出現(xiàn)問(wèn)題，將會(huì)導(dǎo)致整個(gè)平臺(tái)的交易失敗，因此這層會(huì)最大保證數(shù)據(jù)安全、數(shù)據(jù)可用性以及一致性。它的架構(gòu)主要用小機(jī)+高端存儲(chǔ)，以及 Oracle 來(lái)實(shí)現(xiàn)的。

第三層是核心平臺(tái)層，指的是輔助核心支付鏈路完成整個(gè)交易流程的平臺(tái)，或者是自己具備一些自身能力的平臺(tái)，該層在保證性能及穩(wěn)定性的同時(shí)會(huì)減少高端存儲(chǔ)的使用成本。

最后就是離線的歸檔層。根據(jù)我們目前的架構(gòu)劃分在 TiDB 的落地過(guò)程中，我們選擇的路線是從業(yè)務(wù)層開(kāi)始，到核心平臺(tái)層，再往核心支付鏈路層。目前，業(yè)務(wù)層以及核心平臺(tái)層都進(jìn)行了 TiDB 的推廣使用，在過(guò)程中，雖然遇到了一些小問(wèn)題，但總體來(lái)看，在數(shù)據(jù)一致性等關(guān)鍵點(diǎn)都是沒(méi)有出現(xiàn)過(guò)問(wèn)題的。其它關(guān)于性能解讀和參數(shù)調(diào)優(yōu)問(wèn)題也都得到了妥善的解決。并且，在推進(jìn)過(guò)程中，我們針對(duì)分布式數(shù)據(jù)庫(kù)建立了一套應(yīng)用規(guī)范，包括最佳研發(fā)的應(yīng)用實(shí)踐、新老架構(gòu)并行方案等來(lái)降低風(fēng)險(xiǎn)，保障運(yùn)行。

上圖就是我們建立的用來(lái)快速進(jìn)行數(shù)據(jù)庫(kù)選型建議的數(shù)據(jù)庫(kù)評(píng)估模型?，F(xiàn)在對(duì)于新采用的項(xiàng)目，在關(guān)系型數(shù)據(jù)庫(kù)的選型上，已經(jīng)不再考慮使用 Oracle 了，而是在內(nèi)部的 RDS、Sharding-Sphere、TiDB 中做架構(gòu)的選型。進(jìn)行了大量的測(cè)試，包括 TPCC、Sysbench、業(yè)務(wù)測(cè)試以及充分的和原廠進(jìn)行溝通后，最終確定了中國(guó)電信翼支付基于業(yè)務(wù)場(chǎng)景的數(shù)據(jù)庫(kù)選型評(píng)估模型。

下面這個(gè)表里顯示的，我們主要就是三類技術(shù)站，按照容量閥、性能閥、大表的數(shù)量、分區(qū)規(guī)則、 HTAP，以及拓?fù)浣Y(jié)構(gòu)這幾個(gè)緯度進(jìn)行篩選。

• 首先是容量上，比如說(shuō)我的容量小于 3T ，QPS 小于 20000，大表小于 10 個(gè)，這種場(chǎng)景就會(huì)使用 RDS；

• 如果是 3T 到 10T 之間，QPS 超過(guò) 20000，大表比較少，有明確的分表規(guī)則，沒(méi)有統(tǒng)計(jì)類的查詢的場(chǎng)景，會(huì)選擇 Sharding-Sphere；

• 容量大于 3T，QPS 至少大于 20000，大表數(shù)量也比較多，而且分片規(guī)則也很難定義，或者是一些混合場(chǎng)景，這種就會(huì)選擇 TiDB 。

這里就是我們后面進(jìn)行案例選擇時(shí)能夠做出快速選型的一個(gè)建議。

數(shù)據(jù)庫(kù)演進(jìn)路徑

在業(yè)務(wù)選取和應(yīng)用上，我們從邊緣做起，首先從歷史歸檔庫(kù)進(jìn)行產(chǎn)品的基礎(chǔ)功能和性能驗(yàn)證；然后從外圍切入，比如說(shuō)選取統(tǒng)一消息、營(yíng)銷業(yè)務(wù)進(jìn)行實(shí)際業(yè)務(wù)切入；然后再向重要的業(yè)務(wù)進(jìn)行過(guò)渡，比如選取征信業(yè)務(wù)、賬單業(yè)務(wù)、賬目、以及結(jié)算的對(duì)賬類的業(yè)務(wù)進(jìn)行推進(jìn)，這些是我們現(xiàn)在已經(jīng)推進(jìn)的內(nèi)容。接下來(lái)我們規(guī)劃的要做的就是向核心進(jìn)發(fā)，在 CIF、支付、交易、賬務(wù)體系中選取試點(diǎn)業(yè)務(wù)。

在業(yè)務(wù)應(yīng)用和切換的原則上有如下幾點(diǎn)：

• 采用業(yè)務(wù)雙寫(xiě)，對(duì)應(yīng)用和數(shù)據(jù)庫(kù)的適配層進(jìn)行改造，并行運(yùn)行，逐步進(jìn)行流量切換；

• 對(duì)數(shù)據(jù)要求是不能丟也不能錯(cuò)；

• 敏感服務(wù)在雙寫(xiě)驗(yàn)證后，需要快速的切換到 TiDB 的架構(gòu)上；

• 遷移的過(guò)程中，隨時(shí)能夠切換到原有的架構(gòu)；

• 對(duì)部分分庫(kù)分區(qū)的表要進(jìn)行合表。

下面就詳細(xì)介紹下在 TiDB 使用過(guò)程中的實(shí)踐和優(yōu)化。TiDB 在翼支付的應(yīng)用場(chǎng)景主要包括 OLTP 和一些混合場(chǎng)景，大部分場(chǎng)景都是在 TB 級(jí)數(shù)據(jù)庫(kù)的業(yè)務(wù)規(guī)模。

對(duì)賬平臺(tái)系統(tǒng)應(yīng)用

對(duì)賬平臺(tái)（支付系統(tǒng)與渠道間的對(duì)賬）包括兩個(gè)緯度，一是信息流的勾兌，即業(yè)務(wù)對(duì)賬/交易對(duì)賬，主要是就收單交易的支付信息與銀行提供的信息流文件進(jìn)行勾兌。信息流的勾兌能發(fā)現(xiàn)支付系統(tǒng)與銀行系統(tǒng)間的掉單，兩邊由于系統(tǒng)間的原因?qū)е峦还P交易支付金額不一致或者支付狀態(tài)不一致。二是資金流的勾兌，即資金對(duì)賬，主要就收單交易的支付信息與銀行提供的資金流信息進(jìn)行勾兌。資金流的勾兌能發(fā)現(xiàn)支付系統(tǒng)在銀行的帳戶資金實(shí)際發(fā)生的變動(dòng)與應(yīng)該發(fā)生的變動(dòng)的差異。這個(gè)系統(tǒng)涉及到多張表，單表的規(guī)模超 10 億，整體數(shù)據(jù)規(guī)模在 8T+，業(yè)務(wù)應(yīng)用的邏輯相對(duì)復(fù)雜，并發(fā)場(chǎng)景中等，根據(jù)架構(gòu)選型圖及評(píng)估模型來(lái)選擇的話，是比較適用于 TiDB。

對(duì)賬平臺(tái)的應(yīng)用概況

這是它的數(shù)據(jù)流向圖，首先是核心支付系統(tǒng)產(chǎn)生交易流水，通過(guò)文件形式傳輸?shù)轿募馕龇?wù)，文件解析服務(wù)將數(shù)據(jù)的解析結(jié)果保存到分布式數(shù)據(jù)庫(kù)，對(duì)賬系統(tǒng)基于分布式數(shù)據(jù)庫(kù)完成對(duì)賬的流程，同時(shí)向 WEB 端提供查詢頁(yè)面和查詢服務(wù)。

下面兩個(gè)監(jiān)控圖是對(duì)賬平臺(tái)上線后的監(jiān)控圖，日常的（TPS）和響應(yīng)時(shí)間，目前 TPS 日均在 7000 以下，相應(yīng)的響應(yīng)時(shí)間也滿足我們的需要。

對(duì)賬平臺(tái)系統(tǒng)應(yīng)用價(jià)值

對(duì)賬單系統(tǒng)平臺(tái)我們選取的三個(gè)最常用的對(duì)賬渠道來(lái)進(jìn)行的比較：

• 銀聯(lián)支付寶通道，以前使用 MySQL 整體的用時(shí)是兩分鐘，現(xiàn)在使用 TiDB 整體的用時(shí)是 40 秒，性能提高了 300%。

• 銀聯(lián)無(wú)卡快捷通道，原來(lái)使用 MySQL 用時(shí)是 3 到 5 分鐘，目前使用 TiDB 是 1 到 2 分鐘，性能提升也達(dá)到了 200% - 300% 的提升比。

• 微信支付，原來(lái)用 MySQL 用時(shí)是 3 分鐘，目前使用 TiDB 大概是 1 分鐘，性能也提升了 300%。

這個(gè)系統(tǒng)現(xiàn)在對(duì)財(cái)務(wù)部門運(yùn)營(yíng)的處理能效都得到了很大的提升，大大降低了技術(shù)團(tuán)隊(duì)的工作復(fù)雜度。我們上線以后，內(nèi)部對(duì) TiDB 目前的表現(xiàn)還是比較滿意的。

個(gè)人賬單系統(tǒng)應(yīng)用

個(gè)人賬單系統(tǒng)在翼支付 APP 客戶端內(nèi)為個(gè)人用戶提供所有交易的賬單數(shù)據(jù)的管理、查詢功能，以及數(shù)據(jù)的分類和統(tǒng)計(jì)功能，以便用戶能更好的掌握自己通過(guò)翼支付所做的所有的交易。

數(shù)據(jù)來(lái)源主要來(lái)自于 kafka 隊(duì)列的接收，來(lái)源于交易系統(tǒng)。

個(gè)人賬單數(shù)據(jù)原來(lái)是存在 MySQL 中，使用 MyCat 進(jìn)行分庫(kù)分表的策略，但是仍然解決不了日益增長(zhǎng)的數(shù)據(jù)和存儲(chǔ)空間不足的問(wèn)題，只能保存一年的數(shù)據(jù)。同時(shí)個(gè)人賬單數(shù)據(jù)的主表數(shù)據(jù)量大概在 80 億，無(wú)論是加列加索引，使用在線的 pt-online-schema，或者 gh-ost 都會(huì)面臨著拷貝一張臨時(shí)表時(shí)間過(guò)長(zhǎng)，面臨磁盤(pán)打滿，或者是中間處理的時(shí)間過(guò)長(zhǎng)的問(wèn)題。

根據(jù)評(píng)估模型，也是屬于典型的一個(gè) TiDB 的適用場(chǎng)景，按照應(yīng)用切換原則短時(shí)間內(nèi)進(jìn)行了應(yīng)用切換和遷移工作。

這里是個(gè)人賬單的數(shù)據(jù)流向圖。首先是交易系統(tǒng)會(huì)把交易的信息同步到 kafka 里，然后會(huì)消費(fèi)到個(gè)人賬單系統(tǒng)里面，經(jīng)過(guò)個(gè)人賬單系統(tǒng)的處理展示到 APP 端。這里我們選用了 TiDB 的 DM 進(jìn)行了 MySQL 遷移到 TiDB， DM 工具既可以支持全量備份文件，將 MySQL 的數(shù)據(jù)導(dǎo)入 TiDB，也支持通過(guò)解析執(zhí)行 MySQL binlog 的方式來(lái)增量同步到 TiDB，同時(shí)它也滿足了我們多個(gè) MyCat 的分庫(kù)分表，需要合并到同一個(gè) TiDB 一張表的場(chǎng)景。DM 提供了比較好的支持，大家可以看一下 DM 的工作原理圖，上面就是數(shù)據(jù)的全量遷移的功能，下面的數(shù)據(jù)流就屬于一個(gè)增量數(shù)據(jù)同步的過(guò)程。

對(duì)于全量的數(shù)據(jù)遷移， DM 首先使用了 dumper 單元從上游的 MySQL 將表結(jié)構(gòu)與數(shù)據(jù)導(dǎo)成了 SQL 文件，然后通過(guò) loader 單元讀取這些 SQL 文件并同步給下游的 TiDB。增量同步的部分首先使用了 relay 單元作為 Slave，連接到上游的 MySQL 并拉取 binlog 作為 relay log 數(shù)據(jù)導(dǎo)到本地，然后通過(guò) syncer 單元讀取 relay log 并解析成 syncer 的語(yǔ)句同步到下游的 TiDB，這個(gè)增量的過(guò)程就和 MySQL 的主從復(fù)制很相似。

我們的遷移是等 DM 把全量數(shù)據(jù)以及增量都同步到 TiDB 后，經(jīng)過(guò)多種驗(yàn)證它的數(shù)據(jù)一致性，之后選取一天進(jìn)行了短暫的寫(xiě)入暫停（大概是 10 分鐘左右），交由業(yè)務(wù)時(shí)業(yè)務(wù)其實(shí)是做了一個(gè)雙寫(xiě)的改造，這時(shí)把雙寫(xiě)開(kāi)關(guān)打開(kāi)，同時(shí)會(huì)寫(xiě) TiDB，逐步寫(xiě)把讀慢慢切過(guò)去，同時(shí)會(huì)校驗(yàn) TiDB 和 MySQL 在雙寫(xiě)時(shí)的數(shù)據(jù)是否一致，確認(rèn)沒(méi)有問(wèn)題的時(shí)候，后續(xù)就把 MySQL 的同步斷掉，然后就完成了一個(gè)遷移。

個(gè)人賬單應(yīng)用情況

大家可以看一下監(jiān)控圖，上面的是從 Zabbix 上取出來(lái)的，因?yàn)樗瓉?lái)使用的是 MySQL 所以我們最早使用的是 Zabbix 的監(jiān)控， QPS 平時(shí)最大的大概達(dá)到 3 - 4 K，下面的是 TiDB 的圖。大家可以看，平時(shí) QPS 是差不多的，但是在活動(dòng)的時(shí)候 QPS 會(huì)增加好幾倍，這時(shí)使用 TiDB 也沒(méi)有發(fā)現(xiàn)問(wèn)題，說(shuō)明在流量增加好幾倍的時(shí)候也是可以應(yīng)對(duì)這種系統(tǒng)處理的。

顯著提升了用戶體驗(yàn)，增加用戶使用量，減少因追溯交易發(fā)生問(wèn)題丟失的用戶，增加了用戶活躍度，解決了原有分庫(kù)分表在容量、存儲(chǔ)周期、查詢效率等緯度的問(wèn)題。

反洗錢系統(tǒng)應(yīng)用

隨著監(jiān)控?cái)?shù)據(jù)的數(shù)量和類型發(fā)生許多變化，反洗錢業(yè)務(wù)需求數(shù)據(jù)日益增大，監(jiān)控的范圍不斷的擴(kuò)大，目前平臺(tái)面臨以下幾個(gè)方面的問(wèn)題：

• 數(shù)據(jù)庫(kù)批量處理系統(tǒng)出現(xiàn)顯著性能瓶頸；

• 統(tǒng)計(jì)分析系統(tǒng)不滿足響應(yīng)反洗錢監(jiān)管的時(shí)效性要求；

• 數(shù)據(jù)庫(kù)性能無(wú)法進(jìn)行性能擴(kuò)展。

監(jiān)管部門對(duì)處理時(shí)間的要求是 T+1 的時(shí)間內(nèi)必須要完成可疑的規(guī)則和風(fēng)險(xiǎn)評(píng)級(jí)的計(jì)算要求。目前跑批單的任務(wù)時(shí)間大概都在幾百分鐘，整體任務(wù)每天處理的時(shí)間都會(huì)在 15 小時(shí)，隨著數(shù)據(jù)量越來(lái)越大，就滿足不了這種性能需求，所以就有改造的需要。

由于監(jiān)管的嚴(yán)格要求，所以反洗錢系統(tǒng)在性能上也提出了比較強(qiáng)的要求：

• 滿足 SQL2003 的標(biāo)準(zhǔn)；

• 多表關(guān)聯(lián)，能夠查詢數(shù)據(jù)集 1 千萬(wàn)以下，響應(yīng)時(shí)間 5 秒以內(nèi)；

• 數(shù)據(jù)文件批量加載，20G 大小，大概不能超過(guò) 30 分鐘；

• 億萬(wàn)數(shù)據(jù)中要?jiǎng)h除 50 萬(wàn)數(shù)據(jù)，響應(yīng)時(shí)間要在 10 秒之內(nèi)；

• 3 億數(shù)據(jù)中刪除兩千萬(wàn)，也要有 10 秒之內(nèi)的響應(yīng)時(shí)間；

• 3 億數(shù)據(jù)量更新 100 萬(wàn)，響應(yīng)時(shí)間 5 分鐘左右。

評(píng)估下來(lái)使用 TiDB 是能夠完成這種性能要求的，所以就選擇了 TiDB 的方案。

我們按照 TiDB 的形式進(jìn)行架構(gòu)升級(jí)，從原來(lái)的 Oracle 同步到 TiDB 使用的是（OGG for MySQL client ) 來(lái)完成的。還有一部分?jǐn)?shù)據(jù)是在大數(shù)據(jù)平臺(tái)，我們使用大數(shù)據(jù)的發(fā)布功能，從 Hive 直接去同步到 TiDB。

這里我們?cè)诜聪村X系統(tǒng)上做了四項(xiàng)性能對(duì)比的測(cè)試，包括反洗錢查詢業(yè)務(wù)性能對(duì)比、反洗錢插入業(yè)務(wù)性能對(duì)比、反洗錢更新業(yè)務(wù)對(duì)比，以及反洗錢的刪除性能對(duì)比。從測(cè)試結(jié)果來(lái)看，整體跑批性能提高了 3 倍以上，跑批時(shí)間也縮短到原來(lái)的 ?，平臺(tái)整體有效處理能力提升到 5 倍以上，進(jìn)一步滿足了反洗錢的需求。

向核心進(jìn)發(fā)

最后介紹我們下一步的目標(biāo)。下一階段我們將會(huì)擴(kuò)大應(yīng)用范圍，把業(yè)務(wù)發(fā)展快、規(guī)模大的核心鏈路的系統(tǒng)逐步往 TiDB 遷移。主要是目前外部環(huán)境發(fā)生了很多的變化，未來(lái)可能在數(shù)據(jù)庫(kù)上也會(huì)做很多的限制，所以我們必須提前做一些準(zhǔn)備。

另一方面也是出于性能的考慮。大家可以看這個(gè)監(jiān)控圖，是翼支付的一個(gè)活動(dòng)中，核心系統(tǒng)的 QPS 和 CPU。可以看出來(lái)，在活動(dòng)的高峰我們使用的系統(tǒng)是兩臺(tái)高端的小機(jī)和高端存儲(chǔ)，其中一個(gè)單節(jié)點(diǎn)的執(zhí)行量大概在 8 萬(wàn) 4，這時(shí)候 CPU 的最小貢獻(xiàn)在 10%，說(shuō)明我們的性能已經(jīng)基本達(dá)到上限了，一旦后面有業(yè)務(wù)增長(zhǎng)，數(shù)據(jù)規(guī)模再增長(zhǎng)的時(shí)候，性能可能會(huì)出現(xiàn)一些瓶頸，小機(jī)設(shè)備難以擴(kuò)容，這也是核心鏈路上考慮分布式數(shù)據(jù)庫(kù)的原因。因此我們可以利用 TiDB 的分布式特性進(jìn)行水平的擴(kuò)展，使業(yè)務(wù)得到一個(gè)快速的擴(kuò)容。當(dāng)前還處于一個(gè)調(diào)研階段，由于核心系統(tǒng)對(duì)穩(wěn)定性和性能的要求也是對(duì) TiDB 數(shù)據(jù)庫(kù)的挑戰(zhàn)，這是我們下一步的目標(biāo)。

我們目前的核心庫(kù)都會(huì)有上億數(shù)據(jù)量的規(guī)模，單庫(kù)總數(shù)據(jù)量 10T 以上，在探索的過(guò)程中，我們也產(chǎn)生了很多的構(gòu)想，主要是核心業(yè)務(wù)可能停機(jī)時(shí)間非常短或不能停，難度會(huì)非常高。

這方面我們可能需要在開(kāi)發(fā)模式上進(jìn)行更新，包括：

• Oracle 和 TiDB 共存的雙模式開(kāi)發(fā)；

• 灰度或者雙寫(xiě)的切換過(guò)程；

• 具備業(yè)務(wù)校驗(yàn)?zāi)芰Γ?/p>

• 模塊和批次進(jìn)度的設(shè)計(jì)。

在運(yùn)維管理上也會(huì)有一些更高的要求，包括窗口的切換操作的過(guò)程、回退的預(yù)案等。

攜手趟坑

1.insert 周期性超時(shí)。

早期 2.0 版本某業(yè)務(wù)出現(xiàn)過(guò) TiDB 的 insert 約每秒 2W 周期性零星 200 毫秒的超時(shí)，排查原因由于 Region 數(shù)量快速上漲， Raftstore 單線程工作帶來(lái)性能瓶頸，臨時(shí)增加 Heartbeat 的周期來(lái)解決，后期升級(jí)到 3.0.8 的版本，通過(guò) Raftstore 多線程工作已解決此問(wèn)題。

2.執(zhí)行計(jì)劃不準(zhǔn)，走錯(cuò)索引。

早期的 2.0 版本出現(xiàn)過(guò)若干次 TiDB 的統(tǒng)計(jì)信息不準(zhǔn)導(dǎo)致執(zhí)行計(jì)劃出錯(cuò)，業(yè)務(wù)受影響。我們嘗試在每小時(shí)進(jìn)行一個(gè)全庫(kù)表的分析，但是這個(gè)問(wèn)題仍然會(huì)間歇性的出現(xiàn)。目前是通過(guò)升級(jí)到 3.0.8 基本解決掉了。

3.備份并發(fā)數(shù)過(guò)高，導(dǎo)致備份時(shí)間的業(yè)務(wù)偶發(fā)超時(shí)。

在某個(gè)業(yè)務(wù)使用 TiDB 3.0.8 版本，庫(kù)容量約 8T，凌晨 3 點(diǎn)發(fā)起備份，造成業(yè)務(wù)偶發(fā)超時(shí)。經(jīng)排查發(fā)現(xiàn)是備份引起，因?yàn)?TiDB 大于 TiKV 備份時(shí)占用業(yè)務(wù)網(wǎng)帶寬太大，通過(guò)減小備份并發(fā)來(lái)解決。

4.TiDB+keepalived 的問(wèn)題。

TiDB 的負(fù)載均衡策略使用 HAproxy+keepalived 方案，keepalived 使用 2.0.18 的版本發(fā)現(xiàn)偶發(fā)丟包，造成業(yè)務(wù)超時(shí)。后來(lái)替換為低版本的 1.2.8 后解決，這塊建議希望 TiDB 能統(tǒng)一訪問(wèn)層也能自己實(shí)現(xiàn)，多一個(gè)外部組件就多了一個(gè)故障點(diǎn)。

5.樂(lè)觀鎖和悲觀鎖的問(wèn)題。

TiDB 3.0.8 之前的版本使用樂(lè)觀鎖模型，從 MySQL 遷移過(guò)來(lái)的應(yīng)用，在事物中執(zhí)行 DML 語(yǔ)句時(shí)不像 MySQL 那樣使用行級(jí)鎖鎖定相關(guān)記錄行，只有在事物真正提交時(shí)才會(huì)檢查寫(xiě)沖突，這些雖然可以通過(guò)應(yīng)用改造來(lái)解決，但也確實(shí)造成了遷移成本的提高，對(duì)開(kāi)發(fā)人員造成了一些困擾。但 TiDB 4.0 版本的悲觀鎖特性比較成熟，也讓我們對(duì)核心遷移有更多的期待以及更好的基礎(chǔ)。

最后引用魯迅先生的一句話，世上本沒(méi)有路，走的人多了便成了路。架構(gòu)落地的過(guò)程探索是非常艱辛的，但這也值得每一個(gè)企業(yè)去做，在當(dāng)下這個(gè)時(shí)代，不管企業(yè)的規(guī)模如何，都要學(xué)會(huì)借助開(kāi)源的力量，避免去重復(fù)的造輪子。如果企業(yè)規(guī)模小，可以直接用開(kāi)源軟件來(lái)解決痛點(diǎn)，如果企業(yè)規(guī)模大，可以投身進(jìn)入開(kāi)源者軟件的開(kāi)發(fā)，成為貢獻(xiàn)者，同時(shí)也解決自己的問(wèn)題。

每一個(gè)看似輕松的背后都有不為人知的努力，每一個(gè)看似光鮮亮麗的背后，都有不為人知的付出。分布式數(shù)據(jù)庫(kù)建設(shè)之路道阻且長(zhǎng)，我們翼支付的人有信心也有動(dòng)力把他做好。

以上就是關(guān)于“TiDB使用的坑有哪些”這篇文章的內(nèi)容，相信大家都有了一定的了解，希望小編分享的內(nèi)容對(duì)大家有幫助，若想了解更多相關(guān)的知識(shí)內(nèi)容，請(qǐng)關(guān)注億速云行業(yè)資訊頻道。