Configure and manage BUILD jobs - AnalyticDB

BUILD jobs rebuild partitions after data is written, creating indexes and clearing redundant data to improve read performance. During a BUILD job, the system merges the data written in real time with historical partitions, creates indexes, and asynchronously executes any pending DDL statements.

How it works

BUILD jobs operate at two levels:

Table level: Different tables run BUILD jobs in parallel.
Shard level: After a table's BUILD job starts, it splits into tasks across shards. All three replicas of each shard execute tasks independently. The BUILD job completes when all shard tasks finish.

BUILD jobs only process partitions with data changes—partitions with no new INSERT, UPDATE, or DELETE operations are skipped.

Usage notes

During a BUILD job, INSERT OVERWRITE SELECT is blocked. Use INSERT INTO instead.
You cannot cancel a BUILD job after submission.
The number of concurrent BUILD jobs equals ceil(number of cores / 3) and cannot be changed. For a 32-core cluster, this is 11 concurrent jobs.
BUILD jobs consume CPU, memory, and I/O resources. CPU utilization and disk I/O usage may spike while jobs run and return to normal after completion. Run BUILD jobs during off-peak hours.

Trigger BUILD jobs automatically

A BUILD job triggers automatically when either of the following conditions is met:

Condition 1: Enough new data has accumulated

The time since the last BUILD job reaches the minimum interval *and* at least 50,000 rows have been added to a shard.

Edition	Minimum interval
Enterprise Edition	1.5 hours
Basic Edition	1.5 hours
Data Lakehouse Edition	1.5 hours
Data Warehouse Edition (elastic mode)	1.5 hours
Data Warehouse Edition (reserved mode)	0.5 hours

Condition 2: Time-based fallback

24 hours have elapsed since the last BUILD job and at least one row has been modified.

Trigger BUILD jobs manually

Build changed partitions only

The default behavior—rebuild only partitions with data changes.

XUANWU tables
```
BUILD TABLE <table_name>;
```
XUANWU_V2 tables
Note
For information about how to determine and specify a table engine, see the "Specify a table engine" section of the XUANWU_V2 engine topic.
```
BUILD TABLE <table_name> [BUILD_OPTION];
```
BUILD_OPTION accepts only ttl (optional). When specified, expired partitions are deleted immediately after the BUILD job completes. When omitted, only changed partitions are rebuilt.

Build specific partitions

Available for AnalyticDB for MySQL clusters running V3.1.6.0 or later.

BUILD TABLE test force partitions='partition1,partition2';

Use this approach when a table contains large volumes of data and running a full-table BUILD would be resource-intensive. Targeting specific partitions reduces resource usage and speeds up the job.

Important

To view the minor version of your cluster, see How do I view the minor version of a cluster? To update the minor version, contact technical support.

Build an entire table

Important

This operation re-creates indexes for all existing data and can take a long time to complete. Evaluate the impact and risks before proceeding. This feature is disabled by default—submit a ticket to enable it. Use the specific-partition approach above when possible.

BUILD TABLE <table_name> force = true;

This re-creates indexes for all partitions in the table, including those with no data changes.

Schedule BUILD jobs

By default, BUILD jobs run as data accumulates. To restrict them to specific time windows—such as avoiding peak business hours—configure a schedule.

Set a time window

SET ADB_CONFIG RC_CSTORE_BUILD_SCHEDULE_PERIOD=`<start>,<end>`;

Parameter	Description	Valid range
`start`	Start of the scheduling window (hour)	0–24
`end`	End of the scheduling window (hour)	0–24

Separate multiple time windows with semicolons. Enclose all values in backticks.

Important

The time window controls when jobs are *scheduled*, not when they finish. A job scheduled before the window closes may continue running after the window ends.

Example: Schedule BUILD jobs between 00:00–06:59 and 18:00–22:59.

SET ADB_CONFIG RC_CSTORE_BUILD_SCHEDULE_PERIOD=`0,6;18,22`;

Set scheduling priorities

Available for AnalyticDB for MySQL clusters running V3.1.5.0 or later.

By default, BUILD jobs are prioritized by the volume of data added to each shard since the last BUILD job—shards with more newly added data are scheduled first. To override this, set custom priorities using a hint or SET ADB_CONFIG.

The task_priority parameter is an integer (default: 0). A higher value means higher priority. Setting it to a negative number disables automatic scheduling for that table.

Note

To view or update your cluster's minor version, log in to the AnalyticDB for MySQL console and go to the Configuration Information section on the Cluster Information page.

Use a hint (applies to a single table, current job only)

/*build_task_priority = <task_priority> */ BUILD TABLE <db_name>.<table_name>;

Example: Set the priority to 30 for the test table in the adb_demo database.

/*build_task_priority = 30 */ Build TABLE adb_demo.test;

Use SET ADB_CONFIG (persistent, supports multiple tables)

Set priorities for multiple tables across databases:

SET ADB_CONFIG RC_BUILD_TASK_PRIORITY_LIST = `<db1_name>.<table1_name>.<task_priority>;<db2_name>.<table2_name>.<task_priority>`;

Example: Priority 30 for adb_demo1.test1, priority 10 for adb_demo2.test2.

SET ADB_CONFIG RC_BUILD_TASK_PRIORITY_LIST = `adb_demo1.test1.30;adb_demo2.test2.10`;

Set the same priority for all tables in a database:

SET ADB_CONFIG RC_BUILD_TASK_PRIORITY_LIST = `<db1_name>.*.<task_priority>`;

Example: Priority 30 for all tables in adb_demo1.

SET ADB_CONFIG RC_BUILD_TASK_PRIORITY_LIST = `adb_demo1.*.30`;

Set different priorities between one table and the rest in a database:

SET ADB_CONFIG RC_BUILD_TASK_PRIORITY_LIST = `<db1_name>.*.<task_priority>;<db1_name>.<table_name>.<task_priority>`;

Example: Priority 30 for adb_demo1.test1, priority 10 for all other tables in adb_demo1.

SET ADB_CONFIG RC_BUILD_TASK_PRIORITY_LIST = `adb_demo1.*.10;adb_demo1.test1.30`;

When both a hint and SET ADB_CONFIG are configured for the same table, the hint takes precedence for the current job.

To check the current priority configuration, run SHOW ADB_CONFIG.

Monitor BUILD job status

Query BUILD job status for the last three days:

SELECT table_name, schema_name, status
FROM INFORMATION_SCHEMA.KEPLER_META_BUILD_TASK
ORDER BY create_time DESC
LIMIT 10;

Status	Description
`INIT`	The job is being initialized.
`RUNNING`	The job is running.
`FINISH`	The job is complete.

FAQ

Automatic scheduling isn't taking effect

The time parameters in SET ADB_CONFIG RC_CSTORE_BUILD_SCHEDULE_PERIOD must be enclosed in backticks. Without them, the values fail to parse and scheduling is ignored.

Correct syntax:

SET ADB_CONFIG RC_CSTORE_BUILD_SCHEDULE_PERIOD=`0,6`;

This schedules BUILD jobs between 00:00 and 06:59.