PolarDB-X 2.0 transparent distribution provides four working modes. Choose the mode that matches your database scale, SQL complexity, and performance requirements.
Identify your scenario
Large existing business
Your system falls into this category if:
You have 10 or more databases, or 100 or more tables, with complex JOIN operations across databases and tables.
Existing SQL statements are complex and cannot be modified.
A standalone database is hitting CPU or I/O limits, causing slower query response time (RT).
Typical example: a hospital or medical company running a business system for over ten years.
Mixed existing and new business
Your system falls into this category if:
You have 2 or more databases, or 10 or more tables for existing workloads, with complex JOIN operations across databases and tables.
Most existing SQL statements cannot be modified.
New features require large tables, and a standalone database cannot keep up with data growth due to CPU, I/O, or disk limits.
Typical example: an order management system expanding to new features after years of operation.
New business based on standalone MySQL
Your system falls into this category if:
You have fewer than 2 databases, or fewer than 10 tables.
The business is launching soon and iteration speed matters.
You expect significant data growth and need scalability from the start.
The databases and SQL statements for the new business can be modified and optimized.
Typical example: a photography company launching a new business system.
High-performance and high-throughput business
Your system falls into this category if:
Your database and table count is small, but data volume is large and concurrency is high.
Your business is sensitive to query RT.
You need linear scalability to handle tens of thousands or even hundreds of thousands of queries per second (QPS).
Typical example: the core transaction system of a large e-commerce company.
Choose a working mode
The following table maps each scenario to its recommended working mode and expected outcomes.
| Scenario | Recommended working mode | What it gives you |
|---|---|---|
| Large existing business | Non-partitioned table sharding | Non-partitioned tables are distributed across data nodes (DNs), breaking through the resource limits of a standalone database and enabling load balancing and improved performance. SQL compatibility with existing statements is maximized, so query performance stays nearly unchanged. |
| Mixed existing and new business | Non-partitioned table sharding + manual partitioning | Same SQL compatibility as above for existing workloads, breaking through standalone database resource limits through load balancing and improved performance. For large tables in new workloads, apply manual partitioning to resolve storage scalability while maintaining read and write performance. |
| New business based on standalone MySQL | Automatic partitioning | All tables are automatically partitioned, breaking through standalone database limits. All indexes are global indexes by default, ensuring basic query performance on non-primary key columns. |
| High-performance and high-throughput business | Manual partitioning | Manually select the optimal partitioning strategy for each table based on your query patterns. Modify SQL statements to achieve linear scalability at high concurrency. |
Apply manual partitioning to specific tables
After setting the working mode to non-partitioned table sharding, run the following statement to manually partition a large table:
ALTER TABLE <table_name> PARTITION BY KEY(<column_name>) locality='';For details on the locality parameter, see Locality.