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

性能數據

TiDB可以通過水平擴容的方式提升性能，以下為TiDB在固定配置下的數據表現。

測試環境

1 tidb版本: v3.0.5

2 tikv節點數: 3（單節點內存使用約30G）

3 線程: 512

4 表: 32 * 6000萬條數據

5 數據量約1.3T

6 事務: 1000萬

7 測試時間: 600(s)

8 sysbench: v1.0.13

跨可用區類型

同可用區類型

FAQ

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

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

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

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

Q3: slow log 里面的時間是什么時區？

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

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 有區別，TiDB 是分布式數據庫，采用的樂觀鎖機制，也就說 select for update 不在事務開啟就鎖住數據，而是其他事務在提交的時候進行沖突檢查，如有沖突，會進行回滾。

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

可根據TiDB的 error codes 去判斷

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

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

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

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

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

1.目標端啟用系統變量innodb_large_prefix

  1).系統變量innodb_large_prefix為ON

  2).系統變量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及其后續版本，默認字符集由uft8改為utf8mb4，效果是一樣的，但為了保證備份數據和binlog導出的數據能兼容其他數據庫，需顯式的指定為utf8mb4

Q10: TiDB 加個聯合索引會鎖表嗎

首先，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 為在線操作，不會阻塞表中的數據讀寫。https://pingcap.com/docs-cn/dev/reference/sql/statements/add-index/

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

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

Q11:TiDB默認時區

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

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

重新連接mysql即可生效

Q12:查看TiDB創建索引的過程是否已經結束

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

Q13：TiDB最大連接數

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

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

Q14: SQL執行時間突然變長

在執行SQL語句前，TiDB會通過統計信息計算出執行計劃，選擇全表掃還是從索引中獲取數據，如果一張表數據量非常大，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 |

備份數據存儲費用

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

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