摘要：性能數(shù)據(jù)可以通過(guò)水平擴(kuò)容的方式提升性能，以下為在固定配置下的數(shù)據(jù)表現(xiàn)。每個(gè)鍵值對(duì)不超過(guò)，鍵值對(duì)的總大小不超過(guò)。定價(jià)計(jì)費(fèi)方式為用戶提供服務(wù)，實(shí)行按小時(shí)計(jì)費(fèi)方式。

性能數(shù)據(jù)

TiDB可以通過(guò)水平擴(kuò)容的方式提升性能，以下為TiDB在固定配置下的數(shù)據(jù)表現(xiàn)。

測(cè)試環(huán)境

1 tidb版本: v3.0.5

2 tikv節(jié)點(diǎn)數(shù): 3（單節(jié)點(diǎn)內(nèi)存使用約30G）

3 線程: 512

4 表: 32 * 6000萬(wàn)條數(shù)據(jù)

5 數(shù)據(jù)量約1.3T

6 事務(wù): 1000萬(wàn)

7 測(cè)試時(shí)間: 600(s)

8 sysbench: v1.0.13

跨可用區(qū)類型

同可用區(qū)類型

FAQ

Q1:TiDB當(dāng)前覆蓋多少地域？

TiDB當(dāng)前僅在北京二地域開放。有需要使用的用戶請(qǐng)聯(lián)系技術(shù)支持或者客戶經(jīng)理開放使用。

Q2：每個(gè)小時(shí)我們要?jiǎng)?chuàng)建一些中間表，完成計(jì)算，然后刪除掉？頻繁創(chuàng)建和刪除表對(duì)TiDB 性能影響大嗎？

從技術(shù)實(shí)現(xiàn)的角度，對(duì)影響并沒有很大的影響，因?yàn)槟忝總€(gè)小時(shí)操作的庫(kù)都是不一樣的，都是獨(dú)立的數(shù)據(jù)， 但會(huì)影響gc，如果你們每個(gè)小時(shí)的數(shù)據(jù)量很大的話，會(huì)有一定的影響，數(shù)據(jù)量小可以忽略。其實(shí)就是頻繁刪 除數(shù)據(jù)，主要是這里影響，數(shù)據(jù)刪除之后，在一定時(shí)間被gc，如果堆積的量大的話，會(huì)影響寫入的性能.

Q3: slow log 里面的時(shí)間是什么時(shí)區(qū)？

admin show slow 是跟著服務(wù)所在宿主機(jī)的時(shí)區(qū)的，沒法設(shè)置，建議使用select語(yǔ)句查詢，select 會(huì)應(yīng)用你設(shè)置的時(shí)區(qū)信息。

select * from information_schema.slow_query ;

admin show slow log top 4;

Q4: 對(duì)于一張大表insert into t2 select * from t1; 失敗報(bào)錯(cuò) ERROR 2013 (HY000): Lost connection to MySQL server during query

這種情況基本上是 Transaction too large

TiDB對(duì)事務(wù)有限制：

單個(gè)事務(wù)包含的 SQL 語(yǔ)句不超過(guò) 100000 條。每個(gè)鍵值對(duì)不超過(guò) 6MB，鍵值對(duì)的總大小不超過(guò) 100MB。

Q5: TiDB 是否支持 select for update？

支持，但語(yǔ)義上和 MySQL 有區(qū)別，TiDB 是分布式數(shù)據(jù)庫(kù)，采用的樂觀鎖機(jī)制，也就說(shuō) select for update 不在事務(wù)開啟就鎖住數(shù)據(jù)，而是其他事務(wù)在提交的時(shí)候進(jìn)行沖突檢查，如有沖突，會(huì)進(jìn)行回滾。

Q6: 事務(wù)太大(insert ... select)，或者select..for update，以及網(wǎng)絡(luò)問題，執(zhí)行事務(wù)TiDB會(huì)返回錯(cuò)誤，有什么辦法可以區(qū)分嗎？

可根據(jù)TiDB的 error codes 去判斷

Q7: TIDB能否支持session級(jí)別的悲觀鎖

執(zhí)行 set @@tidb_txn_mode = pessimistic;，使這個(gè) session 執(zhí)行的所有顯式事務(wù)（即非 autocommit 的事務(wù)）都會(huì)進(jìn)入悲觀事務(wù)模式。

Q8：TiDB binlog的目標(biāo)端在以下情況不支持udb-mysql5.6.41版本

udb-mysql5.6.41的索引鍵前綴默認(rèn)限制為767字節(jié)，TiDB的表設(shè)計(jì)的key過(guò)長(zhǎng)，全量同步時(shí)會(huì)報(bào)錯(cuò)。

如果一定要使用udb-mysql5.6版本，需如下操作：

1.目標(biāo)端啟用系統(tǒng)變量innodb_large_prefix

  1).系統(tǒng)變量innodb_large_prefix為ON

  2).系統(tǒng)變量innodb_file_format為Barracuda

如果用戶權(quán)限不夠，先調(diào)整自己的super權(quán)限：

mysql>update mysql.user set super_priv = Y where user = root;

mysql>flush privileges;

mysql>set global innodb_large_prefix=on;

mysql>set global innodb_file_format=Barracuda;

2.源端需要修改表屬性：

mysql> ALTER TABLE TEST ROW_FORMAT=DYNAMIC;

目標(biāo)端支持：udb-mysql 5.7

Q9：在 TiDB 中，表或字段設(shè)置為utf8 和 設(shè)置為 utf8mb4 的效果是否一樣

v2.1.3及其后續(xù)版本，默認(rèn)字符集由uft8改為utf8mb4，效果是一樣的，但為了保證備份數(shù)據(jù)和binlog導(dǎo)出的數(shù)據(jù)能兼容其他數(shù)據(jù)庫(kù)，需顯式的指定為utf8mb4

Q10: TiDB 加個(gè)聯(lián)合索引會(huì)鎖表嗎

首先，TiDB內(nèi)部沒有鎖表的機(jī)制：https://pingcap.com/docs-cn/dev/reference/sql/statements/flush-tables/#mysql-%E5%85%BC%E5%AE%B9%E6%80%A7

其次，TiDB 中，ADD INDEX 為在線操作，不會(huì)阻塞表中的數(shù)據(jù)讀寫。https://pingcap.com/docs-cn/dev/reference/sql/statements/add-index/

但是， 如果在創(chuàng)建索引的時(shí)候，剛好跟要讀寫的數(shù)據(jù) 碰巧是同一部分?jǐn)?shù)據(jù)，這個(gè)是會(huì)影響的，因?yàn)閯?chuàng)建索引需要填充數(shù)據(jù)，也會(huì)涉及讀寫操作。

從歷史版本讀就不影響讀取的速度。

Q11:TiDB默認(rèn)時(shí)區(qū)

當(dāng)前實(shí)例創(chuàng)建完成后，默認(rèn)時(shí)區(qū)為UTC時(shí)間，如果用戶需要CST時(shí)間，需要手動(dòng)設(shè)置時(shí)區(qū)+8

set @@time_zone = +8:00;   SET GLOBAL time_zone =+8:00;

重新連接mysql即可生效

Q12:查看TiDB創(chuàng)建索引的過(guò)程是否已經(jīng)結(jié)束

通過(guò)“admin show ddl;”語(yǔ)句查看當(dāng)前job的進(jìn)度

Q13：TiDB最大連接數(shù)

系統(tǒng)變量max_connections僅為兼容MySQL而設(shè)計(jì)，并無(wú)實(shí)際效果；

單TiDB實(shí)例(流量限制)當(dāng)前支持最大3000個(gè)session（可擴(kuò)容）；

Q14: SQL執(zhí)行時(shí)間突然變長(zhǎng)

在執(zhí)行SQL語(yǔ)句前，TiDB會(huì)通過(guò)統(tǒng)計(jì)信息計(jì)算出執(zhí)行計(jì)劃，選擇全表掃還是從索引中獲取數(shù)據(jù)，如果一張表數(shù)據(jù)量非常大，TiDB的選擇算法誤差比較大，一旦選擇全表掃，會(huì)嚴(yán)重影響集群性能，建議強(qiáng)制使用索引

use index(index_name):https://book.tidb.io/session4/chapter6/sql-optimization-cases.html#%E6%A1%88%E4%BE%8B5-sql-%E6%89%A7%E8%A1%8C%E8%AE%A1%E5%88%92%E4%B8%8D%E5%87%86

Q15: 如何通過(guò)tableID 查找表名

INFORMATION_SCHEMA.TABLES 中有對(duì)應(yīng)關(guān)系。

TiDB定價(jià)

1. 計(jì)費(fèi)方式

UCloud TiDB Service 為用戶提供serverless服務(wù)， 實(shí)行按小時(shí)計(jì)費(fèi)方式。

2. 計(jì)費(fèi)內(nèi)容

TiDB 集群費(fèi)用

具體收費(fèi)內(nèi)容如下：

| 類型 | 單價(jià)(元/小時(shí)/GB）| 組件|
| ------- | ------- | ------- |
| 硬盤（NVME） | 0.004 | TiKV Pump TiFlash |
| 內(nèi)存 | 0.2 | TiKV Pump Drainer TiFlash |

備份數(shù)據(jù)存儲(chǔ)費(fèi)用

對(duì)于同可用區(qū)實(shí)例， 如果用戶開啟了備份功能，備份數(shù)據(jù)存儲(chǔ)在用戶的US3空間中，US3的費(fèi)用由用戶承擔(dān)。

實(shí)時(shí)文檔請(qǐng)前往：https://docs.ucloud.cn/tidb/price