FAQ about PolarDB for MySQL - PolarDB - Alibaba Cloud Documentation Center

This topic providesPolarDB for MySQL frequently asked questions and answers.

General questions

Q: What is PolarDB for MySQL?
A: PolarDB for MySQL is a cloud-based relational database service. It is deployed in data centers in more than 10 regions worldwide and provides ready-to-use online database services.PolarDB supports three independent engines: 100% compatible with MySQL, 100% compatible with PostgreSQL, and highly compatible with Oracle syntax. The storage capacity can be up to 1 PB. For details, see What is PolarDB for MySQL Enterprise Edition?.
Q: Why is PolarDB better than traditional databases?
A: Compared with traditional databases, PolarDB supports massive data storage of hundreds of PB and provides features such as high availability and high reliability, fast elastic scaling, and lock-free backup. For details, see What is PolarDB for MySQL Enterprise Edition?.
Q: When was PolarDB released? When did it become commercially available?
A: It was released for public preview in September 2017 and became commercially available in March 2018.
Q: What are clusters and nodes?
A: PolarDB for MySQL uses a multi-node cluster architecture. Each cluster contains one primary node and multiple read-only nodes. A single PolarDB for MySQL cluster can span zones but cannot span regions. Clusters are managed and billed at the cluster level. For details, see Glossary.
Q: What programming languages are supported?
A: PolarDB for MySQL supports programming languages such as Java, Python, PHP, Golang, C, C++,.NET, and Node.js. Any programming language that supports native MySQL can directly use PolarDB for MySQL. For details, see the official MySQL website.
Q: What storage engines are supported?
A: PolarDB for MySQL supports two product series. The storage engines supported by each series are as follows:
PolarDB for MySQLPolarDB uses the InnoDB storage engine for all tables. When you create a table, non-InnoDB engines such as MyISAM, Memory, and CSV are automatically converted to InnoDB. Therefore, even if your existing tables do not use InnoDB, they can still be migrated to
Q: Can I create self-managed secondary instances, and what implementation is recommended?
A: Yes. After you enable binlog, you can synchronize PolarDB for MySQL to other MySQL databases to form a primary-secondary architecture. For easier maintenance, we recommend that you use Data Transmission Service (DTS). For information about how to use DTS for synchronization, see Synchronize data from a PolarDB for MySQL cluster to an ApsaraDB RDS for MySQL instance.
Q: Is PolarDB for MySQL a distributed database?
A: Yes. PolarDB for MySQL is a distributed storage cluster based on the Parallel Raft consensus protocol. Its compute engine consists of multiple compute nodes distributed across different servers. The storage capacity can be up to 1 PB, and it supports up to 120 CPU cores and 920 GB of memory. You can dynamically scale storage and compute resources online without affecting normal workloads.
Q: Does PolarDB for MySQL support table partitioning?
A: Yes.
Q: Can I change the region of a PolarDB for MySQL cluster after I purchase it?
A: You cannot change the region of a cluster after you purchase it.
Q: Does PolarDB for MySQL automatically include a partitioning mechanism?
A: PolarDB for MySQL performs partitioning at the storage layer, which is transparent and imperceptible to users.
Q: When I run an SQL statement in DMS, the following error occurs. What do I do? When the SQL statement is run, an error message appears on the page: Lock wait timeout exceeded; try restarting transaction.
A: This error is caused by a lock wait timeout. The specific cause is that an uncommitted transaction blocks the current session. We recommend that you log on to the DMS console again, create a new connection session, and run the SQL command again.
Q: How does the single-node series ensure service availability and data reliability?
A: The single-node series is a database product built on a single compute node for specific purposes. Although it has only one node, it can still ensure high service availability and high data reliability by using technologies such as second-level compute scheduling and distributed multi-replica storage.
Q: How do I purchase a single-node PolarDB for MySQL cluster?
A: The single-node product series has been discontinued. However, when you purchase a cluster, you can set the number of read-only nodes to 0 to purchase a single-node PolarDB for MySQL cluster.

Compatibility

Q: Is it compatible with MySQL Community Edition?
A: PolarDB for MySQL is 100% compatible with MySQL Community Edition.
Q: Which transaction isolation levels are supported?
A: PolarDB for MySQL supports three isolation levels: READ_UNCOMMITTED, READ_COMMITTED (default), and REPEATABLE_READ. The SERIALIZABLE isolation level is not supported.
Q: Does SHOW PROCESSLIST differ from MySQL Community Edition?
A: If you query through the primary endpoint, there is no difference. If you query through the cluster endpoint, there is a slight difference: multiple records with the same Thread ID appear, one for each node in the PolarDB for MySQL cluster.
Q: Does the PolarDB for MySQL MDL locking mechanism differ from MySQL Community Edition?
A: The MDL mechanism of PolarDB for MySQL is the same as that of MySQL Community Edition. However, because the database nodes of PolarDB for MySQL use a shared-storage architecture, a read-only node may query intermediate data of a DDL operation while the primary node runs the operation, which causes data inconsistency. Therefore, PolarDB for MySQL synchronizes the exclusive MDL locks involved in the DDL operation to the read-only nodes through redo logs, to prevent other user threads on the read-only nodes from accessing table data while the DDL operation is in progress. In certain situations, this may block the DDL operation. You can run the show processlist command to check the execution status of the DDL operation. If the execution status is Wait for syncing with replicas, the preceding situation has occurred. For solutions, see View the DDL statement execution status and MDL status.
Q: Does the binlog format differ from the native MySQL format?
A: There is no difference.
Q: Are performance schema and sys schema supported?
A: Yes.
Q: Does table statistics collection differ from MySQL Community Edition?
A: The table statistics on the primary node of PolarDB for MySQL are the same as those in MySQL Community Edition. To keep the execution plans of the primary node and the read-only nodes consistent, the primary node synchronizes the statistics to the read-only nodes each time it updates them. In addition, a read-only node can run the ANALYZE TABLE operation to proactively load the latest statistics from disk.
Q: Does PolarDB for MySQL support XA transactions, and does it differ from official MySQL?
A: Yes, they are supported, and there is no difference.
Q: Does PolarDB for MySQL support full-text indexes?
A: Yes. However, when you use full-text indexes, read-only nodes have a certain delay in cached index data. We recommend that you use the primary endpoint for all operations that read or write full-text indexes so that you read the latest data. In addition, PolarDB for MySQL columnstore indexes (IMCI) also support building and using full-text indexes. By configuring inverted indexes through column-level COMMENT, you can use the MATCH...AGAINST syntax or the automatically optimized LIKE query to implement millisecond-level fuzzy retrieval. This feature is based on the inverted index and term matching mechanism of IMCI. For details, see An analysis of the full-text search feature in IMCI.
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.
Q: Are index comments supported?
A: Yes. PolarDB for MySQL is 100% compatible with MySQL, so the current MySQL 5.6, MySQL 5.7, and MySQL 8.0 kernels all support index comments. You can use SHOW CREATE TABLE <table_name>; to view the specific index comment information. If you cannot query the index comment information, check whether a comment was added to the index, or whether operations such as synchronization or migration cleared the comment.

Billing

Q: What fees does PolarDB for MySQL include?
A: The fees cover compute nodes, storage space, backup (with a free quota), and SQL Explorer (optional). For details, see Billable items.
Q: What does the billed storage space include?
A: It 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 details, see Storage space.
Q: If I add a read-only node, how is it billed?
A: A read-only node is priced the same as the primary node. See Compute nodes.
Q: If I add a read-only node, does the storage capacity double?
A: PolarDB for MySQL uses an architecture that separates computing from storage. The read-only node that you purchase is a compute resource, so the storage capacity does not increase. PSL4/PSL5 storage types use a serverless approach. You do not need to select a capacity when you purchase a cluster. The storage automatically scales online as your data grows, and you are charged only for the actual amount of data. Each cluster specification has a corresponding maximum storage capacity. To increase the storage capacity limit, Manual specification change.
Q: How do I release a subscription PolarDB for MySQL cluster?
A: A subscription cluster cannot be released directly. You must unsubscribe from it. For details, see Unsubscription rules.
Q: How do I stop a pay-as-you-go cluster from incurring fees?
A: If you confirm that you no longer use the cluster, you can Release a cluster. After the cluster is released, it no longer incurs fees.
Q: Can I still change the specifications of a cluster during a temporary upgrade?
A: During a temporary upgrade (when the cluster is running), Manual specification change is supported, but manual downgrade, Add or remove nodes, Temporarily add nodes, and unsubscribing from the cluster are not supported. For details, see Auto scaling.Temporary upgrade.
Q: What is the public bandwidth of PolarDB for MySQL? Am I charged for it?
A: PolarDB for MySQL itself has no public bandwidth limit. The bandwidth mainly depends on the SLB service that you use. Public connections to PolarDB for MySQL are free.
Q: Why does a subscription cluster still incur fees every day?
A: The billable items of PolarDB for MySQL mainly include compute nodes (primary nodes and read-only nodes), storage space, backup storage (charged only when the free quota is exceeded), SQL Explorer (optional), and cold data archive (optional). For details, see Billable items. Subscription means that you prepay the compute node fees when you create a database cluster. However, fees for storage space (subscription or pay-as-you-go depending on the purchase), backup storage, SQL Explorer, and cold data archive are not included. While you use the database, storage fees are deducted from your account hourly based on the storage space that the cluster occupies. Therefore, even under the subscription billing method, pay-as-you-go bills are still generated.
Q: Am I charged extra for the one-click migration from RDS to PolarDB for MySQL?
A: You are charged for DTS data synchronization tasks, the RDS instance, and the PolarDB cluster itself during the one-click migration. For details, see Billing.
Q: Why am I still charged for storage space after PolarDB for MySQL table data is deleted by using delete?
A: delete only marks the table as deleted. It does not release the tablespace.

Cluster access (read/write splitting)

Q: How do I implement read/write splitting for PolarDB for MySQL?
A: Use the cluster endpoint in your application. Read/write splitting is then implemented based on the configured read/write mode. For details, see Configure the database proxy.
Q: What is the maximum number of read-only nodes that a PolarDB for MySQL cluster supports?
A: PolarDB for MySQL uses a distributed cluster architecture. Enterprise Edition clusters support up to 15 read-only nodes, and Standard Edition clusters support up to 7 read-only nodes. We recommend at least one read-only node to ensure high availability.
Q: Why is the load unbalanced across multiple read-only nodes?
A: The load can be unbalanced across read-only nodes for various reasons, such as a read-only node having few connections or a read-only node not being included when the custom cluster endpoint was configured.
Q: What causes a high or low load on the primary node?
A: Causes of a high load on the primary node include direct connections to the primary endpoint, the primary database accepting read requests, a large number of transaction requests, high replication latency causing requests to be routed to the primary database, and abnormal read-only nodes causing read requests to be routed to the primary database.
In contrast, a low load on the primary node may result from turning on the option that prevents the primary database from accepting read requests.
Q: How do I reduce the load on the primary node?
A: You can reduce the load on the primary node in the following ways:
- Use the cluster endpoint to connect to the PolarDB for MySQL cluster. For details, see Configure the database proxy.
- If a large number of transactions put pressure on the primary node, you can turn on transaction splitting in the console to route some of the queries in a transaction to read-only nodes. For details, see Transaction splitting.
- If requests are routed to the primary database because of replication latency, consider lowering the consistency level (for example, use eventual consistency). For details, see Consistency levels.
- If the primary database accepts read requests, the load on the primary database may also be high. You can turn on the feature that prevents the primary database from accepting read requests in the console to reduce the read requests routed to the primary database. For details, see Primary node accepts read requests.
Q: Why can't I read the data that was just inserted?
A: This issue may be caused by the consistency level configuration. The cluster endpoint of PolarDB for MySQL supports the following consistency levels:
- Eventual consistency: Whether within the same session (connection) or across different sessions, eventual consistency does not guarantee that the data just inserted can be read immediately.
- Session consistency: Data inserted within the same session can always be read.
- Global consistency: Both the same session and different sessions are guaranteed to read the latest data.
Note
The higher the consistency level, the worse the performance and the heavier the load on the primary node. Choose the consistency level with caution. For most use cases, session consistency ensures that your workloads run as expected. For the few statements that require strong consistency, you can use Hint /* FORCE_MASTER */. For details, see Consistency levels.
Q: How do I force an SQL statement to run on the primary node?
A: When you use the cluster endpoint, add /* FORCE_MASTER */ or /* FORCE_SLAVE */ before an SQL statement to force the routing direction of the statement. For details, see Use HINT syntax.
- /* FORCE_MASTER */
- /* FORCE_SLAVE */PolarDB forces the request to be routed to a read-only database. You can use this hint for the few scenarios in which the
Note
- Hints have the highest routing priority and are not constrained by consistency levels or transaction splitting. Evaluate the impact before you use hints.
- Do not include statements that modify GUC parameters in hint statements. For example, /*FORCE_SLAVE*/ set enable_hashjoin = off; and similar statements may cause unexpected query results.
Q: Can I assign different endpoints to different workloads? Can isolation be achieved between different endpoints?
A: You can create multiple custom endpoints for different workloads. If the underlying nodes are different, the custom endpoints are isolated from each other and do not affect each other. For information about how to create a custom endpoint, see Manage endpoints.
Q: If there are multiple read-only nodes, how do I create a single-node endpoint for a specific read-only node?
A: Single-node endpoints can be created only when the read/write mode of the cluster endpoint is read-only. For detailed steps, see Configure the database proxy.
Warning
After you create a single-node endpoint, the endpoint may be unavailable for up to 1 hour if the node fails. Do not use single-node endpoints in production environments.
Q: I use only the primary endpoint, but I found that the read-only nodes also have load. Does the primary endpoint support read/write splitting?
A: The primary endpoint does not support read/write splitting and always connects only to the primary node. A small amount of QPS on the read-only nodes is normal and is unrelated to the primary endpoint.

Management and maintenance

Q: How do I add columns and indexes online?
A: You can use the built-in online DDL feature or tools such as pt-osc and gh-ost. We recommend that you use the built-in online DDL feature.
Note
When you use the pt-osc tool, do not use the parameters that configure primary/secondary detection, such as the recursion-method parameter. The pt-osc tool performs primary/secondary detection based on binlog replication, but PolarDB for MySQL uses physical replication internally and has no binlog-based replication information.
Q: Is the bulk insert feature supported?
A: Yes.
Q: If data is written only to the write-only node, is bulk insert supported? What is the maximum number of values that can be inserted at a time?
A: Yes. The maximum number of values supported at a time is determined by the value of the max_allowed_packet parameter. For details, see Replication and max_allowed_packet.
Q: Can I perform bulk insert operations by using the cluster endpoint?
A: Yes.
Q: Is there replication latency between the primary node (primary) and the read-only nodes (secondary)?
A: Yes. There is a millisecond-level latency between them.
Q: In what situations does replication latency increase?
A: Replication latency increases in the following situations:
- The write load on the primary node is high and generates too many redo logs for the read-only nodes to apply in time.
- The load on the read-only nodes is too high, which preempts too many resources that would otherwise be used to apply redo logs.
- An I/O bottleneck occurs, which causes redo logs to be read and written too slowly.
Q: How do I ensure query consistency when replication latency exists?
A: You can use the cluster endpoint and select an appropriate consistency level for it. Currently, the consistency levels from highest to lowest are global consistency (strong consistency), session consistency, and eventual consistency. For details, see Consistency levels.
Q: Can an RPO of 0 be guaranteed if a single node fails?
A: Yes.
Q: How does the backend implement a specification upgrade (for example, from 2 cores and 8 GB to 4 cores and 16 GB)? What impact does the upgrade have on my workloads?
A: Specification changes for a PolarDB for MySQL cluster trigger node restarts, which cause transient connection interruptions and brief performance fluctuations. The impact depends on whether the cluster has hot standby switchover capability and the binlog status. For details, see Impact assessment.
Q: How long does it take to add a node? Will it affect my workloads?
A: Adding each node takes 5 minutes and does not affect your workloads. For information about how to add nodes, see Add or remove nodes.
Note
Read/write splitting connections created after you add a read-only node forward requests to that read-only node. Read/write splitting connections established before you add the read-only node do not forward requests to the newly added read-only node. You must disconnect such a connection and establish it again, for example, by restarting the application.
Q: How long does an upgrade to the latest minor version take? Does it affect workloads?
A: PolarDB for MySQL uses rolling upgrades across multiple nodes to minimize the impact on workloads. A version upgrade usually takes no more than 30 minutes. The database proxy or the DB engine is restarted during the upgrade, which may cause transient database connection interruptions. Perform the upgrade during off-peak hours and make sure that your application has an automatic reconnection mechanism. For details, see Minor version management.
Q: How does automatic failover work?
A: PolarDB for MySQL uses an active-active high availability cluster architecture. Failover occurs automatically between the read-write primary node and the read-only nodes, and the system elects a new primary node. PolarDB Each node has a failover priority that determines how likely the node is to be elected as the primary node during a failover. When multiple nodes have the same priority, they have the same probability of being elected as the primary node. For details, see Automatic failover and manual failover.
Q: What permissions are required to terminate a connection in PolarDB for MySQL?
A: In MySQL, terminating a connection (by using the KILL command) requires appropriate permissions. Specifically, terminating the connection of another regular user requires the PROCESS permission.
Note
- Terminate your own connection: Any user can terminate their own connection. No additional permission is required.
- Terminate another session of the same user: The PROCESS permission is required.
- Terminate a connection of another regular user: In PolarDB for MySQL, a high-privilege account must use the KILL command with caution.
Q: Does the running log error [ERROR] InnoDB: fil_space_extend space_name:xxx affect existing workloads?
A: No. Your existing workloads are not affected. This log indicates that after a file size is extended on the read-write node of the PolarDB cluster, the read-only nodes synchronize the file size information in memory. MySQL 5.7 clusters do not change the ERROR level of the log, so on the read-only nodes it can be treated as the INFO level. This does not affect your workloads.
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 and evenly distributes traffic between the two proxy nodes at a 1:1 ratio. The system continuously checks the health of the proxy nodes. If a node fails, the system proactively disconnects the connections on that node. The remaining healthy node automatically takes over all traffic so that the service is not interrupted. The system also automatically rebuilds and restores the failed proxy node. The whole process usually takes about 2 minutes, and the database cluster remains accessible during this time.
In rare cases, the connections on a failed node are not disconnected in time, but the node can no longer respond to requests. To handle this, configure appropriate timeout policies on the client, such as the JDBC socketTimeout and connectTimeout parameters, so that the application layer can promptly detect and terminate suspended connections. This further improves the fault tolerance and response efficiency of the system.
Q: How do I view the error logs of a PolarDB for MySQL cluster?
A: Go to the PolarDB console. In the left-side navigation pane of the details page of the target cluster, choose Diagnostics and Optimization > Log Management. On the Running Logs tab, view the corresponding error logs.

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

A: PolarDB for MySQL creates an implicit primary key for tables without primary keys by default.

-- 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, in which 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 does your application receive the Lock wait timeout exceeded error, and why does troubleshooting find a transaction whose trx_mysql_thread_id is 0?
A: When your application interacts with PolarDB for MySQL and encounters a workload interruption caused by lock waits, and you observe a thread in the database whose thread_id is 0, this usually means that an incomplete XA (distributed) transaction is holding a lock.
Symptoms
- When an application or a client connects to the database, it receives ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction.
- After you log on to the database and run SELECT * FROM information_schema.innodb_trx; to query, you find that the output contains a long-running transaction whose trx_mysql_thread_id is 0. This transaction blocks 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
```
Causes
In the InnoDB storage engine, a trx_mysql_thread_id of 0 is the indicator of an XA transaction. The problem usually occurs during the two-phase commit process of an XA transaction. After the transaction successfully runs XA PREPARE and enters the prepared state, the external transaction manager may fail to issue the XA COMMIT (commit) or XA ROLLBACK (rollback) command because of network issues, program exceptions, or other reasons. If this happens, the transaction remains stuck in the prepared state. A transaction in this state continues to hold the lock resources that it has obtained. Other transactions that need these resources are blocked, which eventually causes a lock wait timeout.
Solutions
You must manually intervene and, based on your actual business requirements, commit (COMMIT) or roll back (ROLLBACK) the XA transactions that are in the prepared state.
1. Find uncommitted XA transactions: RunXA RECOVER;to query the XA transactions that are currently uncommitted. Record the values of the formatID, gtrid_length, bqual_length, and data fields for the target transaction. This information is critical in 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 XA transactions: After you find the XA transactions, you can roll back or commit them based on your business requirements.
  1. Get the unique identifier of the XA transaction (xid): xid consists of three parts: gtrid, bqual, and formatID. You must construct xid based on the information obtained in the previous step.
    gtriddata: From the gtrid_length field, extract the first
    bqualdata: From the end of the bqual_length field, extract the last
    formatIDformatID: Use the value of the
    Take the previous step (Find uncommitted XA transactions) as an example. You can construct the three parts of xid by using 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'
    formatID10000
  2. Commit or roll back XA transactions: A manual commit or rollback may cause the final state of the XA transaction to differ from the original intent of the transaction coordinator. This creates a risk of data inconsistency. Fully understand the business context of the transaction and confirm that the operation is safe before you run the following commands.
    Commit: If you determine that the transaction should be committed, run:
    XA COMMIT '192.168.1.2', '_app_name_test', 10000;
    Roll back: If you determine that the transaction should be rolled back, run:
    XA ROLLBACK '192.168.1.2', '_app_name_test', 10000;
3. After the command runs successfully, the locks held by the uncommitted XA transaction are released and the database service returns to normal.
For more information about the XA transaction syntax, see MySQL official documentation: XA Transactions.
Why do different PolarDB for MySQL 8.0 clusters handle errors inconsistently when they compare invalid date and time types?
- Problem description: PolarDB for MySQL 8.0 clusters are available in two revisions: MySQL 8.0.1 and MySQL 8.0.2. The two revisions are fully compatible with MySQL 8.0.13 and MySQL 8.0.18, respectively. However, they behave inconsistently when they handle invalid date and time types.
  Specifically, when a string constant is compared with a time type, the string is converted to that time type. If the string is an invalid date, the conversion fails. The two revisions also behave differently when the conversion fails. Revision 8.0.13 only returns WARNING, whereas revision 8.0.18 directly returns the error code ER_WRONG_VALUE. As a result, when invalid date and time fields are compared, the two revisions of PolarDB for MySQL clusters report errors inconsistently.
- Solution: To keep the results of the same SQL statement consistent (either all succeed or all fail), multiple PolarDB for MySQL clusters must use the same major kernel version. That is, they must all be MySQL 8.0.1 or MySQL 8.0.2.

Backup and restore

Q: Which backup method does PolarDB for MySQL
A: PolarDB for MySQL uses snapshots for backup. For details, see ESSD cloud disk.
Q: How fast is database restoration?
A: Whether you restore to a point in time or from a backup set (snapshot), the key process is the same: first, a temporary node is created and the data from a specific point in time is restored to that node, and then the restored data is recovered to the original cluster. For detailed time estimates, see Overall process and estimated time.

Performance and capacity

Q: Why is the performance improvement of PolarDB for MySQL over RDS MySQL not obvious?
A: Before you compare the performance of PolarDB for MySQL with that of RDS MySQL, note the following items to obtain accurate and reasonable comparison results.
- Compare the performance of PolarDB for MySQL and RDS MySQL instances that use the same specifications.
- Compare the performance of PolarDB for MySQL and RDS MySQL instances that run the same version.
  Different versions use different implementation mechanisms. For example, MySQL 8.0 is optimized for CPUs with many cores and uses separate threads such as Log_writer, log_fluser, log_checkpoint, and log_write_notifier. However, when the number of CPU cores is small, MySQL 8.0 performs worse than MySQL 5.6 or 5.7. We do not recommend comparing PolarDB for MySQL 5.6 with RDS MySQL 5.7 or 8.0, because the MySQL 5.6 optimizer is older and less capable than the optimizers of later versions.
- We recommend that you simulate production workload pressure for the actual performance comparison, or use sysbench. The data you collect this way is closer to real production conditions.
- When you compare read performance, do not use a single SQL statement.
  Because PolarDB for MySQL uses an architecture that separates compute from storage, a single statement is affected by network latency, which makes read performance lower than that of RDS. In production databases, the cache hit ratio is generally above 99%. Only the first read invokes I/O, so read performance drops. Subsequent reads find the data in the buffer pool and do not invoke I/O, so the performance is the same.
- When you compare write performance, do not use a single SQL statement either. Simulate your production environment and run a stress test instead.
  To compare performance with RDS, use PolarDB for MySQL (a primary node and a read-only node) and RDS (a primary instance and a semi-synchronous read-only instance). This is because the PolarDB for MySQL architecture uses the Quorum mechanism by default when it writes data. Data is written to a majority of the three replicas by default. A write operation is considered successful when it succeeds on two or more of the three replicas. PolarDB for MySQL already provides data redundancy at the storage layer and ensures high reliability through strong synchronization across the three replicas. Therefore, it is more reasonable to compare it with the semi-synchronous replication of RDS MySQL rather than asynchronous replication.
PolarDB for MySQLPerformance comparison: PolarDB for MySQL vs. ApsaraDB RDS for MySQL For the results of the performance comparison with RDS MySQL, see
Q: What is the maximum number of tables? At what number of tables might performance start to degrade?
A: The maximum number of tables is limited by the number of files. For details, see Limits.
Q: Can table partitioning improve the query performance of PolarDB for MySQL?
A: In general, if a query SQL statement can be limited to a single partition, performance improves.
Q: Does PolarDB for MySQL support creating 10,000 databases? What is the maximum number of databases?
A: PolarDB for MySQL supports creating 10,000 databases. The maximum number of databases is limited by the number of files. For details, see Limits.
Q: Is the number of read-only nodes related to the maximum number of connections? Can I increase the maximum number of connections by adding read-only nodes?
A: The number of read-only nodes is not related to the maximum number of connections. The maximum number of connections for PolarDB for MySQL is determined by the node specifications. For details, see Limits. If you need more connections, upgrade specifications.
Q: How is IOPS limited and isolated? Can I/O contention occur between multiple PolarDB for MySQL cluster nodes?
A: Each node of a PolarDB for MySQL cluster has its IOPS configured based on its specifications. IOPS is isolated independently between nodes, so the nodes do not affect one another.
Q: Does slower performance on a read-only node affect the primary node?
A: When the load on a read-only node is too high or replication latency increases, memory consumption on the primary node may increase slightly.
Q: What is the impact on performance after binlog is enabled?
A: Enabling binlog does not affect query (SELECT) performance. It affects only the performance of write and update operations (INSERT, UPDATE, and DELETE). In general, for a database with a balanced read/write workload, enabling binlog affects performance by no more than 10%.
Q: What is the impact on performance when SQL Explorer (full SQL log auditing) is enabled?
A: No impact.
Q: Which high-speed network protocol does PolarDB for MySQL use?
A: Dual 25 Gbps RDMA is used between the database compute nodes and storage nodes of PolarDB for MySQL, and between the multiple replicas of stored data. This delivers low-latency, high-throughput I/O performance.
Q: What is the maximum bandwidth of the Internet connection for PolarDB for MySQL?
A: The maximum bandwidth of the Internet connection for PolarDB for MySQL is 10 Gbit/s.

Large tables

Q: Compared with a traditional database that uses local disks, what are the advantages of storing large tables in PolarDB for MySQL?
A: A table in PolarDB for MySQL is physically split across N storage servers. The I/O for a single table is therefore distributed across multiple storage disks. The overall I/O read throughput (not the I/O latency) is far better than that of a centralized database on local disks.
Q: How do I optimize a large table?
A: Use partitioned tables.
Q: In which situations are partitioned tables suitable?
A: Partitioned tables are suitable when you need to prune a large table to control the amount of data that a query accesses and you want the pruning to be transparent to your application code (no changes to the application code are required). For example, you can use a partitioned table to clean up historical business data on a regular schedule, such as dropping the earliest monthly partition and creating the partition for the next month to keep only the data of the last six months.
Q: Within the same PolarDB for MySQL database, what is the best way to copy a table that contains a large amount of data (for example, copying the entire table A into table B)?
A: You can use the following SQL statement to copy the table directly:
```
create table B as select * from A
```

Stability

Q: Can short-lived PHP connections be optimized under high concurrency?
A: Yes. You can enable a session-level connection pool in the cluster endpoint to optimize these connections. For details, see Configure the database proxy.
Q: How do I prevent a few inefficient SQL statements from bringing down the entire database?
A: You can use the statement concurrency control feature Concurrency control to throttle specific statements.
Q: Does PolarDB for MySQL support idle session timeout?
A: Yes. You can modify the wait_timeout parameter to customize the timeout period of idle sessions. For instructions, see Set cluster parameters and node parameters.

Q: How do I find slow SQL statements?

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

Query slow SQL statements directly in the console. For details, see Slow SQL query.

Connect to the database cluster and run show processlist; to find SQL statements that take too long to execute. Run the show processlist command to view the current process list. The query with Id 33554499, select sleep(600), has been running for 250 seconds and is therefore a slow SQL statement.

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 statement?
A: After you find a slow SQL statement, check the ID of the slow SQL statement and then run kill <Id> to terminate it.
```
mysql> kill 33554499;
Query OK, 0 rows affected (0.01 sec)
```
Why does the database restart the cluster? I see a cluster restart task in the task center.
You can go to the Performance Monitoring page of the target cluster and check the Cluster tab to see whether the CPU Usage or Memory Usage of your cluster nodes has reached 100%, which triggered a primary/secondary switchover and restarted the cluster.

Data lifecycle

Q: How does PolarDB for MySQL archive hot and warm data to cold storage?
A: PolarDB for MySQL supports archiving the hot data of the InnoDB engine in PolarStore, the warm data of the X-Engine, and the cold data in OSS (in CSV, ORC, IBD, and other formats) to OSS cold storage media by using a specified DDL policy. After the data is archived, the storage space on PolarStore is released and the overall database storage cost is reduced. For more information, see Cold data archiving.
Q: Does PolarDB for MySQL support automatic separated storage of hot, warm, and cold data? How is this implemented?
A: PolarDB for MySQL supports automatic separation and archiving of hot data, warm data, and cold data. By specifying a DLM policy, you can automatically archive the data in PolarStore to low-cost OSS storage media, which reduces database storage costs. For more information, see Cold data archiving.