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

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

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

測試環(huán)境

1 tidb版本: v3.0.5

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

3 線程: 512

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

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

6 事務: 1000萬

7 測試時間: 600(s)

8 sysbench: v1.0.13

跨可用區(qū)類型

同可用區(qū)類型

FAQ

Q1:TiDB當前覆蓋多少地域？

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

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

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

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

admin show slow 是跟著服務所在宿主機的時區(qū)的，沒法設置，建議使用select語句查詢，select 會應用你設置的時區(qū)信息。

select * from information_schema.slow_query ;

admin show slow log top 4;

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

這種情況基本上是 Transaction too large

TiDB對事務有限制：

單個事務包含的 SQL 語句不超過 100000 條。每個鍵值對不超過 6MB，鍵值對的總大小不超過 100MB。

Q5: TiDB 是否支持 select for update？

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

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

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

Q7: TIDB能否支持session級別的悲觀鎖

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

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

udb-mysql5.6.41的索引鍵前綴默認限制為767字節(jié)，TiDB的表設計的key過長，全量同步時會報錯。

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

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

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

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

如果用戶權限不夠，先調整自己的super權限：

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;

目標端支持：udb-mysql 5.7

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

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

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

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

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

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

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

Q11:TiDB默認時區(qū)

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

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

重新連接mysql即可生效

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

通過“admin show ddl;”語句查看當前job的進度

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

系統(tǒng)變量max_connections僅為兼容MySQL而設計，并無實際效果；

單TiDB實例(流量限制)當前支持最大3000個session（可擴容）；

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

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

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: 如何通過tableID 查找表名

INFORMATION_SCHEMA.TABLES 中有對應關系。

TiDB定價

1. 計費方式

UCloud TiDB Service 為用戶提供serverless服務， 實行按小時計費方式。

2. 計費內容

TiDB 集群費用

具體收費內容如下：

| 類型 | 單價(元/小時/GB）| 組件|
| ------- | ------- | ------- |
| 硬盤（NVME） | 0.004 | TiKV Pump TiFlash |
| 內存 | 0.2 | TiKV Pump Drainer TiFlash |

備份數(shù)據(jù)存儲費用

對于同可用區(qū)實例， 如果用戶開啟了備份功能，備份數(shù)據(jù)存儲在用戶的US3空間中，US3的費用由用戶承擔。

實時文檔請前往：https://docs.ucloud.cn/tidb/price