This topic explains how to use the CREATE TABLE syntax in AnalyticDB for MySQL to create partitioned and replicated tables and define their distribution keys, partition keys, indexes, lifecycle, and tiered storage.
Before creating a table, use this diagram to understand key concepts such as shards, partitions, and clustered indexes.
Syntax
CREATE TABLE [IF NOT EXISTS] table_name
({column_name column_type [column_attributes] [ column_constraints ] [COMMENT 'column_comment']
| table_constraints}
[, ... ])
[table_attribute]
[partition_options]
[index_all]
[storage_policy]
[block_size]
[engine]
[table_properties]
[AS query_expr]
[COMMENT 'table_comment']
column_attributes:
[DEFAULT {constant | CURRENT_TIMESTAMP}]
[AUTO_INCREMENT]
column_constraints:
[{NOT NULL|NULL} ]
[PRIMARY KEY]
table_constraints:
[{INDEX|KEY} [index_name] (column_name|column_name->'$.json_path'|column_name->'$[*]')][,...]
[FULLTEXT [INDEX|KEY] [index_name] (column_name) [index_option]] [,...]
[PRIMARY KEY [index_name] (column_name,...)]
[CLUSTERED KEY [index_name] (column_name[ASC|DESC],...) ]
[[CONSTRAINT [symbol]] FOREIGN KEY (fk_column_name) REFERENCES pk_table_name (pk_column_name)][,...]
[ANN INDEX [index_name] (column_name,...) [index_option]] [,...]
table_attribute:
DISTRIBUTED BY HASH(column_name,...) | DISTRIBUTED BY BROADCAST
partition_options:
PARTITION BY
{VALUE(column_name) | VALUE(DATE_FORMAT(column_name, 'format')) | VALUE(FROM_UNIXTIME(column_name, 'format'))}
LIFECYCLE N
index_all:
INDEX_ALL= 'Y|N'
storage_policy:
STORAGE_POLICY= {'HOT'|'COLD'|'MIXED' {hot_partition_count=N}}
block_size:
BLOCK_SIZE= VALUE
engine:
ENGINE= 'XUANWU|XUANWU_V2'Internal tables in AnalyticDB for MySQL use the zstd compression algorithm by default.
Parameters
Parameters
Table constraints (indexes)
AnalyticDB for MySQL supports various types of indexes, including regular indexes (INDEX), primary key indexes, clustered indexes, foreign key indexes, full-text indexes, and vector indexes. A table can have one or more indexes.
INDEX | KEY
Defines a regular index. INDEX and KEY are synonyms.
-
For a XUANWU_V2 table, indexes are not created on all columns by default. If the table has a primary key, a regular index is created by default only on that key.
-
For a XUANWU table, the system creates indexes on all columns by default. However, if you manually create an index on specific columns (for example,
INDEX (id)) when you create a XUANWU table, AnalyticDB for MySQL will not automatically create indexes on the other columns in the table.
Note: Composite indexes are not supported. For example, the syntax INDEX (column1,column2) is not supported.
PRIMARY KEY
Defines a primary key index.
Basic usage
-
Each table can have only one primary key.
-
A primary key can consist of a single column, such as
PRIMARY KEY (id), or multiple columns, such asPRIMARY KEY (id,name). -
The primary key must include the distribution key and partition key. Place the distribution key and partition key at the beginning of the primary key definition.
Notes
-
You cannot perform DELETE and UPDATE operations on a table that does not have a primary key.
-
If you do not define a primary key, the following behaviors apply:
-
If you do not define a primary key and a distribution key, AnalyticDB for MySQL automatically adds a column named
__adb_auto_id__and uses it as both the primary key and the distribution key. -
If you define a distribution key but not a primary key, AnalyticDB for MySQL does not automatically add a primary key.
-
-
After a table is created, you cannot add, remove, or modify the primary key columns.
Tuning recommendations: For better performance, use numeric columns for the primary key and minimize the number of columns in the key.
Including too many columns in a primary key can cause the following issues:
-
Increased CPU and I/O resource consumption because AnalyticDB for MySQL checks for duplicate primary key values during data writes.
-
Increased disk space usage by the primary key index. You can use the Storage Analysis feature to view the disk space used by the primary key index.
-
Slower BUILD jobs.
CLUSTERED KEY
Defines a clustered index. A clustered index is configured at the partition level and determines the physical storage order of data. Within each partition, data is sorted by the clustered index key values and stored sequentially, in ascending order by default. The system stores data with the same or similar key values in the same or adjacent data blocks. For range queries or equivalence filtering, if the query condition matches the clustered index column, the storage engine can quickly read contiguous data blocks. This reduces disk I/O and improves data read speed.
Scenarios
A clustered index is suitable for both range queries and equivalence filtering. Consider creating a clustered index on columns that are frequently used in range query or equivalence filtering conditions.
When query conditions fully or partially match the clustered index columns, data read efficiency improves. For example, in SaaS applications where users typically access only their own data, you can use the user ID as a clustered index key. This ensures that data for the same user is stored contiguously in the same or adjacent data blocks, which results in faster data reads.
Basic usage
-
Each table can have only one clustered index.
-
You can create a clustered index on a single column, such as
CLUSTERED KEY index(id), or on multiple columns, such asCLUSTERED KEY index(id,name). When a clustered index consists of multiple columns, the system first sorts the data by the values in the first column. For rows with the same value in the first column, the data is then sorted by the values in the second column. Therefore,CLUSTERED KEY index(id,name)is different fromCLUSTERED KEY index(name,id). -
By default, a clustered index sorts data in ascending order and is suitable for ascending queries. If your queries require descending order, set the clustered index to descending order when you create the table, for example,
CLUSTERED KEY index(id) DESC. If the table already exists, you can delete the existing clustered index and then create a new one in descending order. -
Do not use columns with long values, such as strings of tens of kilobytes, as clustered index keys as this can degrade sorting performance.
FULLTEXT INDEX | FULLTEXT KEY
Defines a full-text index.
FOREIGN KEY
Use foreign key indexes to eliminate unnecessary joins.
ANN INDEX
Defines a vector index.
Note: You cannot create vector indexes on XUANWU_V2 tables.
JSON INDEX
Defines a JSON index or a JSON array index.
Table attribute (distribution key)
The table_attribute determines whether a table is a standard table or a replicated table.
-
DISTRIBUTED BY HASH: Specifies that the table is a standard table. Standard tables leverage a distributed system to improve query efficiency. They can store large amounts of data, typically from tens of millions to hundreds of billions of rows. -
DISTRIBUTED BY BROADCAST: Specifies that the table is a replicated table. A replicated table stores a full copy of its data on each shard in the cluster. We recommend that each replicated table contain no more than 20,000 rows.
DISTRIBUTED BY HASH (column_name,...)
Specifies the distribution key of a table. A standard table with a distribution key is known as a partitioned table. AnalyticDB for MySQL applies a hash function to the distribution key values and distributes rows across different shards based on the resulting hash values. This approach improves scalability and query performance.
Basic usage
-
Each table can have only one distribution key.
-
A distribution key can consist of one or more columns.
-
The columns in the distribution key must be included in the primary key. For example, if the distribution key is customerid, the primary key must also include customerid.
Usage notes
-
If you do not specify a distribution key when you create a table, the system handles it as follows based on whether the table has a primary key:
-
If the table has a primary key, AnalyticDB for MySQL uses the primary key as the distribution key by default.
-
If the table does not have a primary key, AnalyticDB for MySQL automatically adds a column named
__adb_auto_id__and uses it as both the primary key and the distribution key.
-
-
After a table is created, you cannot add, remove, or change the distribution key columns. To modify the distribution key, create a new table and migrate the data.
Recommendations
-
Use as few columns as possible for the distribution key to make it more versatile for various complex queries.
-
Choose columns that are frequently used in query conditions and have high cardinality (evenly distributed values) as the distribution key. Good examples include transaction IDs, device IDs, user IDs, or auto-increment columns. However, avoid columns that are always filtered with a constant value. For example, if a column
ais frequently queried but the condition is alwaysa=3, using it as the distribution key will cause data skew, making it an unsuitable choice. -
Use columns that are used for joins as the distribution key. When two tables are joined, if they share the same distribution key (the join column), data with the same key values is co-located on the same shard. This allows join operations to be performed locally without moving data between shards, reducing data redistribution and improving query performance. For example, if you need to view order history by customer, you can choose
customer_idas the distribution key. -
Avoid using date, time, or timestamp columns as the distribution key. These columns can cause data skew during writes and reduce write performance. Moreover, queries are often filtered by a specific date or time range. If a time-based column is the distribution key, all data for a query might reside on a single node, preventing the query from being processed in parallel across the cluster. We recommend that you use date and time columns as the partition key instead.
-
You can use the storage diagnostics feature to check if the distribution key is effective and to identify data skew.
DISTRIBUTED BY BROADCAST
Specifies a replicated table. A replicated table stores a full copy of its data on each shard of the cluster. We recommend that you do not store a large amount of data in a replicated table.
Advantages: During join operations, the data from a replicated table does not need to be moved across shards. In high-concurrency scenarios, this can significantly reduce network overhead and improve cluster stability.
Disadvantages: When data in a replicated table is changed (due to INSERT, UPDATE, or DELETE operations), the changes are broadcast to all shards to ensure data consistency across all copies. This impacts overall write performance, so we recommend avoiding frequent modifications to replicated tables.
Partition key and lifecycle
If a shard contains a large amount of data after setting a distribution key, you can define a partition key to divide the data on the shard into partitions. This accelerates data filtering and improves query performance.
PARTITION BY
Specifies the partition key.
Syntax: PARTITION BY VALUE {(column_name)|(DATE_FORMAT(column_name, 'format'))|(FROM_UNIXTIME(column_name, 'format'))} LIFECYCLE n
Parameters:
-
column_name: The partition key.
PARTITION BY VALUE(column_name)indicates that the values in thecolumn_namecolumn are used to partition the data. The data type of the partition key can be a numeric type, datetime type, or a string that represents a number. -
DATE_FORMAT(column_name, 'format')|FROM_UNIXTIME(column_name, 'format'): Uses theDATE_FORMATorFROM_UNIXTIMEfunction to convert a datetime column to a specified date format for partitioning. Theformatparameter supports only year, month, and day formats, such as %Y, %y, %Y%m, %y%m, %Y%m%d, and %y%m%d. After table creation, you can modify the format using an ALTER TABLE statement.-
Use the
DATE_FORMATfunction when thecolumnis of the BIGINT, TIMESTAMP, DATETIME, or VARCHAR data type. For a BIGINT column, the value must be a millisecond-level UNIX timestamp, such as 1734278400000. For TIMESTAMP, DATETIME, and VARCHAR columns, the value must be in a format like "2024-11-26 00:01:02". -
Use the
FROM_UNIXTIMEfunction when thecolumnis of the INT data type. The value must be a second-level UNIX timestamp, such as 1696266000.
-
Usage notes
-
For clusters with a kernel version earlier than 3.2.1.0, when you use
PARTITION BYto define partitions, you must also define a lifecycle (LIFECYCLE n). Otherwise, an error occurs. -
For clusters with kernel version 3.2.1.0 or later, when you use
PARTITION BYto define partitions, the lifecycle (LIFECYCLE n) is optional. If you omit this parameter, the system does not clean up partition data. -
After a table is created, you cannot add a partition key, or add, remove, or modify columns in the partition key. To add or modify a partition key, you must create a new table and migrate the data. For more information, see ALTER TABLE.
Recommendations
-
We recommend that you use a datetime type field as the partition key.
-
Partitions that are too large or too small can degrade query and write performance, and even impact cluster stability. For recommendations on the number of rows per partition and how to validate your partitioning strategy, see Diagnose a partition table.
-
Avoid frequently updating data in historical partitions. For example, if you frequently update multiple historical partitions each day, you should re-evaluate whether your partition key is appropriate.
LIFECYCLE n
Use the LIFECYCLE clause with PARTITION BY to manage the partition lifecycle. AnalyticDB for MySQL sorts partitions in descending order based on the partition key value, retains the top n partitions, and deletes any partitions that fall outside this range. You can use LIFECYCLE to define the data retention period.
-
For kernel versions earlier than 3.2.1.1,
LIFECYCLE nspecifies that each shard can retain a maximum ofnpartitions. When managing partition lifecycles at the shard-level, the total number of retained partitions might exceednif data is unevenly distributed or the data volume is extremely small. -
For kernel version 3.2.1.1 and later, for tables that use the
XUANWUengine: New tables created after an upgrade use table-level lifecycle management, whereLIFECYCLE nspecifies that each table retains a maximum ofnpartitions. Tables created before the upgrade continue to use shard-level lifecycle management, whereLIFECYCLE nspecifies that each shard retains a maximum ofnpartitions. -
Tables that use the
XUANWU_V2engine continue to use shard-level lifecycle management, whereLIFECYCLE nspecifies that each shard retains a maximum ofnpartitions. The XUANWU_V2 engine does not yet support table-level lifecycle management.
Example
The clause PARTITION BY VALUE (DATE_FORMAT(date, '%Y%m%d')) LIFECYCLE 30 partitions data by converting the date column to the yyyyMMdd format and retains a maximum of 30 partitions. Assume that data from day 1 is written to partition 20231201, data from day 2 to partition 20231202, and so on, until data from day 30 is written to partition 20231230. When data for day 31 is written to partition 20231231, the oldest partition (20231201) is automatically deleted to maintain a maximum of 30 partitions.
storage_policy
For Enterprise Edition, Basic Edition, and Data Lakehouse Edition clusters and Data Warehouse Edition in elastic mode clusters (new), you can specify a storage policy. Different storage policies offer varying levels of read/write performance and storage costs.
Valid values:
-
hot(default): hot storage. This policy stores all table partitions on SSDs. This policy provides the best performance at the highest storage cost. -
cold: cold storage. This policy stores all table partitions in Object Storage Service (OSS). Compared to hot storage, this policy offers lower performance at the lowest storage cost. -
mixed: tiered storage. This policy balances storage costs with query performance by storing frequently accessed data (hot data) on SSDs and infrequently accessed data (cold data) in OSS. To use themixedpolicy, you must define partitions with thePARTITION BYclause and specify the number of hot partitions with thehot_partition_countparameter. If no partitions are defined, themixedpolicy has no effect, and the system stores all data on SSDs.
Examples
Automatic partitioning by date
Create a partitioned table named sales that is automatically partitioned by the date in the sale_time column.
CREATE TABLE sales (
sale_id BIGINT NOT NULL COMMENT 'Order ID',
customer_id VARCHAR NOT NULL COMMENT 'Customer ID',
phone_num BIGINT NOT NULL COMMENT 'Customer phone number',
revenue DECIMAL(15, 2) COMMENT 'Order amount',
sale_time TIMESTAMP NOT NULL COMMENT 'Order time',
PRIMARY KEY (sale_time,sale_id)
)
DISTRIBUTED BY HASH(sale_id)
PARTITION BY VALUE(DATE_FORMAT(sale_time, '%Y%m%d')); Partitioned table with a lifecycle
Create a partitioned table named customer. The columns login_time, customer_id, and phone_num form a composite primary key. The distribution key is customer_id, the partition key is login_time, and the lifecycle is set to 30.
Partitions are sorted in descending order by the partition key login_time (e.g., 20231202, 20231201). The system retains only the 30 partitions with the largest key values. When data is written to a 31st partition, the system automatically deletes the partition with the smallest key value.
For example, assume data is written with a login_time of 20231201 on day 1, 20231202 on day 2, and so on. When data with a login_time of 20231231 is written on day 31, the system automatically deletes the partition with the oldest data ('20231201'). This retains only data from the most recent 30 days.
CREATE TABLE customer (
customer_id BIGINT NOT NULL COMMENT 'Customer ID',
customer_name VARCHAR NOT NULL COMMENT 'Customer name',
phone_num BIGINT NOT NULL COMMENT 'Phone number',
city_name VARCHAR NOT NULL COMMENT 'City',
sex INT NOT NULL COMMENT 'Gender',
id_number VARCHAR NOT NULL COMMENT 'ID number',
home_address VARCHAR NOT NULL COMMENT 'Home address',
office_address VARCHAR NOT NULL COMMENT 'Office address',
age INT NOT NULL COMMENT 'Age',
login_time TIMESTAMP NOT NULL COMMENT 'Login time',
PRIMARY KEY (login_time,customer_id,phone_num)
)
DISTRIBUTED BY HASH(customer_id)
PARTITION BY VALUE(DATE_FORMAT(login_time, '%Y%m%d')) LIFECYCLE 30
COMMENT 'Customer information table'; Non-partitioned table
Default behavior: Primary key as distribution key
If you define a primary key for a table but do not specify a distribution key, AnalyticDB for MySQL uses the primary key as the distribution key by default.
CREATE TABLE orders (
order_id BIGINT NOT NULL COMMENT 'Order ID',
customer_id INT NOT NULL COMMENT 'Customer ID',
order_status VARCHAR(1) NOT NULL COMMENT 'Order status',
total_price DECIMAL(15, 2) NOT NULL COMMENT 'Order amount',
order_date DATE NOT NULL COMMENT 'Order date',
PRIMARY KEY(order_id,order_date)
);Run the SHOW CREATE TABLE statement to verify the result. The output shows that the primary key columns order_id and order_date also serve as the distribution key.
SHOW CREATE TABLE orders;+---------+-----------------------------------------------------------------------------------------------------------------------------------------------+
| Table | Create Table |
+---------+-----------------------------------------------------------------------------------------------------------------------------------------------+
| orders | CREATE TABLE `orders` ( |
| | `order_id` bigint NOT NULL COMMENT 'Order ID', |
| | `customer_id` int NOT NULL COMMENT 'Customer ID', |
| | `order_status` varchar(1) NOT NULL COMMENT 'Order status', |
| | `total_price` decimal(15, 2) NOT NULL COMMENT 'Order amount', |
| | `order_date` date NOT NULL COMMENT 'Order date', |
| | PRIMARY KEY (`order_id`,`order_date`) |
| | ) DISTRIBUTED BY HASH(`order_id`,`order_date`) INDEX_ALL='Y' STORAGE_POLICY='HOT' ENGINE='XUANWU' TABLE_PROPERTIES='{"format":"columnstore"}' |
+---------+-----------------------------------------------------------------------------------------------------------------------------------------------+
1 row in set (0.04 sec)Default behavior: Auto-added primary and distribution keys
If you create a table without specifying a primary key or a distribution key, AnalyticDB for MySQL automatically adds a column named __adb_auto_id__ and uses it as both the primary key and the distribution key.
CREATE TABLE orders_new (
order_id BIGINT NOT NULL COMMENT 'Order ID',
customer_id INT NOT NULL COMMENT 'Customer ID',
order_status VARCHAR(1) NOT NULL COMMENT 'Order status',
total_price DECIMAL(15, 2) NOT NULL COMMENT 'Order amount',
order_date DATE NOT NULL COMMENT 'Order date'
);Run the SHOW CREATE TABLE statement to verify the result. The output shows that AnalyticDB for MySQL added an auto-increment column named __adb_auto_id__ and set it as both the primary key and distribution key.
SHOW CREATE TABLE orders_new;+-------------+-----------------------------------------------------------------------------------------------------------------------------------------------+
| Table | Create Table |
+-------------+-----------------------------------------------------------------------------------------------------------------------------------------------+
| orders_new | CREATE TABLE `orders_new` ( |
| | `__adb_auto_id__` bigint AUTO_INCREMENT, |
| | `order_id` bigint NOT NULL COMMENT 'Order ID', |
| | `customer_id` int NOT NULL COMMENT 'Customer ID', |
| | `order_status` varchar(1) NOT NULL COMMENT 'Order status', |
| | `total_price` decimal(15, 2) NOT NULL COMMENT 'Order amount', |
| | `order_date` date NOT NULL COMMENT 'Order date', |
| | PRIMARY KEY (`__adb_auto_id__`) |
| | ) DISTRIBUTED BY HASH(`__adb_auto_id__`) INDEX_ALL='Y' STORAGE_POLICY='HOT' ENGINE='XUANWU' TABLE_PROPERTIES='{"format":"columnstore"}' |
+-------------+-----------------------------------------------------------------------------------------------------------------------------------------------+
1 row in set (0.04 sec)Specify primary and distribution keys
Create a table named supplier. The column supplier_id is an auto-increment column. The distribution key is supplier_id, and data is sharded by hashing the supplier_id values.
CREATE TABLE supplier (
supplier_id BIGINT AUTO_INCREMENT PRIMARY KEY,
supplier_name VARCHAR,
address INT,
phone VARCHAR
)
DISTRIBUTED BY HASH(supplier_id);Tiered storage policies
Cold storage policy
CREATE TABLE item (
order_id BIGINT NOT NULL,
item_id INT NOT NULL,
quantity DECIMAL(15, 2) NOT NULL,
discount DECIMAL(15, 2) NOT NULL,
shipdate DATE NOT NULL,
PRIMARY KEY (order_id,item_id,shipdate)
)
DISTRIBUTED BY HASH(item_id)
PARTITION BY VALUE(date_format(shipdate, '%Y%m')) LIFECYCLE 200
STORAGE_POLICY='COLD';Hot storage policy
CREATE TABLE item (
order_id BIGINT NOT NULL,
item_id INT NOT NULL,
quantity DECIMAL(15, 2) NOT NULL,
discount DECIMAL(15, 2) NOT NULL,
shipdate DATE NOT NULL,
PRIMARY KEY (order_id,item_id,shipdate)
)
DISTRIBUTED BY HASH(item_id)
PARTITION BY VALUE(date_format(shipdate, '%Y%m')) LIFECYCLE 200
STORAGE_POLICY='HOT';Mixed policy with 16 hot partitions
CREATE TABLE item (
order_id BIGINT NOT NULL,
item_id INT NOT NULL,
quantity DECIMAL(15, 2) NOT NULL,
discount DECIMAL(15, 2) NOT NULL,
shipdate DATE NOT NULL,
PRIMARY KEY (order_id,item_id,shipdate)
)
DISTRIBUTED BY HASH(item_id)
PARTITION BY VALUE(date_format(shipdate, '%Y%m')) LIFECYCLE 200
STORAGE_POLICY='MIXED' HOT_PARTITION_COUNT=16;Create regular indexes on specific columns
This example creates regular indexes on the id and date columns.
CREATE TABLE index_tb (
id INT,
sales DECIMAL(15, 2),
date DATE,
INDEX (id),
INDEX (date),
PRIMARY KEY (id)
)
DISTRIBUTED BY HASH(id);Define a clustered index
Create a clustered index named clustered_index on the quantity column.
CREATE TABLE clustered (
product_id INT,
product_name VARCHAR,
quantity INT,
price DECIMAL(10, 2),
CLUSTERED KEY INDEX clustered_index(quantity)
)
DISTRIBUTED BY HASH(product_id);Full-text index
Create a full-text index named fidx_c on the content column.
CREATE TABLE fulltext_tb (
id INT,
content VARCHAR,
keyword VARCHAR,
FULLTEXT INDEX fidx_c(content),
PRIMARY KEY (id)
)
DISTRIBUTED BY HASH(id);For more information about creating and modifying a full-text index, see Create a full-text index.
For more information, see Full-text search.
Define a vector index
Define short_feature (type array<smallint>) and float_feature (type array<float>) as vector columns with a dimension of 4.
Create the vector index short_feature_index on the short_feature column and float_feature_index on the float_feature column.
CREATE TABLE fact_tb (
xid BIGINT NOT NULL,
cid BIGINT NOT NULL,
uid VARCHAR NOT NULL,
vid VARCHAR NOT NULL,
wid VARCHAR NOT NULL,
short_feature array<smallint>(4),
float_feature array<float>(4),
ann index short_feature_index(short_feature),
ann index float_feature_index(float_feature),
PRIMARY KEY (xid, cid, vid)
)
DISTRIBUTED BY HASH(xid) PARTITION BY VALUE(cid) LIFECYCLE 4;For details on vector indexing and vector search, see Vector search.
Define a foreign key
Create a table named store_returns. Use the FOREIGN KEY clause to associate the sr_item_sk column with the primary key customer_id of the customer table.
CREATE TABLE store_returns (
sr_sale_id BIGINT NOT NULL PRIMARY KEY,
sr_store_sk BIGINT,
sr_item_sk BIGINT NOT NULL,
FOREIGN KEY (sr_item_sk) REFERENCES customer (customer_id)
);JSON array index
Create a JSON array index named idx_vj on the vj column.
CREATE TABLE json(
id INT,
vj JSON,
INDEX idx_vj(vj->'$[*]')
)
DISTRIBUTED BY HASH(id);For details on creating and modifying JSON array indexes, see Create a JSON array index and JSON array indexes.
FAQ
Column attributes and constraints
Distribution key, partition key, and lifecycle
Data is distributed across shards based on the hash of distribution key values. Within each shard, data is further divided into partitions based on partition key values. The following diagram illustrates this process.
Indexes
Column-oriented storage
Other
Common errors
Related topics
-
To write data to a table, see INSERT INTO.
-
To insert or overwrite data in a table with query results, see INSERT SELECT FROM or INSERT OVERWRITE SELECT.
-
To import data from data sources such as ApsaraDB RDS, MaxCompute, and OSS, see data import.