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
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
-
Log on to the Tablestore console.
-
On the Overview, click Instance Name.
-
On the Instances page, click the Query by Executing SQL Statement tab.
-
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.
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.
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
OTSParameterInvalidwith a message containingDuplicate 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
OTSParameterInvalidorOTSUnsupportOperation:-
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 ( |
UPDATE, DELETE |
Only equality conditions are supported. |
|
|
UPDATE, DELETE |
Only single-value equality matching is supported. |
|
|
UPDATE, DELETE |
Pattern matching is not supported. |
|
|
UPDATE, DELETE |
Logical OR is not supported. |
|
|
UPDATE, DELETE |
Inequality conditions are not supported. |
|
|
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 ... 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 |
|
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.