AnalyticDB for MySQL allows you to execute the CREATE TABLE statement to create a table or execute the CREATE TABLE AS SELECT (CTAS) statement to write queried data to a new table.

Syntax

CREATE TABLE [IF NOT EXISTS] table_name
  ({column_name column_type [column_attributes] [ column_constraints ] [COMMENT 'string']
  | table_constraints}
   [, ... ]  )
   table_attribute
   [partition_options]
   [storage_policy]
   [block_size]
[AS] query_expression
   COMMENT 'string'

column_attributes:
   [DEFAULT default_expr]
   [AUTO_INCREMENT]

column_constraints:
   [{NOT NULL|NULL} ]
   [PRIMARY KEY]

table_constraints:
   [{INDEX|KEY} [index_name] (column_name,...)]
   [PRIMARY KEY [index_name] (column_name,...)]
   [CLUSTERED KEY [index_name] (column_name,...)]

table_attribute:
   DISTRIBUTED BY HASH(column_name,...) | DISTRIBUTED BY BROADCAST

partition_options:
  PARTITION BY 
        {VALUE(column_name) | VALUE(date_format(column_name, ?))}
  LIFECYCLE N

storage_policy:
  STORAGE_POLICY= 'HOT'|'COLD'|'MIXED' [hot_partition_count=N]

block_size:
  BLOCK_SIZE= VALUE

Parameters

Parameter Description
table_name The name of the table.

The table name must be 1 to 127 characters in length and can contain letters, digits, and underscores (_). The table name must start with a letter or underscore (_).

Specify the table name in the db_name.table_name format to distinguish tables that have the same name across different databases.

column_name The name of the column.

The column name must be 1 to 127 characters in length and can contain letters, digits, and underscores (_). The column name must start with a letter or underscore (_).

column_type The data type of the column to be added.

For more information about the data types supported by AnalyticDB for MySQL, see Basic data types.

column_attributes
  • DEFAULT default_expr: specifies the default value of the column. DEFAULT is an expression without variables. Example: current_timestamp.

    If no value is specified, the default value of the column is NULL.

  • AUTO_INCREMENT: specifies whether the column is an auto-increment column. This parameter is optional.

    The data type of an auto-increment column must be BIGINT because AnalyticDB for MySQL provides unique values for an auto-increment column. However, these values are not incremented in sequence.

column_constraints
  • NOT NULL|NULL: specifies whether the column accepts the NULL value. NOT NULL indicates that the column does not accept the NULL value. NULL indicates that the column accepts the NULL value. Default value: NULL.
  • PRIMARY KEY: specifies the primary key of the column.

    You can specify one or more primary key columns in the PRIMARY KEY(column_name [, ... ]) format.

table_constraints
Note Unique indexes cannot be created in AnalyticDB for MySQL.
  • INDEX|KEY: specifies the inverted index.

    AnalyticDB for MySQL automatically creates an index on all columns of the table. You do not need to manually create an index.

  • PRIMARY KEY: specifies the primary key index.
    • Only tables with primary keys support the DELETE and UPDATE operations.
    • A primary key must include a distribution key and a partition key. We recommend that you put distribution and partition keys in the front section of a composite primary key.
  • CLUSTERED KEY: specifies the clustered index that is used as the aggregate columns to sort data in the table. The logical order of key values in the clustered index determines the physical order of the corresponding rows in the table.

    For example, CLUSTERED KEY col5_col6_cls_index(col5,col6) specifies the col5 col6 clustered index. col5 col6 and col6 col5 are different clustered indexes.

    A clustered index sorts one or more aggregate columns in the table to ensure that the same or proximate data is saved in the same or proximate position of a disk. When you use aggregate columns as query conditions, query results are saved in the same position of a disk. This can reduce the number of I/O operations and improve query performance.

    You can use the field that must be included in a query as a clustered index. For example, in software-as-a-service (SaaS) applications, users can use their user ID as the clustered index to access their own data. This ensures that data access is localized and improves data query performance.

    Aggregate columns have the following limits:
    • You can create only a single clustered index for each table.
    • A clustered index sorts the entire table, which causes low data write performance and high CPU utilization. In this case, we recommend that you do not use clustered indexes.
table_attribute
  • DISTRIBUTED BY HASH(column_name,...): specifies the distribution key in a fact table. The data of the table is distributed based on the hash value of the column specified by column_name.

    AnalyticDB for MySQL allows you to select multiple fields as the distribution key.

    AnalyticDB for MySQL does not allow you to change distribution keys. If you want to use a different distribution key for your table, perform the operations described in the "Change a partition or distribution key" section of the ALTER TABLE topic.

  • DISTRIBUTED BY BROADCAST: specifies a dimension table. The dimension table is stored on each node of a cluster. For performance reasons, we recommend that you do not store large amounts of data in the dimension table.
partition_options PARTITION BY: specifies the partition key in a fact table.

LIFECYCLE N is used to manage the lifecycle of the table. Partitions are sorted and only N partitions are retained. The other partitions are filtered out.

For example, PARTITION BY VALUE(column_name) indicates that the table is partitioned based on the column specified by column_name. PARTITION BY VALUE(DATE_FORMAT(column_name, '%Y%m%d')) indicates that the table is partitioned based on the column specified by column_name after the column is formatted to a date format such as 20190101. LIFECYCLE 365 indicates that a maximum of 365 partitions can be retained on each node. Only data from the last 365 days is stored. When you write data on the 366th day, data from the first day is deleted.

AnalyticDB for MySQL does not allow you to change partition keys. If you want to use a different partition key for your table, perform the operations described in the "Change a partition or distribution key" section of the ALTER TABLE topic.

Note
  • List partitions are based on a shard, instead of on the entire table. If data is unevenly distributed, more than N list partitions may be reserved for the entire table.
  • List partitions are not cleared in real time, but are cleared by asynchronous tasks in the background.
  • When you use PARTITION BY to specify list partitions, you must specify LIFECYCLE N. Otherwise, an error is returned. If you do not specify list partitions, data is not cleared.
storage_policy
Note Only clusters in elastic mode for Cluster Edition support tiered storage of hot and cold data.

STORAGE_POLICY: specifies the storage policy of the table. Valid values: HOT, COLD, and MIXED. Default value: HOT.

Different storage policies bring about different data read and write performance and storage costs. To reduce data storage costs and ensure query performance, you can store data with a high query frequency (called hot data) on SSDs and data with a low query frequency (called cold data) on HDDs.

You can also separately select cold and hot storage media based on table granularity and list partition granularity. For example, you can specify that all data of the table is stored on SSDs, all data is stored on HDDs, or data of part of list partitions in the table is stored on SSDs and data of the rest list partitions is stored on HDDs.

  • HOT, COLD, and MIXED are case-insensitive.
  • HOT: Data of all partitions is stored on SSDs.
  • COLD: Data of all partitions is stored on HDDs.
  • MIXED: Data of part of partitions is stored on SSDs and data of the rest partitions is stored on HDDs. You must use the hot_partition_count parameter to specify the number of partitions whose data is stored on SSDs.
hot_partition_count=N Specifies the number of partitions whose data is stored on SSDs when the MIXED storage policy is used. These partitions are called hot partitions. Partitions are sorted by partition key value in descending order. The first N partitions are hot partitions and the others are cold partitions.
  • N is a non-zero positive integer.
  • When you select the MIXED storage policy, you must also specify the number of hot partitions. The hot_partition_count=N parameter is not allowed for other storage policy types.
block_size Specifies the number of values stored in each block in column-oriented storage. It is the minimum unit for I/O operations.
  • Default value for a cluster in elastic mode for Cluster Edition that has fewer than 32 cores: 8192.
  • Default value for a dimension table: 4096.
  • Default value for other cases: 32760. If the default value of block_size is 32760, block_size is not displayed when you execute the SHOW CREATE TABLE <table_name>; statement.

This parameter determines the size of values read or written in each I/O operation and affects query performance based on query characteristics. For example, if block_size is set to a large value for point queries, blocks are read inefficiently by the storage system. In this case, you can appropriately decrease the value of block_size.

Notice If you are not familiar with column-oriented storage, we recommend that you do not change the value of block_size.

Precautions

  • AnalyticDB for MySQL clusters use the UTF-8 encoding format during table creation. This encoding format is equivalent to the utf8mb4 format in MySQL. AnalyticDB for MySQL does not support other encoding formats.
  • The maximum number of tables that can be created in a cluster varies with the following AnalyticDB for MySQL editions:
    • Cluster Edition: MIN(256 × Number of node groups, 10000)
    • Basic Edition:
      • T8: 500
      • T16 and T32: 1,500
      • T52: 2,500

Examples

  • Create a test table.
    CREATE TABLE test (
           id bigint auto_increment,
           name varchar,
           value int,
           ts timestamp
    )
    DISTRIBUTED BY HASH(id);

    The test table is a fact table. The id column is an auto-increment column. The distribution key is id. Data of the table is distributed based on the hash value of the id column.

  • Create a customer table.
    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 card 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 'Logon 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';                   

    The customer table is a fact table. In the table, the distribution key is customer_id. The partition key is login_time. login_time, customer_id, and phone_num form the composite primary key.

MySQL syntax compatibility

The standard CREATE TABLE syntax of AnalyticDB for MySQL must contain the DISTRIBUTED BY ... clause. The standard CREATE TABLE syntax of MySQL does not contain the DISTRIBUTED BY ... clause. By default, AnalyticDB for MySQL is compatible with the CREATE TABLE syntax of MySQL. You can use one of the following methods to resolve the compatibility issues caused by the DISTRIBUTED BY ... clause:

  • If a MySQL table contains a primary key, AnalyticDB for MySQL uses the primary key as the distribution key in DISTRIBUTED BY COLUMN.
    CREATE TABLE t (c1 bigint, c2 int, c3 varchar, PRIMARY KEY(c1,c2));
    Query OK, 0 rows affected (2.37 sec)
    
    SHOW CREATE TABLE t;
    +-------+-------------------------------------------------------------------------------------------------------------------------------+
    | Table | Create Table                                                                                                                  |
    +-------+-------------------------------------------------------------------------------------------------------------------------------+
    | t     | Create Table `t` (
     `c1` bigint,
     `c2` int,
     `c3` varchar,
     primary key (c1,c2)
    ) DISTRIBUTED BY HASH(`c1`,`c2`) INDEX_ALL='Y' |
    +-------+-------------------------------------------------------------------------------------------------------------------------------+
    1 row in set (0.04 sec)
  • If a MySQL table does not contain a primary key, AnalyticDB for MySQL adds the __adb_auto_id__ column as the primary key and uses it as the distribution key in DISTRIBUTED BY COLUMN.
    CREATE TABLE t (c1 bigint, c2 int, c3 varchar);
    Query OK, 0 rows affected (0.50 sec)
    
    SHOW CREATE TABLE t;
    +-------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
    | Table | Create Table                                                                                                                                                                              |
    +-------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
    | t     | Create Table `t` (
     `c1` bigint,
     `c2` int,
     `c3` varchar,
     `__adb_auto_id__` bigint AUTO_INCREMENT,
     primary key (__adb_auto_id__)
    ) DISTRIBUTED BY HASH(`__adb_auto_id__`) INDEX_ALL='Y' |
    +-------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
    1 row in set (0.04 sec)

Specify the storage policy of cold and hot data when you create a table

Note Only clusters in elastic mode for Cluster Edition support tiered storage of hot and cold data.

You can specify the storage policy when you create a table.

CREATE TABLE [IF NOT EXISTS] table_name
  ({column_name column_type [column_attributes] [ column_constraints ] [COMMENT 'string']
  | table_constraints}
   [, ... ]  )
   table_attribute
   [partition_options]
   [storage_policy]
   [AS] query_expression
   COMMENT 'string'
   
storage_policy:
   STORAGE_POLICY= 'HOT'|'COLD'|'MIXED' [hot_partition_count=N]
Example 1: Specify the COLD storage policy when you create a table
CREATE TABLE test_table (
 L_ORDERKEY bigint NOT NULL,
 L_LINENUMBER int NOT NULL,
 L_SHIPDATE date NOT NULL,
 dummy varchar,
 primary key (l_orderkey,l_linenumber,l_shipdate)
) DISTRIBUTE BY HASH(l_orderkey) 
PARTITION BY VALUE(date_format(l_shipdate, '%Y%m')) LIFECYCLE 200 INDEX_ALL='Y' 
STORAGE_POLICY='COLD';
Example 2: Specify the HOT storage policy when you create a table
CREATE TABLE test_table (
 L_ORDERKEY bigint NOT NULL,
 L_LINENUMBER int NOT NULL,
 L_SHIPDATE date NOT NULL,
 dummy varchar,
 primary key (l_orderkey,l_linenumber,l_shipdate)
) DISTRIBUTE BY HASH(l_orderkey) 
PARTITION BY VALUE(date_format(l_shipdate, '%Y%m')) LIFECYCLE 200 INDEX_ALL='Y' 
STORAGE_POLICY='HOT';
Example 3: Specify the MIXED storage policy and set the number of hot partitions to 16 when you create a table
CREATE TABLE test_table (
 L_ORDERKEY bigint NOT NULL,
 L_LINENUMBER int NOT NULL,
 L_SHIPDATE date NOT NULL,
 dummy varchar,
 primary key (l_orderkey,l_linenumber,l_shipdate)
) DISTRIBUTE BY HASH(l_orderkey) 
PARTITION BY VALUE(date_format(l_shipdate, '%Y%m')) LIFECYCLE 200 INDEX_ALL='Y' 
STORAGE_POLICY='MIXED' HOT_PARTITION_COUNT=16;

Create a table that has a vector index

You can create an index named ann when you create a table. Syntax:
ann index [index_name] (col_name,...)] [algorithm=HNSW_PQ ] [dis_function=SquaredL2]
Example:
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 >(32),  
float_feature array < float >(32),  
ann index short_feature_index(short_feature), 
ann index float_feature_index(float_feature),  
PRIMARY KEY (xid, cid, vid)
) DISTRIBUTE BY HASH(xid) PARTITION BY VALUE(cid) LIFECYCLE 4;
Parameters:
  • short_feature/float_feature: the name of the vector column. You can specify this parameter.
  • array<float>(32): the data type of the vector column and the dimension of the vector. You can specify this parameter. You must specify the dimension of the vector. Valid values: float, byte, and short. Define the type of the feature_data column as 512. Example:
    feature_data` array<float>(512)
  • ann: the system keyword.
  • index: the system keyword.
  • short_feature_index/float_feature_index: the name of the index. You can specify this parameter. The following syntax can be used to create a vector index for the feature_data column:
    ann index ecnn_index(`FEATURE_DATA`) algorithm=HNSW_PQ dis_function=SquaredL2

    You can ignore the algorithm and dis_function parameters. The default value of the algorithm parameter is HNSW_PQ. The default value of the dis_function parameter is SquaredL2.

  • algorithm: the algorithm used by the formula to calculate the vector distance. The following table describes the algorithm supported by AnalyticDB for MySQL to calculate the vector distance.
    Algorithm Scenario Supported data type
    HNSW_PQ This algorithm is suitable for medium-scale scenarios in which the data volume of a single table ranges from millions to tens of millions and is sensitive to the vector dimension. SHORT[], BYTE[], or FLOAT[]
  • dis_function: the function used to calculate the vector distance. Default value: SquaredL2. The following table describes the function supported by AnalyticDB for MySQL to calculate the vector distance.
    Function Formula Supported data type
    SquaredEuclidean (SquaredL2) (x1-y1)^2+(x2-y2)^2+… BYTE[], SHORT[], or FLOAT[]
Use the vector index to retrieve queries
  1. Query the last five records of the vector '[1,1,1,1]'.
    SELECT id, l2_distance(short_feature, '[1,1,1,1]') FROM fact_tb ORDER BY 2 LIMIT 5;
  2. Query the last five records of the vector '[1,1,1,1]' by using the vector index, and sort the records by distance.
    SELECT id, l2_distance(short_feature, '[1,1,1,1]') FROM fact_tb WHERE xid = 1 AND cid = 0 ORDER BY 2 LIMIT 5;
  3. Query the last five records of the vector '[1,1,1,1]' by using the vector index, sort the records by distance, and set the maximum range of distance.
    SELECT id, l2_distance(float_feature, '[1.2,1.5,2,3.0]') FROM fact_tb WHERE l2_distance(float_feature, '[1.2,1.5,2,3.0]') < 50.0 AND xid = 2 ORDER BY 2 LIMIT 5;