tencent cloud

Feedback

Data Loading Limitations

Last updated: 2025-01-09 14:28:33
As the read-only analysis engine builds data through columnar storage, some specific MySQL use cases are not supported, as shown below:
Tables without primary keys and unique keys cannot be loaded into the read-only analysis engine.
When a table has neither a primary key nor a unique key, it cannot be loaded into the read-only analysis engine. This requires the table to contain either a primary key or a unique key. In the LibraDB engine, the primary key or unique key of the table will be used by default for columnar data construction.
Tables with float and double field types as primary keys cannot be loaded into the read-only analysis engine.
Float and double fields are floating-point field types. The data of tables with these field types as primary keys cannot be loaded into the read-only analysis engine.
Stored procedures, custom functions, triggers, foreign key constraints, events, and indexes cannot be loaded into the read-only analysis engine.
The above special objects cannot be built in columnar storage.
Tables with unsupported field types can be loaded into the read-only analysis engine, but queries on related columns are not supported.
Queries on the following field types are not supported in the read-only analysis engine: SET, ENUM, Spatial Data Types, and JSON. For tables with such columns, queries in the read-only analysis engine will result in empty column values.
All DDL statements for partition tables will not take effect in the read-only analysis engine.
Partition tables can be loaded into the read-only analysis engine by default and support queries. However, in the read-only analysis engine, it is impossible to perform the synchronization of related DDL operations for partitions of partition tables, such as rebuilding partitions, optimizing partitions, repairing partitions, checking partitions, exchanging partitions, deleting partitions, and merging partitions. Additionally, queries on individual subpartitions are not supported in the read-only analysis engine.
Note:
When subpartition dropping, partition truncating, or partition exchanging operations are performed on a partition table in a read-write instance of TDSQL-C for MySQL, the table will be non-queryable in the read-only analysis engine. To restore usage, the table needs to be unloaded and reloaded.
Temporary tables cannot be loaded into the read-only analysis engine.
As changes to temporary table data are not logged, the data of temporary tables cannot be loaded into the read-only analysis engine.
Any modification to the primary key of tables is not supported.
Because column-based tables reorganize data based on the primary key or unique key of row-based tables, modifications to the primary key of tables of TDSQL-C for MySQL, including deleting the primary key, changing the primary key to another field, and adding a field as part of a composite primary key, are not allowed. When there is no primary key, column-based tables will be built based on the unique key. In such cases, modifications to the unique key are also not allowed.
Note:
If the primary key of a table is modified in TDSQL-C for MySQL, the table will stop being loaded into the read-only analysis engine and cannot be queried. To restore usage, the table needs to be unloaded and reloaded.
Behavior of tables renamed after being loaded into the analysis engine
When a table is loaded into the analysis engine and then renamed with a rename statement, the renamed table will also be automatically loaded into the analysis engine. If a new table is created with the same name as that of the renamed table, this new table will also be automatically loaded into the analysis engine. For example, if table A is already loaded into the read-only analysis engine as a column-based table, renaming table A to table B will cause the table in the read-only analysis engine to be renamed to table B. If a new table named table A is created in the read-write instance, it will also be automatically loaded into the read-only analysis engine.
Unsupported table creation operations
When the entire database or instance is preloaded into the analysis engine and the create table … select statement is executed in the read-write instance of TDSQL-C for MySQL, the table cannot be automatically loaded into the analysis engine. To load the table into the analysis engine, you need to remove the table from the analysis engine's loading list after its creation and then load it through the console.
Column-level permissions are not supported.
The read-only analysis engine synchronizes all user query permissions regarding objects from the read-write instance by default, but it does not synchronize column-level permissions. Therefore, column-level permissions cannot be managed in the read-only analysis engine.
Unsupported data types
The read-only analysis engine does not support certain data types. If an object has any unsupported data type, the table cannot be loaded into the analysis engine.
Unsupported table structures
The read-only analysis engine does not support generated columns, regardless of virtual or physical columns. If a table definition statement includes a generated column, data loading will be interrupted. In such cases, remove the table from the read-only analysis engine's table loading list.
Loading of views
If you need to load views, load the database containing the views directly into the read-only analysis engine. The view objects in the database will be automatically loaded into the analysis engine. If you do not need to load the entire database into the analysis engine but want to use views in the read-only analysis engine, submit a ticket.
Unsupported field type conversions
Certain field type conversions are not supported in the read-only analysis engine. If table type conversion is performed in the read-write instance of TDSQL-C for MySQL, it may cause the data loading task in the read-only analysis engine to be terminated, and the loading status of all tables will become suspended.
Note:
If the field type of a table is modified in TDSQL-C for MySQL and this type modification is not supported in the read-only analysis engine, the loading status of all tables will be suspended. To restore usage, the table needs to be unloaded and reloaded.
Supported common field type conversions are as follows:
Scenario
Supported or Not
Remarks
Conversion between numeric types (int, float, and decimal)
Supported. However, like MySQL, certain type conversions may result in precision loss.
bit is an unsupported data type, so its conversion is also not supported.
Conversion between date and time types
date/datetime can be converted to time, date, or datetime.
time cannot be converted to date and datetime.
Conversion between year/month and date/datetime is not supported.
Time conversion may result in the loss of time precision, with the logic consistent with MySQL.
Scenarios not mentioned in the above cases are currently not supported.
Conversion between date and time types and numeric types
Not supported. Conversion between date and time types and numeric types is not supported at all.
None.
Conversion between character types and all other types
Supported. However, character types have length limitations. Different length settings can cause truncation. Additionally, if there are rows in the table that cannot be converted, the modification will fail in the read-write instance.
If a string is converted to an unsupported field type, it will also result in a failed query.
Conversion from JSON, ENUM, spatial, and other types to character types
Supported. These unsupported field types can be queried normally in the read-only analysis engine after being converted to strings.
None.
Conversion of other field types
Not supported. The conversion of field types not mentioned in the table is not supported.
None.
Contact Us

Contact our sales team or business advisors to help your business.

Technical Support

Open a ticket if you're looking for further assistance. Our Ticket is 7x24 avaliable.

7x24 Phone Support