## 1. Project Overview & Quickstart (Vanessa219/multi-unique-key-adjust)

# multi-unique-key-adjust

Open-source repository Vanessa219/multi-unique-key-adjust

### Repository Details
- **Repository:** [Vanessa219/multi-unique-key-adjust](https://github.com/Vanessa219/multi-unique-key-adjust)
- **Primary Language:** Code

*Note: High-volume repository documentation is actively indexed and synchronized by YakaAI.*

## 2. Official Technical Reference & Guides (Vanessa219/docs)

## File: README.md

# TenDB Cluster
TenDB Cluster is a MySQL distributed relational database solution developed and maintained by Tencent Game CROS DBA team. It consists of three core components: TSpider, TenDB and Tdbctl.   

TSpider is the proxy layer of TenDB Cluster. It is a customized version developed by Tencent Game CROS DBA based on MariaDB 10.3.7. It mainly improves and customizes the distributed MySQL storage engine of Spider; TSpider [github page](https://github.com/Tencent/TenDBCluster-TSpider)

TenDB is the data layer of TenDB Cluster. It is a customized MySQL branch developed by Tencent Game CROS DBA based on Percona Server 5.7.20. It provides some great features internally for business operations; TenDB [github page](https://github.com/Tencent/TenDBCluster-TenDB)

Tdbctl is the control layer of TenDB Cluster. It is developed by Tencent Game CROS DBA team based on TenDB (mainly reuse TenDB's own SQL parsing capabilities and MGR capabilities). It provides cluster routing management, cluster DDL operating, cluster monitoring and some other cluster capabilities. Tdbctl [github page](https://github.com/Tencent/TenDBCluster-Tdbctl)

## Introduction to TenDB Cluster
TenDB Cluster is a MySQL distributed relational database solution developed and maintained by Tencent Game DBA team. The main features include: transparent database/table sharding, high-availability, online scaling. With these features, developers can focus on the development and operation of their product without caring about data sharding logic. Also, in the case of massive concurrency, there is no need to care about the load pressure of the DB storage layer.

## Quick Start
For more detail, see Chapter: [Quick Deployment With Docker Compose](Documentation/op-guide/docker-compose-tendbcluster-en.md)


## [Documentation](http://tendbcluster.com/)
For details, see [Reference Manual](http://tendbcluster.com/)

## Flexible Deployment
It is recommended to use TSpider + TenDB + Tdbctl to deploy TenDB Cluster.   
However, developers can also flexibly deploy TenDB Cluster according to their own online situation. Currently, companies use TSpider + Tencent Cloud RDS or TSpider + AWS RDS to deploy TenDB Cluster clusters.

## Contact us
For any questions or discussions about TenDB Cluster, please feel free to give us feedback via issues:     
TSpider:  https://github.com/Tencent/TenDBCluster-TSpider/issues   
TenDB:    https://github.com/Tencent/TenDBCluster-TenDB/issues   
Tdbctl:   https://github.com/Tencent/TenDBCluster-Tdbctl/issues 


## Roadmap
For details, see [chapter Roadmap](Documentation/roadmap-en.md)


## License
TenDBCluster is licensed under the GNU General Public License Version 2, except for the third-party components listed below. Copyright and license information can be found in the file TenDBCluster-License.


## Acknowledgements
Thanks to MariaDB and Percona for their outstanding contributions to the MySQL open source ecosystem, it was on the shoulders of the predecessors that TenDB Cluster was born.    
In addition, special thanks to the outstanding developers, contributors. For details, see [chapter acknowledgements](Documentation/acknowledgements-en.md)

---

## File: Documentation/com-problem/multi-unique-key-adjust.md

# 多唯一键调整
基于TSpider分区键[选取规则](../re-book/ddl-syntax.md#shard_key)，如果建表是出现多唯一键，则需要进行调整。本文提供一些多唯一键调整经验。

## 同时存在主键与唯一键
若表结构中包含有两个及以上的唯一键（主键是唯一键的一种），且无共同组成部分。要求只保留一个唯一键，其它唯一键变更为普通索引，应用层来保证其它字段的唯一性  


原表：
```
MariaDB [tendb_test]> CREATE TABLE `guild_user` 
    -> (  
    ->   `GID` bigint(20) NOT NULL DEFAULT '0',  
    ->   `UserId` bigint(20) NOT NULL DEFAULT '0',  
    ->    `GuildJob` tinyint(1) unsigned NOT NULL DEFAULT '0',  
    ->   `Contribution` int(10) unsigned DEFAULT '0',  
    ->   `Contribution_Total` int(10) unsigned DEFAULT '0', 
    ->   PRIMARY KEY `userid_index` (`UserId`),  
    ->   UNIQUE KEY `GID_index` (`GID`)
    -> ) ENGINE=InnoDB DEFAULT CHARSET=utf8;
ERROR 4151 (HY000): Failed to execute ddl, Error code: 12021, Detail Error Messages: CREATE TABLE ERROR: ERROR: too more unique key with the different pre key
```


修改后：需要应用层来保证 GID的唯一性  
```
MariaDB [tendb_test]> CREATE TABLE `guild_user` 
    -> (  
    ->   `GID` bigint(20) NOT NULL DEFAULT '0',  
    ->   `UserId` bigint(20) NOT NULL DEFAULT '0',  
    ->    `GuildJob` tinyint(1) unsigned NOT NULL DEFAULT '0',  
    ->   `Contribution` int(10) unsigned DEFAULT '0',  
    ->   `Contribution_Total` int(10) unsigned DEFAULT '0', 
    ->   PRIMARY KEY `userid_index` (`UserId`),  
    ->  KEY `GID_index` (`GID`)
    -> ) ENGINE=InnoDB DEFAULT CHARSET=utf8;
Query OK, 0 rows affected (0.07 sec)
```





若auto_increment列为主键，而唯一键为其他字段，可以将auto_increment列修改为普通index。自增列作为普通Key, 也能保证唯一。

原表:
```
MariaDB [tendb_test]> CREATE TABLE `guild_list` 
    -> (  
    ->      `idx` bigint(20) unsigned NOT NULL AUTO_INCREMENT,  
    ->      `GID` bigint(20) NOT NULL DEFAULT '0',  
    ->      `GName` varchar(64) NOT NULL DEFAULT '',  
    ->      `CreateTime` datetime NOT NULL DEFAULT '0000-00-00 00:00:00',  
    ->       `Data` blob,  
    ->       PRIMARY  KEY (`idx`),  
    ->       UNIQUE KEY `GName_index` (`GName`)
    -> ) 
    -> ;
ERROR 4151 (HY000): Failed to execute ddl, Error code: 12021, Detail Error Messages: CREATE TABLE ERROR: ERROR: too more unique key with the different pre key
```
修改后，将自增列作为普通Key, 也能保证唯一。
```
MariaDB [tendb_test]> CREATE TABLE `guild_list` 
    -> (  
    ->      `idx` bigint(20) unsigned NOT NULL AUTO_INCREMENT,  
    ->      `GID` bigint(20) NOT NULL DEFAULT '0',  
    ->      `GName` varchar(64) NOT NULL DEFAULT '',  
    ->      `CreateTime` datetime NOT NULL DEFAULT '0000-00-00 00:00:00',  
    ->       `Data` blob,  
    ->       KEY (`idx`),  
    ->       PRIMARY KEY `GName_index` (`GName`)
    -> ) ENGINE=InnoDB DEFAULT CHARSET=utf8;
Query OK, 0 rows affected (0.04 sec)

```




注意   
>业务中不允许表的唯一键超过一个，除非各个唯一键有共同部分，且指定该共同部分为分区键

---

## File: Documentation/com-problem/multi-unique-key-adjust-en.md

# Multi-unique Key Adjustment
Based on the TSpider [Shard Key selection rules](../re-book/ddl-syntax-en.md#shard_key), if the TABLE has multiple unique keys, you need to do some adjustment. This article provides some experiences with multiple unique keys adjustments.

## More than One Unique Keys
If the TABLE has two or more unique keys (the primary key is a kind of unique key too), only one unique key is required to be kept, other unique keys should be changed to ordinary indexes, and the application layer should ensures the uniqueness of them  


Original TABLE:

```
MariaDB [tendb_test]> CREATE TABLE `guild_user` 
    -> (  
    ->   `GID` bigint(20) NOT NULL DEFAULT '0',  
    ->   `UserId` bigint(20) NOT NULL DEFAULT '0',  
    ->    `GuildJob` tinyint(1) unsigned NOT NULL DEFAULT '0',  
    ->   `Contribution` int(10) unsigned DEFAULT '0',  
    ->   `Contribution_Total` int(10) unsigned DEFAULT '0', 
    ->   PRIMARY KEY `userid_index` (`UserId`),  
    ->   UNIQUE KEY `GID_index` (`GID`)
    -> ) ENGINE=InnoDB DEFAULT CHARSET=utf8;
ERROR 4151 (HY000): Failed to execute ddl, Error code: 12021, Detail Error Messages: CREATE TABLE ERROR: ERROR: too more unique key with the different pre key
```


After Adjustment: 
The application layer is required to guarantee the uniqueness of GID  

```
MariaDB [tendb_test]> CREATE TABLE `guild_user` 
    -> (  
    ->   `GID` bigint(20) NOT NULL DEFAULT '0',  
    ->   `UserId` bigint(20) NOT NULL DEFAULT '0',  
    ->    `GuildJob` tinyint(1) unsigned NOT NULL DEFAULT '0',  
    ->   `Contribution` int(10) unsigned DEFAULT '0',  
    ->   `Contribution_Total` int(10) unsigned DEFAULT '0', 
    ->   PRIMARY KEY `userid_index` (`UserId`),  
    ->  KEY `GID_index` (`GID`)
    -> ) ENGINE=InnoDB DEFAULT CHARSET=utf8;
Query OK, 0 rows affected (0.07 sec)
```


If the auto_increment column is the primary key and the unique key is another column, you can modify the auto_increment column to an ordinary index. As an ordinary key, the auto-inc column will be guaranteed to be unique by TenDB Cluster.

Original TABLE:

```
MariaDB [tendb_test]> CREATE TABLE `guild_list` 
    -> (  
    ->      `idx` bigint(20) unsigned NOT NULL AUTO_INCREMENT,  
    ->      `GID` bigint(20) NOT NULL DEFAULT '0',  
    ->      `GName` varchar(64) NOT NULL DEFAULT '',  
    ->      `CreateTime` datetime NOT NULL DEFAULT '0000-00-00 00:00:00',  
    ->       `Data` blob,  
    ->       PRIMARY  KEY (`idx`),  
    ->       UNIQUE KEY `GName_index` (`GName`)
    -> ) 
    -> ;
ERROR 4151 (HY000): Failed to execute ddl, Error code: 12021, Detail Error Messages: CREATE TABLE ERROR: ERROR: too more unique key with the different pre key
```

After Adjustment, the auto-inc column `idx` will be guaranteed to be unique by TenDB Cluster.

```
MariaDB [tendb_test]> CREATE TABLE `guild_list` 
    -> (  
    ->      `idx` bigint(20) unsigned NOT NULL AUTO_INCREMENT,  
    ->      `GID` bigint(20) NOT NULL DEFAULT '0',  
    ->      `GName` varchar(64) NOT NULL DEFAULT '',  
    ->      `CreateTime` datetime NOT NULL DEFAULT '0000-00-00 00:00:00',  
    ->       `Data` blob,  
    ->       KEY (`idx`),  
    ->       PRIMARY KEY `GName_index` (`GName`)
    -> ) ENGINE=InnoDB DEFAULT CHARSET=utf8;
Query OK, 0 rows affected (0.04 sec)

```



## Note   
TenDB Cluster do not allow more than one unique keys in a TABLE, unless each unique key has the same common part, and the common part is designated as the Shard Key

---

## File: Documentation/com-problem/problem-analysis.md

# FAQ

下面对TenDB Cluster集群使用中，用户的常见问题进行说明。

## 1. 常见问题

### 1.1 ERROR 12701
> ERROR 12701 (HY000): Remote MySQL server has gone away

12701错误有些也会伴随有错误1159，因网络导致的异常。   
接入层TSpider通过连接池与和存储层交互； 在存储实例单方便把连接断开时接入层TSpider没有感知到这个信息； 当前新请求过来TSpider使用到该异常的连接时就会报12701的错误。以下几种方式可以TSpider侧的异常连接快速释放：
1. 设置spider_idle_conn_recycle_interval=8（最小值），则8秒后所有空闲连接都会释放
2. 在TSpider上重复发送请求，新的请求即可正常执行。（旧的连接因为执行出错会被回收）
3. 重启TSpider节点，则一次性释放所有连接

### 1.2 ERROR 12723
> ERROR 12723 (HY000): Too many connections between spider and remote

接入层TSpider通过连接池与存储实例交互，TSpider和每个存储实例最多同时维护spider_max_connections个数的连接，在应用层瞬间新请求过多会造成spider_max_connections不够用的情况。  因此可通过如下方法解决此类问题：
1. 适当调大spider_max_connections到能够满足要求
2. 针对应用请求进行优化，如果SQL执行够快，那么占用的连接资源就会更少

### 1.3 ERROR 1477
> ERROR 1477 (HY000): The foreign server name you are trying to reference does not exist. Data source error:  SPT0

建表使用的server(SPT0)并不存在，可以检查mysql.servers表是否真的不存在； 如果mysql.servers表中存在SPT0却还报错，说明该server没有执行flush privileges生效

### 1.4 ERROR 1429
> MySQL error code 1429 (ER_CONNECT_TO_FOREIGN_DATA_SOURCE): Unable to connect to foreign data source: %.64s

某个后端存储实例故障，导致对应的server不可用；需要进行主备切换或者修复故障实例

### 1.5 Out of sync错误
非预期的TSpider向存储实例请求数据时出现异常，设置spider_idle_conn_recycle_interval为8（快速释放掉空闲连接），执行flush tables可解决。


### 1.6 自增列
TSpider只保证自增列的唯一性， 有空洞、且不保证自增字段的有序；更多信息参见[自增列](../re-book/auto-increase.md)章节

### 1.7 SQL请求慢
1. 可以打开general_log、 spider_general_log，查看当前请求的分发请求是否符合预期；分发到存储实例执行的请求是否命中索引   
2. 可以设置spider_bgs_mode=1让读操作并行
3. 对涉及多个shard的update/delete/insert操作，在打开spider_bgs_mode前提下打开spider_bgs_dml，让update/delete/insert操作并行
4. 关注存储实例和TSpider间的网络延迟   

### 1.8 OOM
`TSpider OOM`   
用户一次拉取的数据量过大； 尽量避免在TSpider一次性拉取过量数据，非要这样用避免OOM的办法是设置spider_quick_mode=3   
`TenDB OOM`   
通常是buffer pool配置过大，且瞬间连接过多导致；   解决方法是调低buffer pool，使用连接池处理连接问题； TSpider侧也可以调下spider_max_connections；

### 1.9 多唯一键错误
TSpider的唯一键约束规则和MySQL分区表规则相同，多唯一键问题详见[多唯一键调整](multi-unique-key-adjust.md)章节


### 1.10 调整shard key
调整shard key详见 [shard key选取](shard-key-choose.md)章节

### 1.11 TSpider出入流量相差大
一般是TSpider的入流量比出流量大，导致这个原因是部分请求需要拉取大量数据到TSpider层进行计算，TSpider只返回给应用计算后的结果； 比如全表排序取最大的记录，会就导致入流量大于出流量。

### 1.12 存储实例负载不均
考虑shard_key是否配置合理，导致数据及请求分布不均

### 1.13 查询超时
执行复杂查询，可能返回结果超时，一般是因为spider_net_read_timeout/spider_net_write_timeout配置过小

### 1.14 统计信息
通过全局参数spider_get_sts_or_crd开启统计信息，统计信息存储在系统表`mysql`.`spider_table_status`中；   `spider_modify_status_interval`为刷新统计信息的间隔时间。



## 2. 与MySQL的差异性
详见章节[与MySQL的差异](../re-book/mysql-compatibility.md/#jump)
## 3. 架构
详见章节[架构](../architecture.md)
## 4. 事务
详见章节[事务](../re-book/transaction.md)
## 5. SQL语法
详见章节[SQL语法](../re-book/sql-grammar.md)

---

## File: Documentation/com-problem/problem-analysis-en.md

# TenDB Cluster Common Problem(FAQ)

The following describes common problems of using TenDB cluster.

## 1. Client Error Code
###  1.1 ERROR 12701
> ERROR 12701 (HY000): Remote MySQL server has gone away
	 
Usually, Error Code 12701 come with Error Code 1159, it maybe caused by Network partition error.
TSpider Node use connection pool to interactive with all the TenDB Node, some network partition error may cause TenDB Node unilateral close the connection from the TSpider Node. When the TSpider Node accept new query from the client, it will reuse the problematic connection so it will return Error Code 12701 to the client. that is three ways to quickly release the problematic connection:

a. Set the global variables on TSpider Nodes, spider_idle_conn_recycle_interval = 8 which is the minimum value, it means that after 8 seconds all the idled connections will be released by Spider Node.   
b. The Client resend the query to TSpider Node, and the problematic connection will be released immediately and reconnect to TenDB Node again.   
c. Restart TSpider Node, so all the connection will be Re-established.
	  
### 1.2 ERROR 12723
> ERROR 12723 (HY000): Too many connections between TSpider Node and TenDB Node
	
TSpider Node use connection pool to interactive with all the TenDB Node, each TSpider Node will establish spider_max_connections connections with each TenDB Node, when 
a large number of new connections flooded in an instant to TSpider Node, it may encounter no enough connnection to use and so Client will receive Error Code 12723. That is two ways to solve this problem:  

a. set a bigger `spider_max_connections`.

b. optimizate the SQL, when the SQL execute more quickly, it will occupy the connection less time.

### 1.3 ERROR 1477

> ERROR 1477 (HY000): The foreign server name you are trying to reference does not exist. Data source error: SPT0
	
We store the TenDB Instances info and partition info in mysql.servers in TSpider Node , when you receive this Error Code, It seems that the configuration table mysql.servers not exists or you have the table but when you create the TenDB Cluster but you forget to execute FLUSH PRIVILEGES to make the router table available.

### 1.4 ERROR 1429

> MySQL error code 1429 (ER_CONNECT_TO_FOREIGN_DATA_SOURCE): Unable to connect to foreign data source: %.64s
	
When you receive this Error Code, it means that some TenDB master is unavailable, you need to switch to Slave or fix the problem on master quickly.

## 2. Other problem

### 2.1 Out of Sync Error

Unexpected exception occurs when TSpider Node query to the TenDB Node, execute "set global spider_idle_conn_recycle_interval=8"(free idle conn quickly)  and "FLUSH TABLES" on TSpider Node may resolve it

### 2.2 Auto-Increment

TenDB Cluster will ensure the Auto-Increment Column to be unique in the cluster scope, but TenDB Cluster cannot ensure the Auto-Inc column increase 1 by 1, It also will miss some value and the smaller value will be generated later.

for example, follow the timeline, the generated auto-inc ID will be like this: 

      2 6 10 3 7 11 1 5 9 etc.
      
You should know this detail and make sure your program should not relie the Auto-Inc feature.     
For details see [chapter Autoincrement](../re-book/auto-increase-en.md)


### 2.3 Analyse the SlOW QUERY
There is some steps to solve the TenDB Cluster SLOW QUERY:

1. Set global general_log = on and set global spider_general_log = on, and use pt-query-digest to analyse the SQL.
2. Set global spider_bgs_mode=1, which TSpider Node will make read operation executed in parallel on all the TenDB Nodes.
3. When update/delete/insert SQL involve seraval TenDB Nodes, you can `set global spider_bgs_mode=1` and `set global spider_bgs_dml = 1`, which TSpider Node will make  update/delete/insert SQL executed in parallel on all the involved TenDB Nodes
4. Check the network latancy between TSpider Node and TenDB Node, you can ping from TSpider Node and TenDB Node to check the ttl time between the two Nodes.

### 2.4 OOM Problem

#### TSpider Node OOM
This will happen when Client fetch large data from TSpider Node, also you can Set spider_quick_mode=3 to avoid this problem, bug we suggest you don't use TSpider in this way.

#### TenDB Node OOM
This will happen when you config the larger innodb_buffer_pool_size on TenDB Node, and a large number of new connections flooded in an instant, you can lower down the buffer pool size and use connection pool between client and TSpider Node.

### 2.5 Network Flow_In and Flow_Out In TSpider Node is much different
Commonly, network Flow In on TSpider Node will be larger than Flow Out, because TSpider Node need to fetch more data from TenDB Node and calculate the result and return to Client. for example, TSpider Node may execute `SELECT max(COLUMN) from TBALE`.

### 2.6 TenDB Nodes may have different work load
It may happen that you use the unsuitable Shard Key, so it result that different TenDB Node will have different data and request.

### 2.7 Query TimeOut
When you execute complicated QUERY, it will result in query TimeOut, you can set global spider_net_read_timeout/spider_net_write_timeout to avoid this TimeOut problem.

### 2.8 Statistics Information
Set global spider_get_sts_or_crd = on on TSpider Node to collect table statistics information from TenDB Nodes, and TSpider Node will store these information into mysql.spider_table_status table. Because this operation will produce some work load and you can use spider_modify_status_interval variable to control the interval time.

---

## File: Documentation/com-problem/shard-key-choose.md

# Shard Key选取
TSpider会按照表分区键来进行数据分片,分区键的选择尤为重要。本文将提供分区键选取的规则，以及建议。

## Shard Key选取规则
选取规则如下：
*   如果只有一个唯一键（含主键),不指定shard_key, 默认会用唯一键的第一个字段作为分区key；
* 如果多个唯一健（含主键),shard_key只能是其中的共同部分；否则无法建表；   
* 如果只有一个普通索引,不指定shard_key, 默认会用索引的第一个字段作为分区key；  
* 如果包含多个普通索引，则必须指定shard_key
* 如果指定shard_key，shard_key必须是索引的一部分；

其中普通索引和shard_key关系的约束，是通过中控节点Tdbctl建表时的限制。 在不依赖中控节点，直接在TSpider上建表时则不会被约束。 但通常更建议开发者基于索引来访问存储实例。
  
选取规则更详细内容可以参考[TenDB Cluster DDL](../re-book/ddl-syntax.md)


## 选取建议
*   分片的字段，最好是作为经常查询的条件，这样可以提高查询效率；  
*   使用key作为shard_key，数据分布应该均匀，避免数据集中在一个分片上;  


## Note
1. 可通过打开general log来分析应用的各个Table的请求模式，来进行Shard Key的调整，尽量减小跨分片扫描。
2. 另外也可以设置log_sql_use_mutil_partition为true将跨分区扫描的SQL打印到慢查询日志中进行分析。
3. 可以通过查看QUERY_RESPONSE_TIME table来展示TSpider上查询和跨分片扫描的信息。
    ```
     mysql> show QUERY_RESPONSE_TIME;
     mysql> SELECT * FROM information_schema.QUERY_RESPONSE_TIME;
    ```

---

## File: Documentation/com-problem/shard-key-choose-en.md

## Choose The Right Shard Key For TABLE
TSpider Node use the Shard Key to distributed the data to every TenDB Node, It's very important to choose the right Shard Key, you can follow some rules and suggestions here.

## The Rules of Choosing Shard Key
+ If the TABLE just has one unique key, and you don't specify the Shard Key, TSpider Node will use the first column of in unique key as Shard Key.
+ If the TABLE has several unique keys, the specified Shard Key should be the common column of these unique keys, otherwise you can not create table.
+ If the TABLE has multiple unique keys, without specify Shard Key, the first column of the unique key will be used as the Shard Key by default. But it is necessary to ensure that the Shard Key is the first column of each unique key, otherwise the table can not be created.
+ If the TABLE just has one key/index, and you don't specify the Shard Key, TSpider Node will use the first column of the key/index as Shard Key.
+ If the TABLE has several keys/indexes, you must specify one Shard Key.
+ If you specify the Shard Key, it should be part of key/Index of the TABLE.

Among them, the constraints of the relationship between the ordinary index and the shard_key are the limitations when creating tables through the  node Tdbctl. Without relying on the central control node, it will not be constrained when building tables directly on TSpider.  However, it is generally recommended that developers access storage instances based on indexes.

More Rules of choosing Shard Key can founded at [TenDB Cluster DDL](../re-book/ddl-syntax-en.md) 

## The Suggestions of Choosing Shard Key
+  The Shard Key column is best used as conditions for frequent queries, which can improve query efficiency.
+  Use the Column as the Shard Key, the data distribution should be average, to avoid the data concentrated on one or partial Shards.

## Note
1. You can open the general log to analyze the request mode of each TABLE to adjust the Shard Key to minimize Cross-Shard scanning.
2. In addition, you can also set log_sql_use_mutil_partition to true to print the SQL which scans across multiple Shards to the slow query log for analysis.
3. You can find Cross-Shard scanning information on TSpider Node by viewing the QUERY_RESPONSE_TIME table.

	```
	mysql>show QUERY_RESPONSE_TIME; 
	mysql>SELECT * FROM information_schema.QUERY_RESPONSE_TIME;
	```

---

## File: Documentation/contribution/concat.md

# 联系我们

您可以通过仓库提交历史，找到我们的社区成员：   
TSpider:  https://github.com/Tencent/TenDBCluster-TSpider/issues   
TenDB:    https://github.com/Tencent/TenDBCluster-TenDB/issues   
Tdbctl:   https://github.com/Tencent/TenDBCluster-Tdbctl/issues

---

## File: Documentation/contribution/concat-en.md

# Contact Us


You can find our community members through commit history logs of github repository:
   
TSpider:  https://github.com/Tencent/TenDBCluster-TSpider   
TenDB:    https://github.com/Tencent/TenDBCluster-TenDB  
Tdbctl:   https://github.com/Tencent/TenDBCluster-Tdbctl

---

## File: Documentation/contribution/contribute.md

## 源码贡献

欢迎成为TenDB Cluster的贡献者， 一旦您提交给 TSpider/TenDB/Tdbctl项目的PR (pull request) 被合并，你就成为TenDB Cluster的贡献者。
TenDB Cluster的三个核心组件的githu地址分别如下：   
TSpider: https://github.com/TencentDBA/TendbCluster3   
TenDB: https://github.com/TencentDBA/TenDB3   
Tdbctl: https://github.com/TencentDBA/Tdbctl


<a id="jump2"></a>

## 问题反馈

对TenDB Cluster的任何问题或者意见，欢迎通过提issue的方式反馈：   
TSpider:  https://github.com/TencentDBA/TendbCluster3/issues   
TenDB:    https://github.com/TencentDBA/TenDB3/issues   
Tdbctl:   https://github.com/TencentDBA/Tdbctl/issues