- Key Features
- Horizontal Scalability
- MySQL Compatible Syntax
- Replicate from and to MySQL
- Distributed Transactions with Strong Consistency
- Cloud Native Architecture
- Minimize ETL with HTAP
- Fault Tolerance & Recovery with Raft
- Automatic Rebalancing
- Deployment and Orchestration with Ansible, Kubernetes, Docker
- JSON Support
- Spark Integration
- Read Historical Data Without Restoring from Backup
- Fast Import and Restore of Data
- Hybrid of Column and Row Storage
- SQL Plan Management
- Open Source
- Online Schema Changes
- Key Features
- Get Started
- From Binary Tarball
- Orchestrated Deployment
- Geographic Redundancy
- SQL Language Structure
- Data Types
- Numeric Types
- Date and Time Types
- String Types
- Functions and Operators
- Function and Operator Reference
- Type Conversion in Expression Evaluation
- Control Flow Functions
- String Functions
- Numeric Functions and Operators
- Date and Time Functions
- Bit Functions and Operators
- Cast Functions and Operators
- Encryption and Compression Functions
- Information Functions
- JSON Functions
- Aggregate (GROUP BY) Functions
- Window Functions
- Miscellaneous Functions
- Precision Math
- List of Expressions for Pushdown
- SQL Statements
ADMIN CANCEL DDL
ADMIN CHECKSUM TABLE
ADMIN CHECK [TABLE|INDEX]
ADMIN SHOW DDL [JOBS|QUERIES]
CREATE TABLE LIKE
SET DEFAULT ROLE
SET [NAMES|CHARACTER SET]
SET [GLOBAL|SESSION] <variable>
SHOW ANALYZE STATUS
SHOW CHARACTER SET
SHOW [FULL] COLUMNS FROM
SHOW CREATE TABLE
SHOW CREATE USER
SHOW [FULL] FIELDS FROM
SHOW INDEXES [FROM|IN]
SHOW INDEX [FROM|IN]
SHOW KEYS [FROM|IN]
SHOW [FULL] PROCESSSLIST
SHOW [FULL] TABLES
SHOW TABLE REGIONS
SHOW TABLE STATUS
SHOW [GLOBAL|SESSION] VARIABLES
- System Databases
- Garbage Collection (GC)
- Understanding the Query Execution Plan
- The Blocklist of Optimization Rules and Expression Pushdown
- Introduction to Statistics
- TopN and Limit Push Down
- Optimizer Hints
- Follower Read
- Check the TiDB Cluster Status Using SQL Statements
- Execution Plan Binding
- Statement Summary Table
- Tune TiKV
- Operating System Tuning
- Column Pruning
- Key Monitoring Metrics
- Best Practices
- TiDB Binlog
- Binlog Consumer Client
- TiDB Binlog Relay Log
- Bidirectional Replication Between TiDB Clusters
- TiDB Lightning
- All Releases
TiDB allows you to identify expensive queries during SQL execution, so you can diagnose and improve the performance of SQL execution. Specifically, TiDB prints the information about statements whose execution time exceeds
tidb_expensive_query_time_threshold (60 seconds by default) or memory usage exceeds
mem-quota-query (32 GB by default) to the tidb-server log file ("tidb.log" by default).
The expensive query log differs from the slow query log in this way: TiDB prints statement information to the expensive query log as soon as the statement exceeds the threshold of resource usage (execution time or memory usage); while TiDB prints statement information to the slow query log after the statement execution.
[2020/02/05 15:32:25.096 +08:00] [WARN] [expensivequery.go:167] [expensive_query] [cost_time=60.008338935s] [wait_time=0s] [request_count=1] [total_keys=70] [process_keys=65] [num_cop_tasks=1] [process_avg_time=0s] [process_p90_time=0s] [process_max_time=0s] [process_max_addr=10.0.1.9:20160] [wait_avg_time=0.002s] [wait_p90_time=0.002s] [wait_max_time=0.002s] [wait_max_addr=10.0.1.9:20160] [stats=t:pseudo] [conn_id=60026] [user=root] [database=test] [table_ids=""] [txn_start_ts=414420273735139329] [mem_max="1035 Bytes (1.0107421875 KB)"] [sql="insert into t select sleep(1) from t"]
cost_time: The execution time of a statement when the log is printed.
stats: The version of statistics used by the tables or indexes involved in a statement. If the value is
pseudo, it means that there are no available statistics. In this case, you need to analyze the tables or indexes.
table_ids: The IDs of the tables involved in a statement.
txn_start_ts: The start timestamp and the unique ID of a transaction. You can use this value to search for the transaction-related logs.
sql: The sql statement.
Memory usage related fields:
mem_max: Memory usage of a statement when the log is printed. This field has two kinds of units to measure memory usage: byte and other readable and adaptable units (such as MB and GB).
User related fields:
user: The name of the user who executes the statement.
conn_id: The connection ID (session ID). For example, you can use the keyword
con:60026to search for the log whose session ID is
database: The database where the statement is executed.
TiKV Coprocessor task related fields:
wait_time: The total waiting time of all Coprocessor requests of a statement in TiKV. Because the Coprocessor of TiKV runs a limited number of threads, requests might queue up when all threads of Coprocessor are working. When a request in the queue takes a long time to process, the waiting time of the subsequent requests increases.
request_count: The number of Coprocessor requests that a statement sends.
total_keys: The number of keys that Coprocessor has scanned.
processed_keys: The number of keys that Coprocessor has processed. Compared with
processed_keysdoes not include the old versions of MVCC. A great difference between
total_keysindicates that many old versions exist.
num_cop_tasks: The number of Coprocessor requests that a statement sends.
process_avg_time: The average execution time of Coprocessor tasks.
process_p90_time: The P90 execution time of Coprocessor tasks.
process_max_time: The maximum execution time of Coprocessor tasks.
process_max_addr: The address of the Coprocessor task with the longest execution time.
wait_avg_time: The average waiting time of Coprocessor tasks.
wait_p90_time: The P90 waiting time of Coprocessor tasks.
wait_max_time: The maximum waiting time of Coprocessor tasks.
wait_max_addr: The address of the Coprocessor task with the longest waiting time.