TDSQL-C for MySQL
- Release Notes and Announcements
- Announcements
- Product Introduction
- Suggestions on Usage Specifications
- Kernel Features
- Kernel Version Release Notes
- Optimized Kernel Version
- Functionality Features
- Performance Features
- Security Features
- Stability Feature
- Analysis Engine Features
- Purchase Guide
- Value-Added Services Billing Overview
- Database Audit
- Audit Rule Template
- Serverless Service
- Serverless Introduction
- Serverless Resource Pack
- Configuration Change
- Operation Guide
- Database Connection
- Configuring Network Address
- Instance Management
- Configuration Adjustment
- Instance Mode Management
- Cluster Management
- Scaling Instance
- Database Proxy
- Database Proxy Kernel Features
- Managing Database Proxy
- Automatic Read/Write Separation
- Connection Pool Feature
- Other Features
- Account Management
- Console Account
- Database Account
- Configuring Custom Password Strength
- Database Management
- Database Management Tool
- Columnar Storage Index (CSI)
- Utilization of Columnar Storage Indexes
- Read-Only Analysis Engine
- Feature Limits and Compatibility
- Description of Functions and Operators
- Read-Only Analysis Engine Management
- Data Loading
- Executing Queries
- Exclusive Features
- Performance Optimization
- Performance White Paper
- Parameter Configuration
- Multi-AZ Deployment
- Backup and Restoration
- Performing Backup
- Managing Backup
- Rollback
- Restoring Data from Logical Backups
- Restoring Data Through the Console
- Restoring Data from Snapshot Backup
- Data Migration
- Parallel Query
- Setting Parallel Query
- Database Security and Encryption
- Access and Authorization
- Security Group Management
- TencentDB Security Group Management
- Monitoring and Alarms
- Monitoring
- Alarms
- Monitoring Metric Alarm
- Practical Tutorial
- Data Rollback
- Database/Table-Level Rollback
- Rolling back Entire Cluster
- White Paper
- Security White Paper
- Performance White Paper
- Troubleshooting
- Connection Issues
- API Documentation
- Making API Requests
- Instance APIs
- Account APIs
- Audit APIs
- Database Proxy APIs
- Backup and Restoration APIs
- Parameter Management APIs
- Performance Analysis APIs
- Serverless APIs
- ResourcePackage APIs
- Other APIs
- FAQs
- Service Agreement
- TDSQL-C Policy
- General References
ETL Writeback Acceleration
Last updated: 2025-03-20 16:04:25
In databases, the INSERT INTO <Table> SELECT... statement is often executed. If the execution time of SELECT is too long, the overall execution efficiency becomes low. The read-only analysis engine can handle complex queries in online SQL statements. By using this feature, the SELECT query in an INSERT...SELECT... statement can be executed in the read-only analysis engine to accelerate the SELECT query. The data is automatically written back to the read-write instance, thereby greatly improving the SQL execution efficiency.
Technical Principles
As shown in the above figure, you can execute the
INSERT…SELECT… statement in the read-only analysis engine. The SELECT query will be accelerated by the read-only analysis engine, and the query results will be directly written to the read-write instance, thereby improving the overall execution efficiency.Application Scenario
Note:
This feature applies only to scenarios that are not sensitive to data latency. The read-only analysis engine adopts the asynchronous replication mode. Therefore, a certain time delay may exist between the query results and those in the read-write instance when there is a latency in the read-only analysis engine.
This feature is recommended in scenarios where the query conditions are complex, the SQL statement execution time is long, and the data volume of the query result set is small. In such scenarios, this feature can significantly improve performance because the read-only analysis engine will accelerate SELECT queries.
This feature does not bring performance benefits in all scenarios. Instead, the performance may deteriorate in some scenarios. For example:
When the SELECT query in an
INSERT…SELECT… statement is relatively simple, reading data from the read-only analysis engine and writing the data back to the read-write instance will incur additional network overhead. The strengths are not obvious compared with the method of directly reading data from the read-write instance.When the result set of the SELECT query in an
INSERT…SELECT… statement contains a large volume of data, the main performance bottleneck lies in the process of transmitting the result set over the network and writing it to the read-write instance. In this scenario, this feature cannot be used to improve performance.Was this page helpful?
You can also Contact Sales or Submit a Ticket for help.
Yes
No