All Products
Search
Document Center

Lindorm:CREATE TABLE

Last Updated:Sep 25, 2025

The CREATE TABLE statement creates a table in LindormTable or LindormTSDB. It supports multiple data types, such as VARCHAR, TIMESTAMP, and BIGINT. It also supports multiple table attributes, such as data Time to Live (TTL) and the COMPRESSION algorithm. You can combine attributes and data types to design tables that best suit your business scenarios.

Engines and versions

Syntax

create_table_statement ::=  CREATE TABLE [ IF NOT EXISTS ] table_identifier
                            '('
                                column_definition
                                ( ',' column_definition )*
                                 ',' PRIMARY KEY '(' primary_key ')' 
                                ( ',' {KEY|INDEX} [index_identifier] 
                                     [ USING index_method_definition ] 
                                     [ INCLUDE column_identifier ( ',' column_identifier )* ]
                                     [ WITH  index_options ]
                                )*    
                            ')' 
                            [ PARTITION BY partition_definition ]
                            [ WITH  table_options ]
column_definition      ::=  column_identifier data_type [ NOT NULL ]
primary_key            ::=  column_identifier [ ',' column_identifier (ASC|DESC)]                         
index_method_definition  ::= { KV | SEARCH }  
index_options            ::=  '(' 
                                  option_definition (',' option_definition )* 
                              ')'
partition_definition   ::=  HASH '(' column_identifier (',' column_identifier )* ')'
table_options          ::=  '(' option_definition (',' option_definition )*  ')'
option_definition      ::=  option_identifer '=' string_literal 

Differences

The CREATE TABLE syntax differs significantly between LindormTable and LindormTSDB. The following table compares the differences.

Syntax element

LindormTable

LindormTSDB

Table name (table_identifier)

Column definition (column_definition)

Primary key (primary_key)

Index expression (KEY|INDEX)

✖️

Partition (partition_definition)

✖️

Table attributes (table_options)

✖️

Usage notes

Table name (table_identifier)

Note the following requirements for table names:

  • Can contain digits, uppercase letters, lowercase letters, periods (.), hyphens (-), and underscores (_).

  • Cannot start with a period (.) or a hyphen (-).

  • Must be 1 to 255 characters in length.

Column definition (column_definition)

Syntax element

Required

Description

Column name (column_identifier)

Yes

  • Can contain digits, uppercase letters, lowercase letters, periods (.), hyphens (-), and underscores (_).

  • Reserved keywords cannot be used as column names.

  • The length cannot exceed 255 bytes.

Data type (data_type)

Yes

For information about supported data types, see Data types.

Important

When you create a time series table, note the following points if you use the TIMESTAMP data type:

  • You can specify only one column as the TIMESTAMP type.

  • LindormTSDB encodes and parses timestamps based on UTC+8.

  • In some legacy systems, Unix timestamps are still processed as 32-bit values. We recommend that you multiply these timestamps by 1000 before you write them to LindormTSDB. If you write these timestamps directly to LindormTSDB without conversion, a semantic interpretation bias occurs. For example, the timestamp 1641009600 is interpreted as 2022-01-01 12:00:00 in legacy systems, but is interpreted as 1970-01-20 07:50:09 (UTC+8) in LindormTSDB.

NULL constraint

No

Specifies whether the column value can be NULL.

Important

Lindorm SQL does not check for NULL constraints. This check is performed by the storage engine.

The method for checking NULL constraints depends on the validation rules of the storage engine. The rules vary for different storage engines. Therefore, you may be able to write NULL values even if you specify NOT NULL.

To ensure that data is written correctly, follow these requirements:

  • Primary key columns cannot be null. You must specify NOT NULL for primary key columns when you create a table.

  • For non-primary key columns, we recommend that you do not specify NOT NULL in the column definition.

Primary key (primary_key)

The primary key is the unique identifier for data in a table. It consists of one or more columns. You must specify a primary key (PRIMARY KEY) when you create a table.

Important

The primary key cannot be modified after it is created. Design your primary key carefully.

When you use the CREATE TABLE statement to create a table, note the following:

Engine type

Primary key usage notes

LindormTable

  • The maximum length of a single primary key column is 2 KB.

  • The total length of all primary key columns cannot exceed 30 KB.

  • The maximum length of a single non-primary key column cannot exceed 2 MB.

LindormTSDB

  • In the primary key of a time series table, columns of the VARCHAR data type are called tag columns, and the column of the TIMESTAMP data type is called the timestamp column.

  • The data type of primary key columns must be VARCHAR or TIMESTAMP.

  • The primary key can contain one or more columns of the VARCHAR type, but only one column of the TIMESTAMP type.

  • In a time series table, we recommend that you use the unique identifier of the data source as the PRIMARY KEY. Examples include device IDs in Internet of Things (IoT) scenarios, vehicle unique identifiers in Internet of Vehicles (IoV) scenarios, and application IDs or ip:port in monitoring scenarios. For more information, see Best practices for designing a PRIMARY KEY.

Index expression (KEY|INDEX)

When you use the CREATE TABLE statement to create an index table, you can use the KEY or INDEX keyword to specify the index to create.

Important
  • The index expression (KEY|INDEX) is supported only by LindormTable 2.7.7 and later and Lindorm SQL 2.8.6.0 and later.

  • For information about the versions of LindormTable and Lindorm SQL, see LindormTable version history and SQL version history. If you cannot upgrade to the required versions in the console, you can contact Lindorm technical support on DingTalk at s0s3eg3.

Usage notes

  • If you do not explicitly specify an index name, the system generates one by default. The format of the generated index name is TableName_idx_${Auto-incremented_Number}.

  • Currently, you can only create secondary indexes and search indexes using index expressions.

  • Redundancy of secondary indexes:

    Lindorm SQL 2.9.3.10 and later

    If you create a secondary index without specifying INCLUDE, all columns are not included by default.

    Lindorm SQL versions earlier than 2.9.3.10

    If you create a secondary index without specifying INCLUDE, all columns are included by default.

    Note

    This is equivalent to setting the INDEX_COVERED_TYPE index attribute to COVERED_ALL_COLUMNS_IN_SCHEMA. If the table is a dynamic table, this is equivalent to COVERED_DYNAMIC_COLUMNS.

  • If you specify the KEY or INDEX clause when you create a table but do not explicitly specify the MUTABILITY and CONSISTENCY attributes, the table has two default attributes: CONSISTENCY = 'strong' and MUTABILITY='MUTABLE_LATEST'.

  • If the CREATE TABLE statement includes an index expression, the system first creates the table and then creates the index. If an exception occurs during index creation, the created table and index might remain. They are not automatically cleared or deleted. You can view them using statements such as SHOW and DESCRIBE. However, you might not be able to write data or run queries. We recommend that you clear the remaining table and index and then create them again.

Partition (partition_definition)

Partitioning is supported only by LindormTSDB. In a time series table, the column used for PARTITION BY must be a VARCHAR column in the primary key definition.

When you create a table, you can use the PARTITION BY HASH(column1, column2, ..., columnN) statement to explicitly specify one or more columns for hash partitioning. For example: PARTITION BY HASH(c1, p1).

Table attributes (table_options)

Table attributes (table_options) are supported only by LindormTable. You can use the WITH keyword to add the following table attributes:

Option (option_identifer)

Type

Description

COMPRESSION

STRING

The compression algorithm for the table. Valid values are:

  • SNAPPY

  • ZSTD

  • LZ4

Note

In LindormTable versions earlier than 2.3.4, no compression algorithm is specified by default. In LindormTable 2.3.4 and later, the ZSTD algorithm is used by default.

TTL

INT

The time-to-live (TTL) of data, in seconds (s).

Note
  • By default, the TTL option is empty, which means the data does not expire.

  • You can add TTL=<SpecifiedTime> to the CREATE TABLE statement to set a data TTL for the table. You can also set the TTL to an empty string to remove the data TTL. For more information, see Examples.

COMPACTION_MAJOR_PERIOD

LONG

The period for the system to perform a major compaction, in milliseconds (ms). For more information, see Specify the major compaction period.

Note

Default value: Math.Min(TTL, 1728000000 ms). If you do not set a TTL, the default value of this parameter is 20 days (20 × 24 × 60 × 60 × 1000 ms = 1728000000 ms).

MUTABILITY

STRING

Related to indexes. It classifies the write patterns for the primary table. The default value is MUTABLE_LATEST.

All valid values are listed below:

  • IMMUTABLE

  • IMMUTABLE_ROWS

  • MUTABLE_LATEST

  • MUTABLE_ALL

  • MUTABLE_UDT

For more information about the values, see High-performance native secondary indexes.

Important

The value of the MUTABILITY parameter cannot be modified after an index table is created. To adjust this parameter, you must first delete all index tables. We recommend that you back up your data before the operation to prevent data loss.

CONSISTENCY

STRING

The consistency attribute of the table. For a multi-zone instance, this parameter specifies the data consistency between the primary and replica data. It includes the following two levels:

  • eventual: eventual consistency. This is the default value.

  • strong: strong consistency.

Important

For a multi-zone instance, if data is read before it is written, such as in increase, append, or index update operations, you must set the CONSISTENCY parameter of the primary table to strong to ensure data consistency between the primary and replica data.

NUMREGIONS

INT

The number of regions to pre-create for the table.

CHS

INT

The boundary for hot and cold data separation, in seconds.

Note
  • To set the boundary for hot and cold data separation, you must enable the cold storage feature. For more information about the feature and how to enable it, see Introduction to hot and cold data separation.

  • When you set the boundary for hot and cold data separation, you must also set CHS_L2='storagetype=COLD'.

STARTKEY and ENDKEY

Same data type as the first column in the PRIMARY KEY

The start and end keys for pre-created region partitions.

Note
  • If you specify STARTKEY and ENDKEY, you must also specify NUMREGIONS. If you specify STARTKEY and ENDKEY without specifying NUMREGIONS, the settings do not take effect.

  • The string literal values specified for STARTKEY and ENDKEY are implicitly converted to the data type of the first column in the PRIMARY KEY. They are used as the start and end keys of the partitions. Currently, you can specify STARTKEY and ENDKEY only for the following data types.

    • SMALLINT

    • INTEGER

    • BIGINT

    • CHAR

    • VARCHAR

    • FLOAT

    • DOUBLE

SPLITKEYS

Same data type as the first column in the PRIMARY KEY

The start keys for all pre-split partitions of the table.

Note
  • SPLITKEYS is supported starting from LindormTable 2.5.4.

  • When you specify the SPLITKEYS value as a string, use commas (,) to separate the start keys of the pre-split partitions. A comma enclosed in a pair of double quotation marks is treated as a regular character.

  • You cannot use SPLITKEYS together with NUMREGIONS, STARTKEY, and ENDKEY.

  • Similar to STARTKEY and ENDKEY, the specified string literal values are implicitly converted to the data type of the first column in the PRIMARY KEY. They are used as the start keys of the partitions. Only the following data types are supported.

    • SMALLINT

    • INTEGER

    • BIGINT

    • CHAR

    • VARCHAR

    • FLOAT

    • DOUBLE

SPLITALGO

STRING

Defines the splitting algorithm for pre-partitioning. Currently, only the following splitting algorithms are supported:

  • HexStringSplit: splits the primary key based on hexadecimal bytes.

  • UniformSplit: evenly splits the primary key based on the original byte values.

DYNAMIC_COLUMNS

STRING

Specifies whether to enable dynamic columns. Valid values:

  • True: Yes.

  • False: No. This is the default value.

Note

Dynamic columns support only the Varbinary type.

VERSIONS

STRING

The number of versions to retain for a column value. The value must be an integer greater than or equal to 1. The default value is 1, which means one version is retained. Lindorm supports retaining multiple versions of a column value. For more information about multi-version data management, see Multi-version data management.

Important

A large value for the VERSIONS parameter may affect data query and storage performance. Avoid setting an excessively large value. We recommend that you set VERSIONS to 1.

BLOB_BUCKET_NAME

STRING

Creates a bucket for a table that contains BLOB columns. The value is a custom bucket name.

The bucket name must follow these rules:

  • Can contain only lowercase letters, digits, periods (.), and hyphens (-).

  • Must be 3 to 63 characters in length.

  • Cannot start or end with a hyphen (-).

  • Cannot contain consecutive periods (.).

Note
  • BLOB_BUCKET_NAME is supported starting from LindormTable 2.6.4.

  • If you do not set a BLOB column when you create a table but set the BLOB_BUCKET_NAME attribute, the system does not check the bucket name.

Note

LindormTable versions earlier than 2.2.16 do not support the WITH keyword for setting table attributes. You must enclose the table attribute keyword in single quotation marks ('). The attribute value is set based on its type. If the attribute value is a string, enclose it in single quotation marks ('). For example, CREATE TABLE IF NOT EXISTS t1(c1 varchar, c2 bigint, c3 int, c4 int, PRIMARY KEY(c1,c2)) 'CONSISTENCY'='strong';.

Examples

Create a table

CREATE TABLE sensor (
    device_id VARCHAR NOT NULL,
    region VARCHAR NOT NULL,
    time TIMESTAMP NOT NULL,
    temperature DOUBLE,
    humidity BIGINT,
    PRIMARY KEY(device_id, region, time)
);

Verify the result

Execute the DESCRIBE table sensor; statement to check whether the table is created.

Create an index when you create a table

Create a secondary index when you create a table.

CREATE TABLE IF NOT EXISTS sensor (
    device_id VARCHAR NOT NULL,
    region VARCHAR NOT NULL,
    time TIMESTAMP NOT NULL,
    temperature DOUBLE,
    humidity BIGINT,
    PRIMARY KEY(device_id, region, time),
    KEY (temperature, time)
);

Verify the result

Execute the DESCRIBE table sensor; statement to check whether the table is created, and then execute SHOW INDEX FROM sensor; to check whether the secondary index is created.

Specify the data TTL and compression algorithm

Create a wide table, set the data TTL to 30 days (2,592,000 seconds), and set the compression algorithm to ZSTD.

CREATE TABLE sensor (
    device_id VARCHAR NOT NULL,
    region VARCHAR NOT NULL,
    time TIMESTAMP NOT NULL,
    temperature DOUBLE,
    humidity BIGINT,
    PRIMARY KEY(device_id, region, time)
) WITH (COMPRESSION='ZSTD', TTL='2592000');

Verify the result

  • Execute the DESCRIBE table sensor; statement to check whether the table is created.

  • On the Overview page of the cluster management system, click the name of the destination table in the destination database. In the Current Table Details area, click View Table Properties to view the values of the COMPRESSION and TTL parameters.

Specify the major compaction period

Create a wide table and set the major compaction period to 10 days (864,000,000 milliseconds).

CREATE TABLE sensor (
    device_id VARCHAR NOT NULL,
    region VARCHAR NOT NULL,
    time TIMESTAMP NOT NULL,
    temperature DOUBLE,
    humidity BIGINT,
    PRIMARY KEY(device_id, region, time)
) WITH (COMPACTION_MAJOR_PERIOD='864000000');

Verify the result

  • Execute the DESCRIBE table sensor; statement to check whether the table is created.

  • On the Overview page of the cluster management system, click the name of the destination table in the destination database. In the Current Table Details area, click View Table Properties to view the value of the COMPACTION_MAJOR_PERIOD parameter.

Enable dynamic columns

Create a wide table and set the DYNAMIC_COLUMNS parameter to TRUE to support writing dynamic column data to the table.

CREATE TABLE sensor (
    device_id VARCHAR NOT NULL,
    region VARCHAR NOT NULL,
    time TIMESTAMP NOT NULL,
    temperature DOUBLE,
    humidity BIGINT,
    PRIMARY KEY(device_id, region, time)
) WITH (DYNAMIC_COLUMNS='TRUE');

Verify the result

  • Execute the DESCRIBE table sensor; statement to check whether the table is created.

  • On the Overview page of the cluster management system, click the name of the destination table in the destination database. In the Current Table Details area, click View Table Properties to view the value of the DYNAMIC_COLUMNS parameter.

Specify the boundary for hot and cold data separation

Create a wide table and set the boundary for hot and cold data separation. The system archives data based on this boundary.

CREATE TABLE sensor (
    device_id VARCHAR NOT NULL,
    region VARCHAR NOT NULL,
    time TIMESTAMP NOT NULL,
    temperature DOUBLE,
    humidity BIGINT,
    PRIMARY KEY(device_id, region, time)
) WITH (CHS = '86400', CHS_L2 = 'storagetype=COLD');

Verify the result

  • Execute the DESCRIBE table sensor; statement to check whether the table is created.

  • On the Overview page of the cluster management system, click the name of the destination table in the destination database. In the Current Table Details area, click View Table Properties to view the values of the CHS and CHS_L2 parameters.

Set multiple attributes at the same time

Create a wide table and specify the compression algorithm, data TTL, and the boundary for hot and cold data separation.

CREATE TABLE sensor (
    device_id VARCHAR NOT NULL,
    region VARCHAR NOT NULL,
    time TIMESTAMP NOT NULL,
    temperature DOUBLE,
    humidity BIGINT,
    PRIMARY KEY(device_id, region, time)
) WITH (
    COMPRESSION='ZSTD', 
    CHS = '86400', 
    CHS_L2 = 'storagetype=COLD', 
    TTL = '2592000');

Verify the result

  • Execute the DESCRIBE table sensor; statement to check whether the table is created.

  • On the Overview page of the cluster management system, click the name of the destination table in the destination database. In the Current Table Details area, click View Table Properties to view the values of the COMPRESSION, CHS, CHS_L2, and TTL parameters.

Set partitions

Create a wide table with five predefined partitions. The start key of the partitions is 1000 and the end key is 9000.

CREATE TABLE sensor (
  p1 INTEGER NOT NULL, 
  c1 INTEGER, 
  c2 VARCHAR, 
  c3 VARCHAR,
  PRIMARY KEY(p1)
) WITH (NUMREGIONS='5', STARTKEY='1000', ENDKEY='9000');

Verify the result

  • Execute the DESCRIBE table sensor; statement to check whether the table is created.

  • On the Overview page of the cluster management system, click the name of the destination table in the destination database. In the Shard Details area, you can view the values of the startKey and endKey parameters for each shard.

Set the start keys of multiple partitions

Create a wide table and predefine the start keys for five partitions. After the table is created, it contains six pre-split partitions by default.

CREATE TABLE sensor (
  p1 INT NOT NULL,
  p2 INT NOT NULL,
  c1 VARCHAR,
  c2 BIGINT,
  PRIMARY KEY(p1, p2)
) WITH (SPLITKEYS = '100000,300000,500000,700000,900000');

Verify the result

  • Execute the DESCRIBE table sensor; statement to check whether the table is created.

  • On the Overview page of the cluster management system, click the name of the destination table in the destination database. In the Shard Details area, you can view the values of the startKey and endKey parameters for each shard.

Explicitly specify a partition key column

Most query scenarios involve querying the instantaneous data of a single device. Therefore, you can explicitly specify device_id as the partition key column for data partitioning.

CREATE TABLE sensor (
    device_id VARCHAR NOT NULL,
    region VARCHAR NOT NULL,
    time TIMESTAMP NOT NULL,
    temperature DOUBLE,
    humidity BIGINT,
    PRIMARY KEY(device_id, region, time)
) PARTITION BY HASH(device_id);

Verify the result

Execute the DESCRIBE TABLE sensor; statement to verify the result.