Frequently asked questions about the PolarDB engine - PolarDB

This topic provides answers to frequently asked questions about PolarDB for MySQL, , and .

General questions

Q: What is PolarDB?

A: PolarDB is a relational database cloud service deployed in data centers across more than 10 regions worldwide, offering an out-of-the-box experience. PolarDB supports three independent engines that are 100% compatible with MySQL, 100% compatible with PostgreSQL, and highly compatible with Oracle syntax. It provides a storage capacity of up to 200 TB. For more information, see What is PolarDB for MySQL Enterprise Edition?, , or
Q: Why is PolarDB a better choice than traditional databases?

A: Compared with traditional databases, PolarDB can store hundreds of terabytes of data and provides features such as high availability, high reliability, rapid elastic scaling, and lock-free backups. For more information, see Benefits, , or .
Q: When was PolarDB released and when did it become commercially available?

A: PolarDB was released for public preview in September 2017 and became commercially available in March 2018.
Q: What are clusters and nodes?

A: PolarDB Cluster Edition uses a multi-node architecture. A cluster contains one primary node and multiple read-only nodes. A single PolarDB cluster can be deployed across zones but not across regions. The service is managed and billed at the cluster level. For more information, see Terms, , or .
Q: What programming languages are supported?

A: PolarDB supports various programming languages, including Java, Python, PHP, Go, C, C++, .NET, and Node.js. Any programming language that supports native MySQL works with PolarDB for MySQL. For more information, visit the official MySQL website.
Q: What storage engines are supported?

A: PolarDB offers two product series. The supported storage engines vary based on the series.

PolarDB for MySQL Cluster Edition uses the InnoDB storage engine for all tables. When you create a table, PolarDB for MySQL automatically converts non-InnoDB engines, such as MyISAM, Memory, and CSV, to InnoDB. This ensures that even if your source tables do not use InnoDB, they can be successfully migrated to PolarDB for MySQL.
Q: Is PolarDB a distributed database?

A: Yes. PolarDB is a distributed storage cluster based on the Parallel Raft consensus protocol. Its compute engine consists of 1 to 16 compute nodes distributed across different servers. The cluster provides a maximum storage capacity of 200 TB and supports up to 88 CPU cores and 710 GB of memory. You can dynamically scale storage and compute resources online without affecting your workloads.
Q: After I purchase a PolarDB cluster, do I also need to purchase the PolarDB-X database middleware to implement sharding?

A: Yes.
Q: Does PolarDB support table partitioning?

A: Yes.
Q: Can I change the region of a PolarDB cluster after it is purchased?

A: No, you cannot change a cluster's region after purchase.
Q: Does PolarDB automatically include a partitioning mechanism?

A: Yes. PolarDB performs partitioning at the storage layer, which is transparent to users.
Q: How does a single-node cluster ensure service availability and data reliability?

A: A single-node cluster runs on a single compute node for specific purposes. Although it has only one node, a single-node cluster leverages technologies such as instant compute scheduling and distributed multi-replica storage to ensure high service availability and data reliability.
Q: How do I purchase a single-node PolarDB cluster?

A: The single-node product series is no longer available. However, you can create a cluster that functions as a single-node cluster by setting the number of read-only nodes to 0 when you purchase a PolarDB cluster.

Compatibility

Q: Is PolarDB compatible with MySQL Community Edition?

A: PolarDB for MySQL is 100% compatible with MySQL Community Edition.
Q: What transaction isolation levels are supported?

A: PolarDB for MySQL supports the READ-UNCOMMITTED, READ-COMMITTED (default), and REPEATABLE-READ isolation levels. The SERIALIZABLE isolation level is not supported.
Q: Is the output of SHOW PROCESSLIST different from that in MySQL Community Edition?

A: If you connect to the cluster by using the primary endpoint, the output is the same. If you use the cluster endpoint, the output is slightly different. You will find multiple records that have the same thread ID, each corresponding to a node in the PolarDB for MySQL cluster.
Q: Is the metadata lock (MDL) mechanism in PolarDB for MySQL different from that in MySQL Community Edition?

A: No, the MDL mechanism in PolarDB for MySQL is the same as that in MySQL Community Edition. However, because PolarDB for MySQL nodes use a shared-storage architecture, when you perform a DDL operation on the primary node, read-only nodes might read intermediate data from the DDL operation, leading to data inconsistency. To prevent this, PolarDB for MySQL synchronizes the exclusive MDLs involved in the DDL operation to the read-only nodes by using redo logs. This blocks other user threads on the read-only nodes from accessing the table during the DDL operation. In some cases, this can stall the DDL operation. You can run the SHOW PROCESSLIST command to view the execution status of the DDL operation. If the status is Wait for syncing with replicas, it indicates that a stall has occurred. For more information about how to resolve this issue, see View the DDL statement execution status and MDL status.
Q: Is the binlog format different from the native MySQL format?

A: No, there is no difference.
Q: Are the performance schema and sys schema supported?

A: Yes.
Q: Is the table statistics collection mechanism different from that in MySQL Community Edition?

A: The table statistics on the primary node of a PolarDB for MySQL cluster are consistent with those in MySQL Community Edition. To ensure consistent execution plans between the primary node and read-only nodes, each statistics update on the primary node is synchronized to the read-only nodes. In addition, you can run the ANALYZE TABLE command on read-only nodes to proactively load the latest statistics from the disk.
Q: Does PolarDB support XA transactions? Is it different from the official MySQL implementation?

A: Yes, PolarDB supports XA transactions, and there is no difference from the official MySQL implementation.
Q: Does PolarDB support full-text search?

A: Yes.

Note
When you use full-text indexes, there may be data latency in the index cache on read-only nodes. We recommend that you use the primary endpoint for both read and write operations that involve full-text indexes to ensure you retrieve the most up-to-date data.
Q: Is Percona Toolkit supported?

A: Yes, but we recommend that you use online DDL.
Q: Is gh-ost supported?

A: Yes, but we recommend that you use online DDL.

Billing

Q: What are the billable items of a PolarDB cluster?

A: The billable items include storage space, compute nodes, backups (with a free quota), and SQL Explorer (optional). For more information, see Billable items, , or .
Q: What does the charged storage space include?

A: The charged storage space includes database table files, index files, undo log files, redo log files, binlog files, slow log files, and a small number of system files. For more information, see Overview, , or .
Q: How am I charged if I add a read-only node?

A: The price of a read-only node is the same as the price of a primary node. For more information, see Pricing details of compute nodes, , or .
Q: If I add a read-only node, is the storage capacity doubled?

A: No. PolarDB uses an architecture that decouples compute and storage. When you purchase a read-only node, you are adding a compute resource, which does not increase the storage capacity.

Storage space is serverless, so you do not need to select a capacity when you make a purchase. It scales automatically as your data grows, and you are charged only for the amount of data that you use. Each cluster specification has a maximum storage capacity. To increase the storage limit, upgrade the cluster specifications, , or .
Q: How can I stop incurring charges for a pay-as-you-go cluster?

A: If you no longer need the cluster, you can release it. Releasing the cluster stops all future charges.
Q: Can I change the specifications of a cluster during a temporary upgrade?

A: During a temporary upgrade, while the cluster status is Running, you can manually upgrade the specifications. However, you cannot manually downgrade, enable auto-scaling, or add or remove nodes.
Q: What is the public bandwidth of PolarDB, and are there any associated costs?

A: PolarDB itself does not have a public bandwidth limit. The bandwidth primarily depends on the Server Load Balancer (SLB) service that you use. PolarDB does not charge for public connections.
Q: Why do I still see daily charges for a subscription cluster?

A: The billable items for PolarDB include compute nodes (primary and read-only nodes), storage space, data backups (charged only when the free quota is exceeded), SQL Explorer (optional), and Global Database Network (GDN) (optional). For more information, see Billable items. The subscription billing method requires you to prepay for the compute nodes when you create a cluster, but it does not cover the costs of storage space, data backups, and SQL Explorer. The fees for these pay-as-you-go items are deducted from your account on an hourly basis. Therefore, even with a subscription, you will still receive pay-as-you-go bills.
Q: Are there extra charges for one-click migration from ApsaraDB RDS for MySQL to PolarDB?

A: The one-click migration process is free of charge. You are charged only for the ApsaraDB RDS for MySQL instance and the PolarDB cluster itself.
Q: Why am I still charged for storage space after deleting data from a PolarDB table by using the DELETE command?

A: The DELETE command only marks rows for deletion. It does not release the table space.

Cluster access and read/write splitting

Q: How do I implement read/write splitting in PolarDB?

A: You only need to use the cluster endpoint in your application. Read/write splitting is then implemented based on the configured read/write mode. For more information, see Configure the database proxy, , or .
Q: What is the maximum number of read-only nodes supported in a PolarDB cluster?

A: PolarDB uses a distributed cluster architecture. A cluster contains one primary node and up to 15 read-only nodes. At least one read-only node is required to ensure high availability.
Q: Why are workloads unbalanced among multiple read-only nodes?

A: Workload imbalance among read-only nodes can be caused by a low number of connections to the nodes or by a custom cluster endpoint that does not include all read-only nodes in its configuration.
Q: What causes the load on the primary node to be high or low?

A: A high load on the primary node can be caused by several factors: direct connections to the primary endpoint, the primary node accepting read requests, a large number of transaction requests, high replication latency causing requests to be routed to the primary node, or a read-only node failure causing read requests to be routed to the primary node.

A low load on the primary node may occur if the option to accept read requests on the primary node is disabled.
Q: How can I reduce the load on the primary node?
A: You can use the following methods to reduce the load on the primary node:
- Connect to the PolarDB cluster by using the cluster endpoint. For more information, see Configure the database proxy, , or .
- If a large number of transactions cause high pressure on the primary node, you can enable the transaction splitting feature in the console to route some queries within transactions to read-only nodes. For more information, see Transaction splitting, , or .
- If high replication latency causes requests to be routed to the primary node, you can consider lowering the consistency level, for example, by using eventual consistency. For more information, see Consistency levels, , or .
- If the primary node accepts read requests, it may also lead to a high load. You can disable read requests on the primary node from the console to reduce the number of read requests routed to it. For more information, see Primary Node Accepts Read Requests.
Q: Why can't I read data immediately after it is inserted?
A: This issue may be caused by the consistency level configuration. The cluster endpoint of a PolarDB cluster supports the following consistency levels:
- Eventual consistency: This level does not guarantee that you can immediately read newly inserted data, regardless of whether the read is from the same session (connection) or a different one.
- Session consistency: This level guarantees that you can read data that was inserted within the same session.
- Global consistency: This level guarantees that you can read the latest data from both the same session and different sessions.
Note
Higher consistency levels lead to lower performance and greater pressure on the primary node. Choose the consistency level with caution. For most application scenarios, session consistency is sufficient to ensure normal business operations. For the few statements that require strong consistency, you can use the /*FORCE_MASTER*/ hint. For more information, see Consistency levels, , or .
Q: How can I force an SQL statement to run on the primary node?
A: When you use a cluster endpoint, you can prefix an SQL statement with /*FORCE_MASTER*/ or /*FORCE_SLAVE*/ to specify its routing direction. For more information, see HINT syntax, , or .
- The /*FORCE_MASTER*/ hint forces a request to be routed to the primary node. This can be used for read requests that require a higher level of consistency.
- The /*FORCE_SLAVE*/ hint forces a request to be routed to a read-only node. This can be used in scenarios where the PolarDB proxy routes special syntax to the primary node by default to ensure correctness, such as calls to stored procedures or the use of multi-statements.
Note
- Hints have the highest routing priority and are not constrained by consistency levels or transaction splitting. Evaluate the potential impact before use.
- Do not include statements that modify GUC parameters in a hint, such as /FORCE_SLAVE/ SET enable_hashjoin = off;. Such statements can lead to unexpected query results.
Q: Can I assign different endpoints to different services? Can these endpoints provide isolation between services?

A: Yes, you can create multiple custom endpoints for different services. If these endpoints use different underlying nodes, they provide isolation and do not affect each other. For information about how to create a custom endpoint, see Create a custom cluster endpoint, , or .
Q: If I have multiple read-only nodes, how can I create a dedicated single-node endpoint for one of them?

A: You can create a single-node endpoint only if the read/write mode of the cluster endpoint is set to Read Only and the cluster has three or more nodes. For detailed steps, see Configure the cluster endpoint, , or .

Warning
After you create a single-node endpoint, if the node fails, the endpoint may be unavailable for up to one hour. Do not use single-node endpoints in production environments.
Q: What is the maximum number of single-node endpoints I can create in a cluster?

A: If your cluster has three nodes, you can create a single-node endpoint for only one read-only node. If your cluster has four nodes, you can create separate single-node endpoints for two of the read-only nodes. This pattern continues as the number of nodes increases.
Q: I am only using the primary endpoint, but I see a load on the read-only nodes. Does the primary endpoint also support read/write splitting?

A: No, the primary endpoint does not support read/write splitting. It always connects only to the primary node. A small number of QPS on read-only nodes is normal and is not related to the primary endpoint.

Management and maintenance

Q: How can I add fields and indexes online?

A: You can use native online DDL or tools like pt-online-schema-change and gh-ost. We recommend that you use native online DDL operations.

Note
When you use pt-online-schema-change, do not use parameters related to master-slave detection, such as the recursion-method parameter. This is because the tool performs master-slave detection based on binlog replication. However, PolarDB uses physical replication and does not have binlog-based replication information.
Q: Is the bulk insert feature supported?

A: Yes.
Q: Is bulk insert supported if I write data only to the primary node? What is the maximum number of values I can insert at a time?

A: Yes, it is supported. The maximum number of values you can insert at a time is determined by the value of the max_allowed_packet parameter. For more information, see Replication and max_allowed_packet.
Q: Can I perform a bulk insert operation through the cluster endpoint?

A: Yes.
Q: Is there a replication delay between the primary node and the read-only nodes?

A: Yes, a millisecond-level delay exists between them.
Q: What can cause an increase in replication delay?
A: Replication delay can increase in the following situations:
- A high write load on the primary node generates an excessive amount of redo logs, which the read-only nodes cannot apply in time.
- A high load on a read-only node consumes resources that are required to apply redo logs.
- An I/O bottleneck slows down the process of reading and writing redo logs.
Q: If there is a replication delay, how can I ensure query consistency?

A: You can use a cluster endpoint and select an appropriate consistency level for it. The available consistency levels, from highest to lowest, are global consistency (strong consistency), session consistency, and eventual consistency. For more information, see Consistency levels, , or .
Q: Can a recovery point objective (RPO) of 0 be guaranteed in the event of a single node failure?

A: Yes.
Q: How are specification upgrades (for example, from 2 cores and 8 GB of memory to 4 cores and 16 GB) implemented in the backend? What is the impact on services?

A: PolarDB performs a rolling upgrade on both the proxy and database nodes to minimize service impact. An upgrade typically takes 10 to 15 minutes to complete, with a service impact of no more than 30 seconds. During this period, one to three transient connection errors may occur. For more information, see Manual scaling, , or .
Q: How long does it take to add a node? Does it affect my services?

A: Adding a node takes about five minutes and does not affect your services. For information about how to add a node, see Add a node, , or .

Note
After you add a read-only node, new read/write splitting connections will forward requests to that node. Read/write splitting connections established before the node was added will not forward requests to the new node. You must disconnect and reconnect them, for example, by restarting your application.
Q: How long does it take to upgrade to the latest revision version? Does it affect my services?

A: PolarDB uses a rolling upgrade method across multiple nodes to minimize the impact on your services. A version upgrade usually takes less than 30 minutes. During the upgrade, the database proxy or the DB kernel engine is restarted, which may cause transient connection errors. We recommend that you perform the upgrade during off-peak hours and ensure that your application has an automatic reconnection mechanism. For more information, see Minor version management, , or .
Q: How does automatic failover work?

A: PolarDB uses an Active-Active high-availability cluster architecture. Automatic failover occurs between the read-write primary node and the read-only nodes. The system automatically elects a new primary node. Each node in a PolarDB cluster has a failover priority, which determines its probability of being elected as the new primary node during a failover. If multiple nodes have the same priority, they have the same probability of being elected. For more information, see Automatic and manual primary/standby node switchover, , or .
Q: What permissions are required to terminate a connection in a PolarDB for MySQL cluster?

A: In MySQL, you need specific permissions to terminate a connection by using the KILL command. Specifically, to terminate the connection of another regular user, you must have the PROCESS permission.
Note
- Terminate your own connection: Any user can terminate their own connection without additional permissions.
- Terminate other sessions of the same user: You must have the PROCESS permission.
- Terminate connections of other regular users: In PolarDB for MySQL, high-privilege accounts should use the KILL command with caution.
Q: My running log shows an [ERROR] InnoDB: fil_space_extend space_name:xxx error. Does this affect my current services?

A: No, this does not affect your services. This log entry indicates that after the file size is extended on the read-write node of the PolarDB cluster, the read-only node synchronizes the file size information in its memory. In clusters that run MySQL 5.7, the log level for this message is not adjusted and remains at ERROR. On read-only nodes, you can consider this an INFO level message. It does not affect your services.
Q: What is the architecture of the database proxy? Does it have a failover mechanism? How is its high availability ensured?

A: The database proxy uses a dual-node high-availability architecture, distributing traffic evenly between the two proxy nodes. The system continuously checks the health status of the proxy nodes. If a node failure is detected, the system proactively disconnects the connections on that node, and the remaining healthy node automatically takes over all traffic to ensure uninterrupted service. At the same time, the system automatically rebuilds and restores the failed proxy node. This process is typically completed in about 2 minutes. During this time, the database cluster remains accessible.

In rare cases, connections to a failed node may not be disconnected in a timely manner and become unresponsive. To handle such situations, configure appropriate timeout policies on the client side, such as JDBC's socketTimeout and connectTimeout. This allows the application layer to promptly detect and terminate suspended connections, further improving the system's fault tolerance and response efficiency.
Q: How do I view the error logs for a PolarDB for MySQL cluster?

A: Go to the PolarDB console. On the cluster details page, go to Diagnostics and Optimization > Log Management in the left-side navigation pane. On the Running Logs tab, you can view the error logs.

Q: Does PolarDB for MySQL automatically create a hidden primary key for a table without a primary key?

A: Yes. By default, PolarDB for MySQL creates an implicit primary key for any table without a primary key.

View the implicit primary key

You can log on to the cluster and run SET show_ipk_info = 1. Then, you can view the key by running the SHOW CREATE TABLE command.

-- Set the parameter to display the implicit primary key.
SET show_ipk_info = 1;
-- View the table schema.
SHOW CREATE TABLE t;

View the table schema. The __#alibaba_rds_row_id#__ column is the implicit primary key.

+-------+------------------------------------------------------------------------------------------------------------+
| Table | Create Table                                                                                               |
+-------+------------------------------------------------------------------------------------------------------------+
| t     | CREATE TABLE `t` (
  `id` int(11) DEFAULT NULL,
  `__#alibaba_rds_row_id#__` bigint(20) NOT NULL AUTO_INCREMENT COMMENT 'Implicit Primary Key by RDS',
  KEY `__#alibaba_rds_row_id#__` (`__#alibaba_rds_row_id#__`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 |
+-------+------------------------------------------------------------------------------------------------------------+

Q: Why do I see a Lock wait timeout exceeded error and find a transaction with a trx_mysql_thread_id of 0?
A: If your application encounters a service interruption due to lock contention when interacting with PolarDB for MySQL, and you observe a thread with a thread_id of 0 in the database, it usually means that an incomplete XA transaction is holding a lock. This section guides you on how to resolve this issue.
Symptoms
- Your application or client receives the ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction error when connecting to the database.
- After logging in to the database and running SELECT * FROM information_schema.innodb_trx;, you find a long-running transaction in the output where the value of the trx_mysql_thread_id field is 0. This transaction is blocking other transactions.
```
MySQL xxx > select * from information_schema.innodb_trx\G
*************************** 1. row ***************************
                    trx_id: 3317965
                 trx_state: RUNNING
               trx_started: 2025-12-23 11:29:17
      trx_requested_lock_id: NULL
          trx_wait_started: NULL
                trx_weight: 3
       trx_mysql_thread_id: 0
                 trx_query: NULL
```
Cause

In the InnoDB storage engine, a trx_mysql_thread_id of 0 is an indicator of an XA transaction. This issue typically occurs during the two-phase commit process of an XA transaction. After a transaction successfully executes XA PREPARE and enters the prepared state, if the external transaction manager fails to issue an XA COMMIT or XA ROLLBACK command due to network issues, application exceptions, or other reasons, the transaction becomes stuck in the prepared state. This stuck transaction continues to hold locks, blocking other transactions and eventually causing a lock wait timeout.
Solution

You need to manually intervene to either commit or roll back the prepared XA transaction based on your business requirements.
1. Find uncommitted XA transactions: Run the XA RECOVER; command to query for uncommitted XA transactions. Record the values of the formatID, gtrid_length, bqual_length, and data fields for the target transaction. This information is crucial for the next step.
```
MySQL [xxx]> xa recover;
+----------+---------------+--------------+----------------------------+
| formatID | gtrid_length  | bqual_length | data                       |
+----------+---------------+--------------+----------------------------+
|    10000 |            11 |           14 | 192.168.1.2_app_name_test  |
+----------+---------------+--------------+----------------------------+
```
2. Manually commit or roll back the XA transaction: After you find the XA transactions, you can choose to either commit or roll them back based on your business needs.
  1. Obtain the unique identifier (xid) of the XA transaction: An xid consists of three parts: gtrid, bqual, and formatID. You need to construct the xid based on the information obtained in the previous step.
    
    gtrid: A string with a length specified by gtrid_length, extracted from the beginning of the data field.
    
    bqual: A string with a length specified by bqual_length, extracted from the end of the data field.
    
    formatID: The value of the formatID field.
    
    Based on the example in the previous step, you can construct the three parts of the xid. You can use SUBSTRING to split the data field.
    SELECT SUBSTRING('192.168.1.2_app_name_test',1,11) AS gtrid, SUBSTRING('192.168.1.2_app_name_test',-14) AS bqual; +-------------+----------------+ | gtrid | bqual | +-------------+----------------+ | 192.168.1.2 | _app_name_test | +-------------+----------------+
    
    gtrid: '192.168.1.2'
    
    bqual: '_app_name_test'
    
    formatID: 10000
  2. Commit or roll back the XA transaction: Manually committing or rolling back an XA transaction can result in a final state that differs from the original intent of the transaction coordinator, which may lead to data inconsistencies. Before you run the following commands, make sure that you fully understand the business context of the transaction and confirm that it is safe to proceed.
    
    Commit: If you determine that the transaction should be committed, run the following command:
    XA COMMIT '192.168.1.2', '_app_name_test', 10000;
    
    Roll back: If you determine that the transaction should be rolled back, run the following command:
    XA ROLLBACK '192.168.1.2', '_app_name_test', 10000;
3. After the command is successfully run, the locks held by the uncommitted XA transaction are released, and the database service returns to normal.
For more information about XA transaction syntax, see the official MySQL documentation on XA Transactions.
Why do different PolarDB for MySQL 8.0 clusters show inconsistent error handling behavior when comparing invalid date and time types?
- Problem description: PolarDB for MySQL 8.0 clusters are available in two versions, MySQL 8.0.1 and MySQL 8.0.2, which are fully compatible with MySQL 8.0.13 and MySQL 8.0.18, respectively. However, these two versions handle invalid date and time types inconsistently.
  
  Specifically, when a string literal is compared with a time-type value, an attempt is made to convert the string to a time type. If the string is an invalid date, the conversion fails. The behavior upon conversion failure differs between the two versions. The 8.0.13-compatible version only issues a WARNING, whereas the 8.0.18-compatible version returns an ER_WRONG_VALUE error. As a result, when comparing invalid dates and time fields, these two versions of PolarDB for MySQL clusters exhibit inconsistent error-reporting behavior.
- Solution: To ensure consistent SQL execution results (either all succeeding or all failing), multiple PolarDB for MySQL clusters should use the same major kernel version, either all MySQL 8.0.1 or all MySQL 8.0.2.

Backup and recovery

Q: How does PolarDB back up data?

A: PolarDB uses snapshots to back up data. For more information, see Backup method 1: Automatic backup and Backup method 2: Manual backup, , or .
Q: How fast can a database be restored?

A: Restoring a database from a backup set (snapshot) or cloning a database takes about 40 minutes per TB. If you restore data to a specific point in time, the time required to apply redo logs is also included. Applying redo logs takes about 20 to 70 seconds per GB. The total restoration time is the sum of these two parts.

Performance and capacity

Q: Why is the performance of PolarDB for MySQL not significantly better than that of ApsaraDB RDS for MySQL?
A: To get an accurate performance comparison between PolarDB for MySQL and ApsaraDB RDS for MySQL, consider the following points.
- Use a PolarDB for MySQL cluster and an ApsaraDB RDS for MySQL instance that have the same specifications.
- Use a PolarDB for MySQL cluster and an ApsaraDB RDS for MySQL instance that run the same MySQL version.
  
  The implementation mechanisms vary by version. For example, MySQL 8.0 is optimized for multi-core CPUs with abstracted threads like Log_writer, log_fluser, log_checkpoint, and log_write_notifier. However, its performance on systems with fewer CPU cores is lower than that of MySQL 5.6 or 5.7. We do not recommend comparing PolarDB for MySQL 5.6 with ApsaraDB RDS for MySQL 5.7 or 8.0 because the optimizer in MySQL 5.6 is older and less efficient than those in newer versions.
- Simulate online pressure scenarios for realistic performance comparisons or use sysbench for testing. The data obtained from these methods is closer to real-world online scenarios.
- When comparing read performance, we do not recommend using single SQL statements.
  
  Because PolarDB has a decoupled compute and storage architecture, single statements are affected by network latency, which can result in lower read performance compared to ApsaraDB RDS for MySQL. In online databases, the cache hit rate is typically above 99%. Only the first read operation involves an I/O call, which reduces read performance. Subsequent data is retrieved from the buffer pool, which does not require I/O calls. Therefore, the performance is the same.
- When comparing write performance, we also do not recommend using single SQL statements. We recommend that you simulate an online environment for stress testing.
  
  To compare the performance with ApsaraDB RDS for MySQL, use a PolarDB cluster with a primary node and a read-only node, and compare it with an ApsaraDB RDS for MySQL instance that has a primary instance and a semi-synchronous read-only instance. This is because the PolarDB architecture uses a quorum mechanism for data writes by default. This means a write operation is considered successful if it is written to a majority of the three replicas (two or more). PolarDB provides data redundancy at the storage layer and ensures strong consistency and high reliability with three replicas. Therefore, a more reasonable comparison is to use semi-synchronous replication on ApsaraDB RDS for MySQL, not asynchronous replication.
For a performance comparison between PolarDB for MySQL and ApsaraDB RDS for MySQL, see Performance comparison: PolarDB for MySQL vs. ApsaraDB RDS for MySQL.
Q: What is the maximum number of tables? At what point might performance degrade?

A: The maximum number of tables is limited by the number of files. For more information, see Limits, , or .
Q: Can table partitioning improve the query performance of PolarDB?

A: Generally, yes. If a query can be scoped to a specific partition, performance can be improved.
Q: Can I create 10,000 databases in a PolarDB cluster? What is the maximum number of databases?

A: Yes, you can create 10,000 databases in a PolarDB cluster. The maximum number of databases is limited by the number of files. For more information, see Limits, , or .
Q: Is the maximum number of connections related to the number of read-only nodes? Can I increase the maximum number of connections by adding read-only nodes?

A: No, the number of read-only nodes is not related to the maximum number of connections. The maximum number of connections in PolarDB is determined by the node specifications. For more information, see Limits. If you need more connections, you must upgrade specifications.
Q: How are IOPS limited and isolated? Can I/O contention occur between multiple PolarDB cluster nodes?

A: In a PolarDB cluster, each node has an IOPS limit based on its specifications. The IOPS of each node is isolated and does not affect other nodes.
Q: Can the performance of a slow read-only node affect the primary node?

A: Yes. If a read-only node has a high load or increased replication delay, it may slightly increase the memory consumption of the primary node.
Q: What is the performance impact of enabling binlog?

A: Enabling binlog does not affect query (SELECT) performance, but it does affect write operations (INSERT, UPDATE, DELETE). In a database with a balanced read-write workload, enabling binlog typically impacts performance by less than 10%.
Q: What is the performance impact of enabling SQL Explorer?

A: There is no impact on performance.
Q: What high-speed network protocol does PolarDB use?

A: PolarDB uses dual 25 Gbps RDMA technology for communication between its compute and storage nodes, and between its storage data replicas. This provides powerful I/O performance with low latency and high throughput.
Q: What is the maximum bandwidth for external connections to PolarDB?

A: The maximum bandwidth for external connections to PolarDB is 10 Gbit/s.

Large tables

Q: What are the advantages of storing large tables in PolarDB for MySQL compared to traditional databases that use local disks?

A: In PolarDB for MySQL, a single table is physically split and stored across multiple storage servers. As a result, I/O operations on the table are distributed among multiple storage disks. The overall I/O read throughput, though not the I/O latency, is much better than that of centralized databases that use local disks.
Q: How can I optimize large tables?

A: We recommend that you use partitioned tables.
Q: When is it appropriate to use partitioned tables?

A: Partitioned tables are suitable for scenarios where you need to prune large tables to control the amount of data accessed by queries, and you want this pruning to be transparent to your business code without requiring modifications. For example, you can use partitioned tables to periodically clean up historical business data, such as by deleting the oldest month's partition and creating a new one for the next month to retain only the last six months of data.
Q: What is the best way to copy a very large table (for example, copying table A to table B) within the same PolarDB for MySQL database?
A: You can use the following SQL statement to copy the table directly:
```
CREATE TABLE B AS SELECT * FROM A;
```

Stability

Q: Can I optimize PHP short-lived connections in high-concurrency scenarios?

A: Yes. You can optimize them by enabling the session-level connection pool in the cluster endpoint settings. For more information, see Configure the cluster endpoint, , or .
Q: How can I prevent a few inefficient SQL queries from degrading the entire database?

A: If your PolarDB for MySQL cluster is version 5.6 or 8.0, you can use the Concurrency control feature to apply rate limiting to specific statements.
Q: Does PolarDB support an idle session timeout?

A: Yes. You can customize the timeout for idle sessions by modifying the wait_timeout parameter. For detailed steps, see Specify cluster and node parameters.

Q: How do I find slow SQL queries?

A: You can find slow SQL queries in the following two ways:

Query slow SQL logs directly in the console. For more information, see Slow SQL query.

Connect to the database cluster and run SHOW PROCESSLIST; to identify queries that are taking too long to execute. For more information about how to connect to a database cluster, see Connect to a database cluster. Run the SHOW PROCESSLIST command to view the current process list. In the example, the query SELECT SLEEP(600) with Id 33554499 has been running for 250 seconds, which is a slow SQL query.

mysql> show processlist;
+----------+------+-------------------------------+------+---------+------+------------+--------------------+
| Id       | User | Host                          | db   | Command | Time | State      | Info               |
+----------+------+-------------------------------+------+---------+------+------------+--------------------+
| 33554490 | acc  | xxx:19358                     | NULL | Query   |    0 | starting   | show processlist   |
| 33554499 | acc  | xxx                           | NULL | Query   |  250 | User sleep | select sleep(600)  |
| 33554499 | acc  | xxx                           | NULL | Sleep   |  253 |            | NULL               |
+----------+------+-------------------------------+------+---------+------+------------+--------------------+
3 rows in set, 13312 warnings (0.00 sec)

Q: How do I terminate a slow SQL query?
A: After you identify a slow SQL query, you can find its ID and then run KILL <Id> to terminate it.
```
mysql> KILL 33554499;
Query OK, 0 rows affected (0.01 sec)
```

Data lifecycle management

Q: How does a PolarDB for MySQL cluster archive hot and warm data as cold data?

A: A PolarDB for MySQL cluster can archive hot data from the InnoDB engine and warm data from the X-Engine in PolarStore to Object Storage Service (OSS) as cold data in the CSV or ORC format by using DDL policies. This archiving effectively releases storage space on PolarStore and reduces the overall database storage costs. For more information, see Manually archive cold data.
Q: Does a PolarDB for MySQL cluster support automatic separation and archiving of hot, warm, and cold data? How is this implemented?

A: PolarDB for MySQL supports the automatic separation and archiving of hot, warm, and cold data. By specifying a DLM policy, you can automatically archive data from PolarStore to low-cost OSS storage to reduce and optimize database storage costs. For more information, see Automatically archive cold data.