Data Loading Restrictions
Last updated:2025-08-25 18:41:37
The analysis engine builds data through columnar storage. Therefore, certain special MySQL usage scenarios are not supported, as shown below:
Description of supported tables without primary keys and unique keys
In version 1.2404.x: When a table has neither a primary key nor a unique key, the table cannot be loaded into the analysis engine. This requires that tables contain a primary key or a unique key. In the LibraDB engine, the primary key or unique key of a table is used by default to build columnar data. In addition, in version 1.2404.x, any form of DDL statements to modify table primary keys is not supported. If a primary key is modified in TencentDB for MySQL, the corresponding table in the analysis engine is no longer loaded and cannot be queried. To use the table again, you need to remove this table and then reload it.
In version 2.2410.x: Tables can also be loaded into the analysis engine without a primary key or unique key, and changes to the table primary keys are also supported. However, the following special scenarios are not supported:
The table only has fields such as time, date, timestamp, datetime, float, and double, and no other field types.
When primary key DDL is performed to a table, no other field types except the above ones exist in the table.
Tables using columns of the float or double field type as the primary key cannot be loaded into the analysis engine.
Float and double field types are floating-point field types. Tables using columns of the two types as the primary key cannot be loaded into the analysis engine.
Stored procedures, user-defined functions, triggers, foreign key constraints, events, and indexes are not loaded into the analysis engine.
It is not supported to build the above special objects in columnar storage.
Tables with spatial-type fields cannot be loaded into the analysis engine. Tables with JSON-type fields can be loaded into the analysis engine but cannot be queried.
Tables with spatial-type fields cannot be loaded into the analysis engine. When tables with JSON fields are queried in the analysis engine, the JSON column values will be empty.
Loading temporary tables into the analysis engine is not supported.
Data modifications of temporary tables are not logged. Therefore, the data of temporary tables cannot be loaded into the analysis engine.
Behavior of tables loaded into the analysis engine after being renamed
When a table is loaded into the analysis engine, a table will be automatically loaded into the analysis engine after it is renamed by executing the rename statement. At this time, if a table with the same name as the renamed table is created, the new table will also be automatically loaded into the analysis engine. For example, table A has been loaded as a columnar storage table into the analysis engine. If table A is renamed to table B, the table name changes to table B as well in the analysis engine. If a new table named table A is added in the read-write instance, this table A is also automatically loaded into the analysis engine.
Loading tables with primary key fields of ultra-long numeric types into columnar storage is not supported
In version 1.2404.x, loading a table with a primary key of Decimal exceeding 128 characters into columnar storage is not supported.
In version 2.2410.x, loading tables with a primary key of Decimal exceeding 256 characters into columnar storage is not supported.
Column-level permissions are not supported
By default, the analysis engine synchronizes all users' permissions to query objects in the primary instance but does not synchronize column-level permissions. Therefore, it is impossible to control column-level permissions in the analysis engine.
Unsupported data types
The analysis engine does not support certain data types. If a table contains objects of unsupported data types, the table cannot be loaded into the analysis engine.
Unsupported table structure
The analysis engine does not support the syntax of generated columns, regardless of virtual columns or physical columns. Tables containing generated columns cannot be loaded into the analysis engine.
Unsupported field type conversion
Conversions of certain field types are not supported in the analysis engine. If data type conversion is performed in the primary instance of TencentDB for MySQL, the data loading task of the analysis engine may be terminated, and the loading statuses of all tables may become Paused. For detailed information on the type conversion support, see Description of Supported Type Conversion Functions.
Note:
If you modify the field type of a table in TencentDB for MySQL, and this type modification is not supported in the analysis engine, the loading statuses of all tables become Paused. At this time, to use the table again, you need to remove the table and then reload it.
Description of DDL synchronization for partition tables
In version 1.2404.x: Partition tables can be loaded into the analysis engine by default and support querying. However, synchronization of related DDL operations on partitions of partition tables is not supported, such as rebuilding partitions, optimizing partitions, fixing partitions, checking partitions, exchanging partitions, deleting partitions, and merging partitions. In addition, querying a specific subpartition is not supported in the analysis engine.
Note:
When you drop a subpartition, truncate a partition, or exchange partitions for a partition table in the primary instance of TencentDB for MySQL, this table cannot be queried in the analysis engine. To use the table again, you need to remove this table and then reload it.
In version 2.2410.x: Partition tables can be loaded into the analysis engine, and the following DDL operations can be performed on partition tables on the source side.
Support the Drop Partition/Subpartition template of Range/List partition tables.
Support the Add Partition/Subpartition template of Range/List partition tables.
In the scenario without functions, the supported partition data types include Uint8, Uint16, Uint32, Uint64, Int8, Int16, Int32, and Int64.
Description of DDL synchronization for ordinary tables
DDL operations on tables in the primary instance of TencentDB for MySQL will be synchronized normally to the analysis engine. However, in the following scenarios, issues will occur when you use tables in the analysis engine.
After a DDL operation is performed on a table, the table cannot be used normally in the analysis engine if any of the unsupported scenarios mentioned in this document exist.
Schema changes via pt-osc and gh-ost and lock-free data changes via Alibaba Cloud DMS on tables can be synchronized normally.
Primary key modifications (addition, deletion, and change) for tables with over 1 million rows can cause synchronization to the analysis engine to be paused. For tables with over 1 million rows, it is recommended that tools like pt-osc be used to perform DDL operations for primary key modifications.
Was this page helpful?
You can also Contact Sales or Submit a Ticket for help.
Yes
No
Feedback