All Products
Search
Document Center

Lindorm:CREATE TABLE

Last Updated:Dec 24, 2025

You can use the CREATE TABLE statement to create a table in LindormTable or LindormTSDB. This statement supports multiple data types, such as VARCHAR, TIMESTAMP, and BIGINT. It also supports various table properties, such as time-to-live (TTL) and the COMPRESSION algorithm. You can combine these properties and data types to design tables that best fit your business scenarios.

Engines and versions

  • CREATE TABLE applies to LindormTable and LindormTSDB.

  • LindormTSDB supports the standard CREATE TABLE syntax in versions 3.4.32 and later. To view or upgrade your database engine version, see LindormTSDB version guide and Minor version update.

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 ]
                            [ ZORDER BY zorder_column_list ]
                            [ 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 )* ')'
zorder_column_list     ::=  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)

0

Column definition (column_definition)

0

Primary key (primary_key)

0

0

Index expression (KEY|INDEX)

0

✖️

Partition (partition_definition)

✖️

0

Table properties (table_options)

0

✖️

Usage notes

Table name (table_identifier)

Note the following when you set a table name:

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

  • The name cannot start with a period (.) or a hyphen (-).

  • The name must be 1 to 255 characters in length.

Column definition (column_definition)

Syntax element

Required

Usage notes

Column name (column_identifier)

Yes

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

  • You cannot use reserved keywords 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 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. 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(GMT+8)  in LindormTSDB.

NULL constraint

No

Specifies whether the column value can be NULL.

Important

Currently, Lindorm SQL does not validate NULL constraints. The storage engine performs this validation.

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

To ensure that data can be 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, do not specify NOT NULL in the column definition.

Primary key (primary_key)

A 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

You cannot modify a primary key 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

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 a time series table, a primary key column of the VARCHAR type is called a tag column, and a primary key column of the TIMESTAMP type is called a timestamp column.

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

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

  • In a time series table, use the unique identifier of the data source as the PRIMARY KEY, such as the device ID in Internet of Things (IoT) scenarios, the unique vehicle identifier in Internet of Vehicles (IoV) scenarios, or the application ID or ip:port in monitoring scenarios. For more information, see Best practices for PRIMARY KEY design.

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 in LindormTable 2.7.7 or later and Lindorm SQL 2.8.6.0 or later.

  • To view your LindormTable and Lindorm SQL versions, see LindormTable version guide and SQL version guide. If you cannot upgrade to these versions in the console, 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 table_name_idx_${auto_increment_id}.

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

  • Secondary index redundancy:

    Lindorm SQL 2.9.3.10 and later

    If you do not specify the INCLUDE clause when you create a secondary index, all columns are not redundantly stored by default.

    Lindorm SQL versions earlier than 2.9.3.10

    If you do not specify the INCLUDE clause when you create a secondary index, all columns are redundantly stored by default.

    Note

    The redundancy effect is the same as setting the index property INDEX_COVERED_TYPE to COVERED_ALL_COLUMNS_IN_SCHEMA. If the table created here is a dynamic table, the effect is the same as setting the property to COVERED_DYNAMIC_COLUMNS.

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

  • If a 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 table and index may remain in a residual state and are not automatically cleared or deleted. You can view them using statements such as SHOW and DESCRIBE, but you may be unable to write data or perform queries. We recommend that you clear the residual table and index and then recreate them.

Partition (partition_definition)

Partitions are supported only by LindormTSDB. In a time series table, the columns used for PARTITION BY must be VARCHAR columns 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 to hash-partition the table. For example: PARTITION BY HASH(c1, p1).

Table properties (table_options)

Only the wide table engine supports table properties (table_options). You can use the WITH keyword to add the following table properties:

Option (option_identifer)

Type

Description

COMPRESSION

STRING

The compression algorithm for the table. The optional compression algorithms are:

  • SNAPPY

  • ZSTD

  • LZ4

Note

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

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 set a TTL for a table by adding TTL=<specified_time> to the table creation statement, or remove the TTL by setting its value to an empty string. For more information, see Examples.

COMPACTION_MAJOR_PERIOD

LONG

The period for the system to execute major compaction, in milliseconds (ms). For more information, see Specify Major Compaction Period.

Note

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

MUTABILITY

STRING

An attribute related to indexes that specifies the mutability of the base 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

After you create an index table, you cannot modify the value of the MUTABILITY parameter. To adjust this parameter, you must first delete all index tables. Back up your data before the operation to prevent data loss.

CONSISTENCY

STRING

The consistency property of the table. For multi-zone instances, this parameter indicates the data consistency between the primary and standby data. It includes the following two levels:

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

  • strong: strong consistency.

Important

For multi-zone instances, if your data involves read-after-write operations, such as increase, append, or index updates, you must set the CONSISTENCY parameter of the primary table to strong to ensure data consistency between the primary and standby instances.

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 Hot and cold data separation.

  • When you set the hot/cold data boundary option, you must also set CHS_L2='storagetype=COLD'.

STARTKEY and ENDKEY

Same as the data type of the first column in the PRIMARY KEY

The start key and end key for pre-creating region partitions for the table.

Note
  • If you specify STARTKEY and ENDKEY, you must also specify NUMREGIONS. If you specify STARTKEY and ENDKEY without specifying NUMREGIONS, the settings have no effect.

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

    • SMALLINT

    • INTEGER

    • BIGINT

    • CHAR

    • VARCHAR

    • FLOAT

    • DOUBLE

SPLITKEYS

Same as the data type of the first column in the PRIMARY KEY

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

Note
  • SPLITKEYS is supported since LindormTable 2.5.4.

  • In the string value of SPLITKEYS, use commas (,) to separate the start keys of the pre-created partitions. Commas enclosed in double quotation marks are treated as regular characters.

  • SPLITKEYS cannot be used with NUMREGIONS, STARTKEY, or ENDKEY.

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

    • SMALLINT

    • INTEGER

    • BIGINT

    • CHAR

    • VARCHAR

    • FLOAT

    • DOUBLE

SPLITALGO

STRING

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

  • HexStringSplit: Splits the primary key using hexadecimal bytes.

  • UniformSplit: Performs an even split using 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. For more information about dynamic columns, see Dynamic columns.

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 column values. 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. 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 since LindormTable 2.6.4.

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

Note

In LindormTable versions earlier than 2.2.16, the WITH keyword is not supported when you set table properties. You must enclose the table property keyword in single quotation marks ('). You can set property values based on their data types. If the property value is a string (STRING), you must also enclose the string 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)
);

Verifying the results

You can execute DESCRIBE table sensor; to check whether the table has been created successfully.

Create an index when creating 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)
);

Result Verification

You can execute DESCRIBE table sensor; to check if the table was created successfully, and execute SHOW INDEX FROM sensor; to check if the secondary index was created successfully.

Specify the TTL and compression algorithm

When you create a wide table, set the TTL to 30 days (2592000 seconds) and 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 results

  • You can execute DESCRIBE table sensor; to check whether the table has been created successfully.

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

Specify the Major Compaction period

When you create a wide table, 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

  • You can execute DESCRIBE table sensor; to check whether the table has been created successfully.

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

Enable the dynamic column feature

After you set the DYNAMIC_COLUMNS parameter to TRUE when you create a wide table, you can write 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

  • You can execute DESCRIBE table sensor; to check whether the table was created successfully.

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

Specify the boundary for hot and cold data

When you create a wide table, set the boundary for hot and cold data. 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');

Verifying the result

  • You can execute DESCRIBE table sensor; to check whether the table was successfully created.

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

Set multiple properties at the same time

When you create a wide table, specify the compression algorithm, TTL, and the boundary for hot and cold data.

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');

Verifying the results

  • You can execute DESCRIBE table sensor; to check whether the table has been created successfully.

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

Set partitions

When you create a wide table, you can predefine five partitions. The start key for these 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');

Verifying the result

  • You can execute DESCRIBE table sensor; to check whether the table has been created successfully.

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

Set the start keys for multiple partitions

When you create a wide table, you can pre-define five start keys. The table is then created with six 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');

Verifying the results

  • You can execute DESCRIBE table sensor; to verify that the table was created successfully.

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

Explicitly specify partition key columns

Most query scenarios involve querying the instantaneous data of a single device. For these scenarios, 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);

Verifying the result

You can execute the DESCRIBE TABLE sensor; statement to verify the table creation result.

Create a spatio-temporal data table

  • Create a table that supports any spatial data type (Geometry). You can write data of any spatial data type to the table.

    CREATE TABLE geoms(gid INT, g GEOMETRY, PRIMARY KEY(gid));

    Write data of any spatial data type.

    UPSERT INTO geoms(gid, g) VALUES(0,ST_GeomFromText('POINT(-10.1 3.3)')),(1,ST_GeomFromText('LINESTRING(-12.2 4.3, -10.2 4.3)')),(2,ST_GeomFromText('POLYGON((2 2, 2 8, 8 8, 8 2, 2 2))'));
  • Create a table that supports the Point type. You can only write point data to the table.

    CREATE TABLE pts(gid INT, g GEOMETRY(POINT), PRIMARY KEY(gid));

    Write point data.

    UPSERT INTO pts(gid, g) VALUES(0, ST_MakePoint(0,0)),(1, ST_MakePoint(1,1));
  • Create a table that supports the Polygon type. You can only write polygon data to the table.

    CREATE TABLE polys(gid INT, g GEOMETRY(POLYGON), PRIMARY KEY(gid));

    Write polygon data.

    UPSERT INTO polys(gid,g) VALUES(0,ST_GeomFromText('POLYGON((2 2, 2 8, 8 8, 8 2, 2 2))'));
  • Create a table that supports the LineString type. You can only write line data to the table.

    CREATE TABLE lines(gid INT, g GEOMETRY(LINESTRING), PRIMARY KEY(gid));

    Write line data.

    UPSERT INTO lines(gid,g) VALUES(0, ST_GeomFromText('LINESTRING(-12.2 4.3, -10.2 4.3)'));
  • Create a table that supports the MULTIPOINT type. You can only write multipoint data to the table.

    CREATE TABLE multipoints(gid INT, g GEOMETRY(MULTIPOINT), PRIMARY KEY(gid));

    Write multipoint data.

    UPSERT INTO multipoints(gid,g) VALUES(0, ST_GeomFromText('MULTIPOINT (10 40, 40 30, 20 20, 30 10)'));
  • Create a table that supports the MULTILINESTRING type. You can only write multilinestring data to the table.

    CREATE TABLE multilines(gid INT, g GEOMETRY(MULTILINESTRING), PRIMARY KEY(gid));

    Write multilinestring data.

    UPSERT INTO multilines(gid,g) VALUES(0, ST_GeomFromText('MULTILINESTRING ((10 10, 20 20, 10 40),(40 40, 30 30, 40 20, 30 10))'));
  • Create a table that supports the MULTIPOLYGON type. You can only write multipolygon data to the table.

    CREATE TABLE multipolys(gid INT, g GEOMETRY(MULTIPOLYGON), PRIMARY KEY(gid));

    Write multipolygon data.

    UPSERT INTO multipolys(gid,g) VALUES(0, ST_GeomFromText('MULTIPOLYGON (((30 20, 45 40, 10 40, 30 20)),((15 5, 40 10, 10 20, 5 10, 15 5)))'));
  • Create a table that supports the GEOMETRYCOLLECTION type. You can only write geometry collection data to the table.

    CREATE TABLE collections(gid INT, g GEOMETRY(GEOMETRYCOLLECTION), PRIMARY KEY(gid));

    Write geometry collection data.

    UPSERT INTO collections(gid,g) VALUES(0, ST_GeomFromText('GEOMETRYCOLLECTION (POINT (40 10), LINESTRING (10 10, 20 20, 10 40), POLYGON ((40 40, 20 45, 45 30, 40 40)))'));
  • Create a table that consists of columns of multiple spatial data types (Geometry).

    CREATE TABLE mix(gid INT, pt GEOMETRY(POINT), ply GEOMETRY(POLYGON), PRIMARY KEY(gid));