Sign InTry Free

Introduction to Extended Statistics

TiDB can collect the following two types of statistics:

  • Basic statistics: statistics such as histograms and Count-Min Sketch. See Introduction to Statistics for details.
  • Extended statistics: statistics filtered by tables and columns.

When the ANALYZE statement is executed manually or automatically, TiDB by default only collects the basic statistics and does not collect the extended statistics. This is because the extended statistics are only used for optimizer estimates in specific scenarios, and collecting them requires additional overhead.

Extended statistics are disabled by default. To collect extended statistics, you need to first enable the extended statistics, and then register each individual extended statistics object.

After the registration, the next time the ANALYZE statement is executed, TiDB collects both the basic statistics and the registered extended statistics.

Limitations

Extended statistics are not collected in the following scenarios:

  • Statistics collection on indexes only
  • Statistics collection using the ANALYZE INCREMENTAL command
  • Statistics collection when the value of the system variable tidb_enable_fast_analyze is set to true

Common operations

Enable extended statistics

To enable extended statistics, set the system variable tidb_enable_extended_stats to ON:

SET GLOBAL tidb_enable_extended_stats = ON;

The default value of this variable is OFF. The setting of this system variable applies to all extended statistics objects.

Register extended statistics

The registration for extended statistics is not a one-time task, and you need repeat the registration for each extended statistics object.

To register extended statistics, use the SQL statement ALTER TABLE ADD STATS_EXTENDED. The syntax is as follows:

ALTER TABLE table_name ADD STATS_EXTENDED IF NOT EXISTS stats_name stats_type(column_name, column_name...);

In the syntax, you can specify the table name, statistics name, statistics type, and column name of the extended statistics to be collected.

  • table_name specifies the name of the table from which the extended statistics are collected.
  • stats_name specifies the name of the statistics object, which must be unique for each table.
  • stats_type specifies the type of the statistics. Currently, only the correlation type is supported.
  • column_name specifies the column group, which might have multiple columns. Currently, you can only specify two column names.
How it works

To improve access performance, each TiDB node maintains a cache in the system table mysql.stats_extended for extended statistics. After you register the extended statistics, the next time the ANALYZE statement is executed, TiDB will collect the extended statistics if the system table mysql.stats_extended has the corresponding objects.

Each row in the mysql.stats_extended table has a version column. Once a row is updated, the value of version is increased. In this way, TiDB loads the table into memory incrementally, instead of fully.

TiDB loads mysql.stats_extended periodically to ensure that the cache is kept the same as the data in the table.

Delete extended statistics

To delete an extended statistics object, use the following statement:

ALTER TABLE table_name DROP STATS_EXTENDED stats_name;
How it works

After you execute the statement, TiDB marks the value of the corresponding object in mysql.stats_extended's column status to 2, instead of deleting the object directly.

Other TiDB nodes will read this change and delete the object in their memory cache. The background garbage collection will delete the object eventually.

Export and import extended statistics

The way of exporting or importing extended statistics is the same as exporting or importing basic statistics. See Introduction to Statistics - Import and export statistics for details.

Usage examples for correlation-type extended statistics

Currently, TiDB only supports the correlation-type extended statistics. This type is used to estimate the number of rows in the range query and improve index selection. The following example shows how the correlation-type extended statistics are used to estimate the number of rows in a range query.

Step 1. Define the table

Define a table t as follows:

CREATE TABLE t(col1 INT, col2 INT, KEY(col1), KEY(col2));

Suppose that col1 and col2 of table t both obey monotonically increasing constraints in row order. This means that the values of col1 and col2 are strictly correlated in order, and the correlation factor is 1.

Step 2. Execute an example query without extended statistics

Execute the following query without using extended statistics:

SELECT * FROM t WHERE col1 > 1 ORDER BY col2 LIMIT 1;

For the execution of the preceding query, the TiDB optimizer has the following options to access table t:

  • Uses the index on col1 to access table t and then sorts the result by col2 to calculate Top-1.
  • Uses the index on col2 to meet the first row that satisfies col1 > 1. The cost of this access method mainly depends on how many rows are filtered out when TiDB scans the table in col2's order.

Without extended statistics, the TiDB optimizer only supposes that col1 and col2 are independent, which leads to a significant estimation error.

Step 3. Enable extended statistics

Set tidb_enable_extended_stats to ON, and register the extended statistics object for col1 and col2:

ALTER TABLE t ADD STATS_EXTENDED s1 correlation(col1, col2);

When you execute ANALYZE after the registration, TiDB calculates the Pearson correlation coefficient of col and col2 of table t, and writes the object into the mysql.stats_extended table.

Step 4. See how extended statistics make a difference

After TiDB has the extended statistics for correlation, the optimizer can estimate how many rows to be scanned more precisely.

At this time, for the query in Stage 2. Execute an example query without extended statistics, col1 and col2 are strictly correlated in order. If TiDB accesses table t by using the index on col2 to meet the first row that satisfies col1 > 1, the TiDB optimizer will equivalently translate the row count estimation into the following query:

SELECT * FROM t WHERE col1 <= 1 OR col1 IS NULL;

The preceding query result plus one will be the final estimation for the row count. In this way, you do not need to use the independent assumption and the significant estimation error is avoided.

If the correlation factor (1 in this example) is less than the value of the system variable tidb_opt_correlation_threshold, the optimizer will use the independent assumption, but it will also increase the estimation heuristically. The larger the value of tidb_opt_correlation_exp_factor, the larger the estimation result. The larger the absolute value of the correlation factor, the larger the estimation result.

Was this page helpful?

Download PDFRequest docs changesAsk questions on Discord
Playground
New
One-stop & interactive experience of TiDB's capabilities WITHOUT registration.
Products
TiDB
TiDB Dedicated
TiDB Serverless
Pricing
Get Demo
Get Started
© 2024 PingCAP. All Rights Reserved.
Privacy Policy.