You can use the SQL INSERT, UPDATE, and DELETE statements to write, update, and delete data in Tablestore non-transactional tables.
Scope
Item | Description |
Table type | Only non-transactional tables (tables created without the transaction feature enabled). |
Supported DML statements |
|
Query statements |
|
Some DML syntax | Clauses such as |
Prerequisites
You have created a non-transactional table.
You have created an SQL mapping for the table using the
CREATE TABLEstatement.
To execute DML operations as a RAM user, you must grant the user the SQL_DML permission. For more information, see Custom RAM Policy.
Usage
You can execute DML operations on non-transactional tables using the Tablestore console or an SDK. This section shows how to use each method.
Console
Log on to the Tablestore console.
On the Overview page, click the name of an Instance Name.
On the Instances page, click the Query by Executing SQL Statement tab.
In the SQL editor, enter a DML statement and click Execute SQL Statement.
Example: Insert a row.
INSERT INTO my_table VALUES (1, 'value1', 100);SDK
Java
Use the SyncClient.sqlQuery() method of the Java SDK to execute DML statements. Retrieve the affected rows (getAffectedRows()) and the consumed read/write CUs (getConsumedCapacity()) from the SQLQueryResponse.
You must use SDK version 5.17.11 or later.
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
Execute DML statements by using the TableStoreClient.SQLQuery() method of the Go SDK. Obtain the number of affected rows (AffectedRows) and the consumed read and write CUs (SQLQueryConsumed) from the SQLQueryResponse.
You must use SDK version v1.9.2 or later.
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.SQLQueryConsumedINSERT statement
For non-transactional tables, the INSERT statement supports single-row inserts and atomic multi-row batch inserts within the same partition key. If a primary key conflict occurs, the operation returns an error and does not overwrite existing data.
Single-row insert
INSERT INTO user_table VALUES (1, 'value1', 100);Batch insert in a single partition
Multiple rows that share the same partition key can be atomically inserted in a single batch of up to 200 rows. For example, assume the table structure is user_table(pk1 BIGINT, pk2 VARCHAR(1024), value BIGINT), where pk1 is the partition key. Two rows that both have a partition key pk1 of 1 belong to the same partition and can therefore be atomically inserted in a batch.
INSERT INTO user_table VALUES (1, 'attr1', 100), (1, 'attr2', 200);Notes
Primary key conflict: Inserting a row with an existing primary key returns an error with the error code
OTSParameterInvalidand an error message that containsDuplicate entry for key 'PRIMARY'. The existing data is not overwritten.Cross-partition batch inserts: All rows in a batch
INSERTstatement must have the same partition key.Batch size limit: A batch
INSERTstatement that contains more than 200 rows is rejected.Affected rows: A successful single-row
INSERTreturns 1. A successful N-row batch insert returns N. If a primary key conflict occurs, the operation returns an error instead of the number of affected rows.
UPDATE statement
For non-transactional tables, the UPDATE statement supports only single-row updates specified by an equality condition on the full primary key. For a composite primary key, the order of columns in the WHERE clause does not need to match the key's defined column order.
Update with constant values
You can update single or multiple columns simultaneously.
-- Update a single column
UPDATE user_table SET attr_col = 999 WHERE pk_col = 1;
-- Update multiple columns
UPDATE user_table SET c1 = 10, c2 = 20, c3 = 'updated' WHERE id = 1;
-- Update a row with a composite primary key. The order of columns in the WHERE clause can differ from the key definition.
UPDATE user_table SET value = 999 WHERE pk2 = 2 AND pk1 = 1;Atomic increment and decrement
You can atomically increment or decrement the value of a BIGINT attribute column. This is useful for scenarios such as counters. This operation is supported only for integer attribute columns, not for other types such as DOUBLE, BOOL, or VARCHAR.
-- 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 effectively deletes it; the system removes the column from the row rather than storing a NULL value.
UPDATE user_table SET attr_col = NULL WHERE pk_col = 1;Notes
The WHERE clause must specify an equality condition for the complete primary key: The following cases are not supported, and an
OTSParameterInvalidorOTSUnsupportOperationerror is returned:The
WHEREclause does not include the full primary key.The
WHEREclause uses a condition on a non-primary key column.The WHERE clause uses a range query (such as
>,<, orBETWEEN).The WHERE clause uses non-equality conditions such as
IN,LIKE,OR, or!=.The
WHEREclause includes a condition on an attribute column in addition to the full primary key.
Cannot modify primary key columns: The
SETclause cannot be used to modify the value of a primary key column.Target row does not exist: An
UPDATEoperation on a non-existent row completes silently with 0 affected rows. No error is returned.
DELETE statement
For non-transactional tables, the DELETE statement supports only single-row deletions specified by an equality condition on the full primary key. For a composite primary key, the order of columns in the WHERE clause does not need to match the key's defined column order.
-- Delete with a single primary key
DELETE FROM user_table WHERE pk_col = 1;
-- Delete with a string primary key
DELETE FROM user_table WHERE id = 'abc';
-- Delete with a composite primary key
DELETE FROM user_table WHERE pk1 = 1 AND pk2 = 1;
-- Delete with a composite primary key where the order of columns in the WHERE clause differs from the key definition.
DELETE FROM user_table WHERE pk2 = 2 AND pk1 = 1;Notes
The WHERE clause must be an equality condition on the complete primary key: This constraint is the same for UPDATE statements. Missing
WHEREclauses, conditions on partial or non-primary key columns, range conditions, theIN,LIKE, orORoperators, or conditions on additional attribute columns are not supported.Target row does not exist: A
DELETEoperation on a non-existent row completes silently with 0 affected rows. No error is returned.
Limitations
SQL syntax limitations
DML operations on non-transactional tables do not support the following SQL syntax:
Limitation | Operations | Description |
No |
| Full primary key required. |
|
| Only equality conditions on primary key columns are supported. |
|
| Full composite primary key required. |
Range conditions ( |
| Only equality conditions are supported. |
|
| Only single-value equality matches are supported. |
|
| Fuzzy matching is not supported. |
|
| Logical |
|
| Not-equal conditions are not supported. |
|
| Checking for null values in attribute columns is not supported. |
Combined primary key and attribute column conditions |
| Only equality conditions on the primary key are supported. |
|
| Sorting is not supported. |
|
| Limiting the number of rows is not supported. |
|
| Ignoring errors is not supported. |
Priority settings (e.g., |
| Not supported. |
Multi-table operations |
| Cross-table operations are not supported. |
Partition name specification |
| Not supported. |
Index hints |
| Index hints are not supported. |
|
|
|
|
| Inserting from a query result is not supported. |
|
| Not supported for non-transactional tables. |
|
| Not supported for non-transactional tables. |
|
| Not supported. |
Updating primary key columns |
| The |
Number of rows in a batch |
| A maximum of 200 rows per batch within the same partition key. |
Data type limitations
Type | Primary key | Limitations |
| Yes | The |
| Yes | Can be used as a primary key column. |
| Yes | Can be used as a primary key column. |
| No | Cannot be used as a primary key. |
| No | Cannot be used as a primary key. Can only be used as an attribute column. |
| No | Cannot be used as a primary key. |
| No | The length must be 1. Cannot be used as a primary key. |
Column options and constraints
When using CREATE TABLE, only the following column options are supported: PRIMARY KEY, NOT NULL, NULL, DEFAULT VALUE, and ON UPDATE.
Only the PRIMARY KEY constraint is supported.
Special table type limitations
Search-indexed tables and alias tables do not support any DML operations (INSERT, UPDATE, DELETE).
Billing
For non-transactional tables, INSERT, UPDATE, and DELETE are all single-row atomic operations. Before writing data, the system validates the target row (for example, to check if the row exists or if column values have changed). This validation process consumes read CUs.
Operations that result in a write: Consumes both read and write CUs.
Operations that do not result in a write (for example, an
INSERTwith a primary key conflict, anUPDATEorDELETEon a non-existent row, or anUPDATEwhere column values do not change): Consumes only read CUs.