tencent cloud

TDSQL-C for MySQL

Release Notes and Announcements
Release Notes
Product Announcements
Beginner's Guide
Product Introduction
Overview
Strengths
Use Cases
Architecture
Product Specifications
Instance Types
Product Feature List
Database Versions
Regions and AZs
Common Concepts
Use Limits
Suggestions on Usage Specifications
Kernel Features
Kernel Overview
Kernel Version Release Notes
Optimized Kernel Version
Functionality Features
Performance Features
Security Features
Stability Feature
Analysis Engine Features
Inspection and Repair of Kernel Issues
Purchase Guide
Billing Overview
Product Pricing
Creating Cluster
Specification Adjustment Description
Renewal
Payment Overdue
Refund
Change from Pay-as-You-Go to Yearly/Monthly Subscription
Change from Pay-as-You-Go to Serverless Billing
Value-Added Services Billing Overview
Viewing Billing Statements
Getting Started
Database Audit
Overview
Viewing Audit Instance List
Enabling Audit Service
Viewing Audit Logs
Log Shipping
Post-Event Alarm Configuration
Modifying Audit Rule
Modifying Audit Service
Disabling Audit Service
Audit Rule Template
Viewing Audit Task
Authorizing Sub-User to Use Database Audit
Serverless Service
Serverless Introduction
Creating and Managing a Serverless Cluster
Elastic Scaling Management Tool
Serverless Resource Pack
Multi-AZ Deployment
Configuration Change
FAQs
Serverless Cost Estimator
Operation Guide
Operation Overview
Switching Cluster Page View in Console
Database Connection
Instance Management
Configuration Adjustment
Instance Mode Management
Cluster Management
Scaling Instance
Database Proxy
Account Management
Database Management
Database Management Tool
Parameter Configuration
Multi-AZ Deployment
GD
Backup and Restoration
Operation Log
Data Migration
Parallel Query
Columnar Storage Index (CSI)
Analysis Engine
Database Security and Encryption
Monitoring and Alarms
Basic SQL Operations
Connecting to TDSQL-C for MySQL Through SCF
Tag
Practical Tutorial
Classified Protection Practice for Database Audit of TDSQL-C for MySQL
Upgrading Database Version from MySQL 5.7 to 8.0 Through DTS
Usage Instructions for TDSQL-C MySQL
New Version of Console
Implementing Multiple RO Groups with Multiple Database Proxy Connection Addresses
Strengths of Database Proxy
Selecting Billing Mode for Storage Space
Creating Remote Disaster Recovery by DTS
Creating VPC for Cluster
Data Rollback
Solution to High CPU Utilization
How to Authorize Sub-Users to View Monitoring Data
White Paper
Security White Paper
Performance White Paper
Troubleshooting
Connection Issues
Performance Issues
API Documentation
History
Introduction
API Category
Making API Requests
Instance APIs
Multi-Availability Zone APIs
Other APIs
Audit APIs
Database Proxy APIs
Backup and Recovery APIs
Parameter Management APIs
Billing APIs
serverless APIs
Resource Package APIs
Account APIs
Performance Analysis APIs
Data Types
Error Codes
FAQs
Basic Concepts
Purchase and Billing
Compatibility and Format
Connection and Network
Features
Console Operations
Database and Table
Performance and Log
Database Audit
Between TDSQL-C for MySQL and TencentDB for MySQL
Service Agreement
Service Level Agreement
Terms of Service
TDSQL-C Policy
Privacy Policy
Data Privacy and Security Agreement
General References
Standards and Certifications
Glossary
Contact Us

Exchange Subpartition Template

PDF
Focus Mode
Font Size
Last updated: 2024-10-09 10:27:19

Feature Overview

The Exchange Subpartition Template feature allows you to exchange subpartition templates between two partitions. In this way, you can quickly change the partitioning policy of a partitioned table, without recreating a table or migrating data.

Supported Versions

The kernel version should be 3.1.15 or later for TXSQL 8.0.

Applicable Scenarios

It is applicable to scenarios where quick data exchange between tables is required.

Use Instructions

Syntax

ALTER TABLE pt EXCHANGE SUBPARTITION TEMPLATE p WITH TABLE nt WITH VALIDATION / WITHOUT VALIDATION

Example

-- Move data from hash_range_1 to hash_range_2 in s20240111.

CREATE TABLE hash_range_1(
id INT NOT NULL,
fname VARCHAR(30),
hired date NOT NULL DEFAULT '9999-12-31',
primary key (id, hired))
ENGINE=InnoDB DEFAULT CHARSET=utf8mb4
PARTITION BY LIST(murmurHashCodeAndMod(id,2))
SUBPARTITION BY RANGE(tdsql_day(hired))
SUBPARTITION TEMPLATE
(SUBPARTITION s20240111 VALUES LESS THAN (20240111),
SUBPARTITION s20240112 VALUES LESS THAN (20240112),
SUBPARTITION s20240113 VALUES LESS THAN (20240113))
(PARTITION p1 VALUES IN (0),
PARTITION p2 VALUES IN (1));

-- (hash_range_2 is identical to hash_range_1.)
CREATE TABLE hash_range_2(
id INT NOT NULL,
fname VARCHAR(30),
hired date NOT NULL DEFAULT '9999-12-31',
primary key (id, hired))
ENGINE=InnoDB DEFAULT CHARSET=utf8mb4
PARTITION BY LIST(murmurHashCodeAndMod(id,2))
SUBPARTITION BY RANGE(tdsql_day(hired))
SUBPARTITION TEMPLATE
(SUBPARTITION s20230111 VALUES LESS THAN (20240111),
SUBPARTITION s20230112 VALUES LESS THAN (20240112),
SUBPARTITION s20230113 VALUES LESS THAN (20240113))
(PARTITION p1 VALUES IN (0),
PARTITION p2 VALUES IN (1));

-- Create a temp table with the same partitions and table structure as hash_range_1.
CREATE TABLE temp(
id INT NOT NULL,
fname VARCHAR(30),
hired date NOT NULL DEFAULT '9999-12-31',
primary key (id, hired))
ENGINE=InnoDB DEFAULT CHARSET=utf8mb4
PARTITION BY LIST(murmurHashCodeAndMod(id,2))
(PARTITION p1 VALUES IN (0),
PARTITION p2 VALUES IN (1));

-- Syntax demonstration
-- Step 1: hash_range_1 --> temp
ALTER TABLE hash_range_1
EXCHANGE subpartition template s20240111
with table temp with validation;
-- Step 2: temp --> hash_range_2
ALTER TABLE hash_range_2
EXCHANGE subpartition template s20240111
with table temp with validation;

Use Limits

The pt and nt tables cannot have global indexes.
The pt and nt tables cannot have triggers and check constraints.
The partition type and subpartition type of the pt and nt tables only support RANGE and LIST.
The pt and nt tables should have the same definition of partitions.

Data Validation

As described in the official documentation, you can explicitly specify WITH VALIDATION to enable data validation or WITHOUT VALIDATION to disable data validation. Data validation is enabled by default.
Data validation is primarily used to verify whether the data in a partition of the nt table meets the definition of subpartitions in the corresponding partition of the pt table. In the example above, if data of the hired column in the p1 partition of the temp table meets tdsql_day(hired) >= 20240111, it does not meet the definition of subpartitions, SUBPARTITION s20240111 VALUES LESS THAN (20240111), so the data validation will fail.

Help and Support

Was this page helpful?

Help us improve! Rate your documentation experience in 5 mins.

Feedback