DML operations

更新时间:
复制 MD 格式

Non-transactional tables in Tablestore support INSERT, UPDATE, and DELETE statements through SQL.

Scope

Item

Description

Table type

Non-transactional tables only (tables created without transactions enabled)

Supported DML statements

INSERT, UPDATE, DELETE

Query statements

SELECT and SHOW are not subject to DML restrictions. For more information, see the SQL query documentation.

Partial DML syntax

INSERT IGNORE, ON DUPLICATE KEY UPDATE, REPLACE, and similar syntax are only supported for transactional tables.

Prerequisites

Make sure that you have:

  • A non-transactional table

  • An SQL mapping created for the table by using a CREATE TABLE statement

Note

To run DML operations with a RAM user, grant the SQL_DML permission to the RAM user. For more information, see RAM policy.

Access methods

You can run DML operations through the console, SDKs, or other access methods.

Console

  1. Log on to the Tablestore console.

  2. On the Overview, click Instance Name.

  3. On the Instances page, click the Query by Executing SQL Statement tab.

  4. Enter a DML statement in the SQL editor and click Execute SQL Statement.

Example: Insert a row.

INSERT INTO my_table VALUES (1, 'value1', 100);

SDK

Java

Use SyncClient.sqlQuery() in the Tablestore SDK for Java to run DML statements. Call getAffectedRows() on SQLQueryResponse to get the number of affected rows, and getConsumedCapacity() to get the consumed read and write CUs.

Note

SDK version 5.17.11 or later is required.

SQLQueryRequest request = new SQLQueryRequest("INSERT INTO my_table VALUES (1, 'value1', 100)");
SQLQueryResponse response = client.sqlQuery(request);
long affectedRows = response.getAffectedRows();
Map<String, ConsumedCapacity> consumedCapacity = response.getConsumedCapacity();

Go

Use TableStoreClient.SQLQuery() in the Tablestore SDK for Go to run DML statements. Read the AffectedRows field from SQLQueryResponse to get the number of affected rows, and SQLQueryConsumed to get the consumed read and write CUs.

Note

SDK version 1.9.2 or later is required.

request := &tablestore.SQLQueryRequest{Query: "INSERT INTO my_table VALUES (1, 1, 100, 'hello')"}
response, err := client.SQLQuery(request)
if err != nil {
    log.Fatal(err)
}
affectedRows := response.AffectedRows
consumed := response.SQLQueryConsumed

INSERT statements

Non-transactional tables support single-row inserts and atomic multi-row batch inserts within the same partition key. If a primary key conflict occurs, an error is returned and existing data is not overwritten.

Single-row insert

INSERT INTO user_table VALUES (1, 'value1', 100);

Multi-row batch insert within the same partition key

Rows that share the same partition key can be atomically batch-inserted, with a maximum of 200 rows per batch. The following example uses a table schema of user_table(pk1 BIGINT, pk2 VARCHAR(1024), value BIGINT), where pk1 is the partition key. Both rows have pk1 = 1, so they belong to the same partition.

INSERT INTO user_table VALUES (1, 'attr1', 100), (1, 'attr2', 200);

Usage notes

  • Primary key conflict: Inserting a row with an existing primary key returns error code OTSParameterInvalid with a message containing Duplicate entry for key 'PRIMARY'. Existing data is not overwritten.

  • Cross-partition batch insert: All rows in a batch INSERT must share the same partition key. Batch inserts across different partition keys fail.

  • Batch size limit: A batch INSERT with more than 200 rows is rejected.

  • Affected rows: A single-row INSERT returns 1 on success. An N-row batch INSERT returns N on success. A primary key conflict does not return affected rows and directly raises an error.

UPDATE statements

Non-transactional tables support only single-row updates identified by a full primary key equality condition in the WHERE clause. For composite primary keys, the column order in the WHERE clause does not need to match the primary key definition order.

Update with constant values

Update one or more columns at the same time.

-- Single-column update
UPDATE user_table SET attr_col = 999 WHERE pk_col = 1;

-- Multi-column update
UPDATE user_table SET c1 = 10, c2 = 20, c3 = 'updated' WHERE id = 1;

-- Composite primary key update. The column order in the WHERE clause can differ from the key definition order.
UPDATE user_table SET value = 999 WHERE pk2 = 2 AND pk1 = 1;

Atomic increment and decrement

Atomically increment or decrement integer (BIGINT) attribute columns. This is useful for counters and similar use cases. Only BIGINT attribute columns are supported.

-- Increment by 1
UPDATE user_table SET counter = counter + 1 WHERE id = 1;

-- Increment by a specified value
UPDATE user_table SET counter = counter + 10 WHERE id = 1;

-- Decrement
UPDATE user_table SET counter = counter - 5 WHERE id = 1;

Set an attribute column to NULL

Setting an attribute column to NULL removes the column from the row instead of storing a NULL value.

UPDATE user_table SET attr_col = NULL WHERE pk_col = 1;

Usage notes

  • WHERE must specify the full primary key with equality conditions: The following cases are not supported and return error code OTSParameterInvalid or OTSUnsupportOperation:

    • The WHERE clause does not contain the full primary key.

    • The WHERE clause references non-primary-key columns.

    • The WHERE clause uses range conditions (>, <, BETWEEN, and similar operators).

    • The WHERE clause uses IN, LIKE, OR, !=, or other non-equality conditions.

    • The WHERE clause includes attribute column conditions in addition to the full primary key.

  • Primary key columns cannot be modified: UPDATE does not support changing primary key column values through SET.

  • Non-existent row: Updating a non-existent row succeeds silently with 0 affected rows and no error.

DELETE statements

Non-transactional tables support only single-row deletions identified by a full primary key equality condition in the WHERE clause. As with UPDATE, the column order in the WHERE clause does not need to match the primary key definition order for composite primary keys.

-- Single primary key
DELETE FROM user_table WHERE pk_col = 1;

-- String primary key
DELETE FROM user_table WHERE id = 'abc';

-- Composite primary key
DELETE FROM user_table WHERE pk1 = 1 AND pk2 = 1;

-- Composite primary key with different column order
DELETE FROM user_table WHERE pk2 = 2 AND pk1 = 1;

Usage notes

  • WHERE must specify the full primary key with equality conditions: The same constraints as UPDATE apply. Missing WHERE, partial primary key, non-primary-key column conditions, range conditions, IN, LIKE, OR, and additional attribute column conditions are all unsupported.

  • Non-existent row: Deleting a non-existent row succeeds silently with 0 affected rows and no error.

Limitations

DML operations on non-transactional tables have limitations in SQL syntax, data types, column options, and special table types.

SQL syntax limitations

The following SQL syntax is not supported:

Limitation

Applies to

Description

No WHERE clause

UPDATE, DELETE

The full primary key must be specified.

Non-primary-key columns in WHERE

UPDATE, DELETE

Only primary key equality conditions are supported.

Partial primary key in WHERE

UPDATE, DELETE

All columns of a composite primary key must be specified.

Range conditions (>, <=, BETWEEN)

UPDATE, DELETE

Only equality conditions are supported.

IN clause (multi-value)

UPDATE, DELETE

Only single-value equality matching is supported.

LIKE conditions

UPDATE, DELETE

Pattern matching is not supported.

OR conditions

UPDATE, DELETE

Logical OR is not supported.

!= conditions

UPDATE, DELETE

Inequality conditions are not supported.

IS NULL conditions (attribute columns)

UPDATE, DELETE

NULL checks on attribute columns are not supported.

Primary key + attribute column combination

UPDATE, DELETE

Only pure primary key equality conditions are supported.

ORDER BY

UPDATE, DELETE

Sorting is not supported.

LIMIT

UPDATE, DELETE

Row count limits are not supported.

IGNORE option

UPDATE, DELETE

Error suppression is not supported.

Priority settings (e.g., HIGH_PRIORITY)

INSERT, UPDATE, DELETE

Not supported.

Multi-table operations

UPDATE, DELETE

Cross-table operations are not supported.

Partition specification

INSERT, UPDATE, DELETE

Not supported.

Index hints

UPDATE, DELETE

Not supported.

INSERT SET syntax

INSERT

INSERT INTO t SET col=val is not supported.

INSERT ... SELECT

INSERT

Inserting from query results is not supported.

INSERT IGNORE

INSERT

Not supported for non-transactional tables.

ON DUPLICATE KEY UPDATE

INSERT

Not supported for non-transactional tables.

REPLACE

INSERT

Not supported.

Updating primary key columns

UPDATE

Primary key column values cannot be changed through SET.

Batch INSERT row limit

INSERT

A maximum of 200 rows per batch within the same partition key.

Data type limitations

Data type

Can be primary key

Limitations

BIGINT

Yes

UNSIGNED is not supported. The valid primary key range is -9223372036854775808 to 9223372036854775806 ([-2^63, 2^63 - 2]). Long.MAX_VALUE is a system-reserved value and cannot be used.

VARCHAR

Yes

Can be used as a primary key column.

VARBINARY

Yes

Can be used as a primary key column.

DOUBLE

No

Cannot be used as a primary key.

MEDIUMBLOB

No

Cannot be used as a primary key. Can only be an attribute column.

MEDIUMTEXT

No

Cannot be used as a primary key.

BOOL / TINYINT(1)

No

Length must be 1. Cannot be used as a primary key.

Column options and constraints

CREATE TABLE supports only the following column options: PRIMARY KEY, NOT NULL, NULL, DEFAULT VALUE, and ON UPDATE. AUTO_INCREMENT, UNIQUE, CHECK, COMMENT, and other column options are not supported.

For constraints, only PRIMARY KEY is supported. UNIQUE, FOREIGN KEY, CHECK, and other constraints are not supported.

Special table type limitations

Tables bound to search indexes and alias tables do not support any DML operations (INSERT, UPDATE, DELETE).

Billing

INSERT, UPDATE, and DELETE on non-transactional tables are single-row atomic operations. Before each write, Tablestore validates the target row, such as checking whether it exists or whether column values have changed. This validation consumes read CUs.

  • Actual write occurs: Both read CUs and write CUs are consumed.

  • No actual write occurs (INSERT with a primary key conflict, UPDATE or DELETE on a non-existent row, or UPDATE with unchanged column values): Only read CUs are consumed. No write CUs are consumed.