本文介绍PolarDB MySQL版的常见问题和解答。
基本问题
Q：什么是PolarDB？
A：PolarDB是一个关系型数据库云服务，目前已在全球十多个地域（Region）的数据中心部署，向用户提供开箱即用的在线数据库服务。PolarDB目前支持3种独立的引擎，分别可以100%兼容MySQL、100%兼容PostgreSQL、高度兼容Oracle语法，存储容量最高可达200 TB。详情请参见什么是PolarDB MySQL企业版。
Q：为什么云原生数据库PolarDB优于传统数据库？
A：相较于传统数据库，云原生数据库PolarDB支持上百TB级别海量数据存储，提供高可用和高可靠保障、快速弹性升降级、无锁备份等功能，详情请参见产品优势。
Q：PolarDB是什么时候发布？什么时候开始商用？
A：2017年9月发布公测，2018年3月开始商用。
Q：集群和节点分别指的是什么？
A：PolarDB集群版采用多节点集群的架构，集群中有一个主节点和多个只读节点。单个PolarDB集群支持跨可用区，但不能跨地域，面向集群进行管理和计费。详情请参见术语。
Q：支持哪些编程语言？
A：PolarDB支持Java、Python、PHP、Golang、C、C++、.NET、Node.js等编程语言。只要支持原生MySQL的编程语言都可以直接使用PolarDB MySQL版，详情请参见MySQL官网。
Q：支持哪些存储引擎？
A：PolarDB支持2种产品系列，不同系列支持的存储引擎详情如下：
PolarDB MySQL版集群版全部表均使用InnoDB存储引擎。创建表的时候，PolarDB MySQL版会自动将非InnoDB引擎（如MyISAM、Memory、CSV等）转换为InnoDB引擎，因此即使迁移之前的数据表不是InnoDB，也仍然能够正常迁移至PolarDB MySQL版。
Q：PolarDB是分布式数据库吗？
A：是的，PolarDB是基于Parallel Raft一致性协议的分布式存储集群，计算引擎是由1~16个分布在不同服务器上的计算节点构成，存储容量最高可达200 TB，最高支持88核710 GB内存，可在线动态扩容存储和计算资源，扩容时不会影响业务的正常运行。
Q：购买PolarDB后，如果需要分库分表是否还需要购买PolarDB-X数据库中间件？
A：是的。
Q：PolarDB是否支持表的分区？
A：支持。
Q：PolarDB是否已经自动包含了分区机制？
A：PolarDB在存储层做了分区，对用户透明，无感知。
Q：单节点系列是如何保证服务可用性和数据可靠性呢？
A：单节点是基于单个计算节点提供特定用途的数据库产品。虽然只有一个节点，但单节点借助秒级计算调度、分布式多副本存储等技术，依旧可以保证服务的高可用性和数据的高可靠性。
Q：如何购买单节点形态的PolarDB集群？
A：当前单节点产品系列已经下线，但您可以在购买集群时将节点个数中只读节点个数设置为0，即可购买单节点形态的PolarDB集群。
兼容性
Q：是否兼容社区版MySQL？
A：PolarDB MySQL版可以100%兼容社区版MySQL。
Q：支持哪些事务隔离级别？
A：PolarDB MySQL版支持READ_UNCOMMITTED、READ_COMMITTED（默认）、REPEATABLE_READ这三种隔离级别，不支持SERIALIZABLE隔离级别。
Q：SHOW PROCESSLIST与社区版MySQL是否存在差异？
A：如果是通过主地址查询，两者没有区别。但如果是通过集群地址查询，略有差异，此时会出现有多条相同Thread ID的记录，分别对应PolarDB MySQL版集群中的每一个节点。
Q：PolarDB MySQL版MDL锁机制和社区版MySQL是否存在差异？
A：PolarDB MySQL版与社区版MySQL的MDL机制保持一致。但由于PolarDB MySQL版的数据库节点是基于共享存储的架构，这将导致主节点在执行DDL操作的时候，只读节点可能会查询到DDL操作的中间数据而出现数据不一致的问题。因此，PolarDB MySQL版会将DDL操作中涉及到的Exclusive MDL锁通过Redo日志同步到只读节点上，以阻止只读节点上其它用户线程在DDL操作过程中访问表数据。在特定场景下，这可能会堵塞DDL操作。您可以通过
show processlist命令查看DDL操作的执行状态，若执行状态为Wait for syncing with replicas，则说明发生了上述情况。具体解决措施请参考查看DDL执行状态和MDL锁状态。Q：Binlog格式和MySQL原生格式是否存在差异？
A：没有差异。
Q：是否支持performance schema和sys schema？
A：支持。
Q：表统计信息收集和社区版MySQL是否存在差异？
A：PolarDB MySQL版主节点的表统计信息和社区版MySQL一致。为了保证主节点和只读节点执行计划的一致性，主节点每次更新统计信息时，会同步到只读节点。此外，只读节点还可以通过
ANALYZE TABLE操作，主动从磁盘加载最新的统计信息。Q：PolarDB是否支持XA事务，和官方MySQL是否存在差异？
A： 支持，没有差异。
Q：PolarDB是否支持全文索引？
A：支持。
说明目前，用户使用全文索引时，只读节点存在一定的索引缓存数据延迟，建议读写全文索引的操作都使用主地址，以读到最新的数据。
Q：是否支持Percona工具集？
A： 支持，但是建议您使用online DDL。
Q：是否支持gh-ost？
A：支持，但是建议您使用online DDL。
费用
Q：PolarDB的费用都包含哪些？
A：包含存储空间、计算节点、备份（附赠免费额度）、SQL洞察（可选），详情请参见计费项概览。
Q：收费的存储空间都包含哪些内容？
A：包含数据库表文件、索引文件、undo日志文件、Redo日志文件、Binlog文件、slowlog文件及少量的系统文件，详情请参见概览。
Q：PolarDB的存储包怎么用？
A：购买的包年包月或按量付费的集群，均可使用存储包抵扣存储费用。例如您有3个存储容量均为40 GB的集群（即总容量为120 GB），这3个集群可以共享一个100 GB的存储包，多出的20 GB则按量计费，详情请参见购买存储包。
Q：如果增加一个只读节点，价格如何收费？
A：只读节点的价格和主节点的价格一致，请参见计算节点价格细则。
Q：如果增加一个只读节点，存储容量是否会增大一倍？
A：PolarDB采用计算与存储分离的架构，购买的只读节点是计算资源，因此存储容量不会增加。
存储空间采用Serverless方式，购买时无需选择容量，随着数据增长而在线自动扩容，只按实际数据量大小收费。每个集群规格都有对应的最大存储容量。如需提高存储容量上限，请升级集群规格。
Q：按量付费的集群，如何操作不再产生费用？
A：如果您确认不再使用该集群，可以释放集群。集群释放后将不再产生费用。
Q：临时升配期间的集群还可以变配吗？
Q：PolarDB的公网带宽是多少？是否会产生费用？
A：PolarDB本身没有公网带宽限制，主要取决于您所使用的SLB服务的带宽。PolarDB的公网连接不收费。
Q：为什么包年包月的集群每天还有费用产生？
A：PolarDB的计费项主要包括：计算节点（主节点和只读节点）、存储空间、数据备份（仅超出免费额度时收费）、SQL洞察（可选）、全球数据库网络GDN（可选），具体请参考计费项概览。包年包月是指在新建数据库集群时您需预支付集群的计算节点费用，但存储空间、数据备份和SQL洞察的费用不包含在内。实际使用数据库的过程中，会根据集群所占用的存储空间，从账户中按小时扣除一定的存储空间的费用。因此在包年包月的购买方式下，依旧会产生按量付费的账单。
Q：RDS一键迁移至PolarDB是否额外收费？
A：一键迁移过程免费，仅收取RDS实例和PolarDB集群本身的费用。
Q：为什么PolarDB表数据使用
delete删除后仍然收取存储空间费用？A：
delete只是给表打上删除的标记，并不会释放表空间。
集群访问（读写分离）
Q：如何实现PolarDB的读写分离？
A：只需在应用程序中使用集群地址，即可根据配置的读写模式实现读写分离，详情请参见配置数据库代理。
Q：一个PolarDB集群内最多可以支持多少个只读节点？
A：PolarDB采用分布式集群架构，一个集群包含一个主节点和最多15个只读节点（至少一个，用于保障高可用）。
Q：多个只读节点间负载不均衡的原因是什么？
A：只读节点间负载不均衡的原因有只读节点连接数较少、自定义集群地址分配时未包括某个只读节点等。
Q：造成主节点负载高或低的原因是什么？
A：造成主节点（主库）负载高的原因有直连主地址、主库接受读请求、存在大量的事务请求、主从复制延迟高导致请求被路由到主库、只读节点异常导致读请求被路由到主库等。
而主节点负载较低的原因可能是主库开启了不接受读选项。
Q：怎么降低主节点的负载？
Q：为什么读不到刚插入的数据？
A：该问题可能是由于一致性级别的配置导致的，PolarDB的集群地址支持如下几种一致性级别：
最终一致性：不论是同一会话（连接）或不同会话，最终一致性都不保证读能够马上读到刚插入的数据。
会话一致性：一定能够读到同一会话插入之后的数据。
全局一致性：保证同一会话和不同会话都能够读到最新数据。
说明一致性等级越高，性能越差，对主库的压力越大，请谨慎选择。对于大多数应用场景会话一致性能够保证业务正常工作，对于少数有强一致性的需求的语句，可以通过Hint
/* FORCE_MASTER */来实现，详情请参见一致性级别。Q：如何强制SQL到主节点执行？
A：使用集群地址时，在SQL语句前加上
/* FORCE_MASTER */或/* FORCE_SLAVE */，即可强制指定这条SQL的路由方向，详情请参见HINT语法。/* FORCE_MASTER */强制请求被路由到主库。该用法可以用于解决少数一致性要求较高的读请求的场景。/* FORCE_SLAVE */强制请求被路由到从库。该用法可以用于解决少数PolarDB代理由于保证正确性，要求特殊语法被路由到从库的场景（比如存储过程的调用，multistatement的使用等语句默认是会被路由到主库）。
说明Hint的路由优先级最高，不受一致性级别和事务拆分的约束，使用前请进行评估。
Hint语句里不要有修改 GUC 参数的语句，例如/*FORCE_SLAVE*/ set enable_hashjoin = off; 等，这类语句可能导致查询结果非预期。
Q：是否可以给不同的业务分配不同的地址？不同地址间是否可以达到隔离的效果？
A：您可以创建多个自定义地址给不同的业务使用，若底层节点不同则自定义地址间可同时具备隔离的效果，不会互相影响。关于如何创建自定义地址，详情请参见新增自定义集群地址。
Q：如果有多个只读节点，如何为其中某个只读节点单独创建单节点地址？
A：仅当集群地址读写模式为只读且集群内拥有三个及以上节点时，才支持创建单节点地址，详细操作步骤请参见设置集群地址。
警告创建单节点地址后，当此节点故障时，该地址可能会出现最多1小时不可用的情况，请勿用于生产环境。
Q：一个集群内最多允许创建多少个单节点地址？
A：如果您的集群内有3个节点，则只允许为其中1个只读节点创建单节点地址；若集群内有4个节点，则允许为其中2个只读节点创建各自的单节点地址，以此类推。
Q：只用了主地址，但是发现只读节点也有负载，是否主地址也支持读写分离？
A：主地址不支持读写分离，始终只连接到主节点。只读节点有少量QPS是正常现象，与主地址无关。
管理与维护
Q：如何在线添加字段和索引？
A：支持原生自带的online DDL、pt-osc和gh-ost等工具，建议您使用自带的online DDL操作。
说明使用pt-osc工具时，请不要使用用于设置主从检测的相关参数，如参数
recursion-method。因为pt-osc工具是基于Binlog复制进行主从检测的，但PolarDB内部采用的是物理复制，没有基于Binlog的复制信息。Q：是否支持bulk insert功能？
A：支持。
Q：若只向只写节点写入数据，是否支持bulk insert？一次最多支持insert多少个values？
A：支持。一次最多支持的values数量由max_allowed_packet参数值决定，详细请参见Replication and max_allowed_packet。
Q：是否支持通过集群地址执行bulk insert操作？
A：支持。
Q：主节点（主）与只读节点（备）是否存在复制延迟？
A：是，它们之间存在毫秒级延迟。
Q：什么情况下会导致复制延迟增大？
A：出现如下情况时会导致复制延迟增大：
主节点写入负载高，产生了过多的Redo日志，导致只读节点来不及应用。
只读节点负载过高，抢占了过多原本属于应用Redo日志的资源。
I/O出现瓶颈，导致读写Redo日志过慢。
Q：存在复制延迟的情况下，如何保证查询的一致性？
A：您可以使用集群地址并为其选择合适的一致性级别。目前一致性从高到低分别为全局一致性（强一致性）、会话一致性和最终一致性，详情请参见一致性级别。
Q：单节点故障的情况下是否可以保证RPO为0？
A：可以。
Q：升级规格配置（比如从2核8 GB升级到4核16 GB）后端是怎么实现的？对业务有什么影响？
A：PolarDB的代理（Proxy）和数据库节点（Node）均需要升级到最新的配置，采用多个节点滚动升级的方式尽量减少对业务的影响。目前每次升级大概需要10~15分钟，对业务的影响时间不超过30秒，期间可能会产生1~3次连接闪断，详情请参见手动变配。
Q：添加节点要多久？是否会影响业务？
A：每增加一个节点需要5分钟，对业务无影响。关于如何添加节点，详情请参见增加只读节点。
说明新增只读节点之后新建的读写分离连接会转发请求到该只读节点。新增只读节点之前建立的读写分离连接不会转发请求到新增的只读节点，需要断开该连接并重新建立连接，例如，重启应用。
Q：升级到最新修订版本需要多久？是否会影响业务？
A：PolarDB采用多节点滚动升级的方式尽量减少对业务的影响。版本升级一般不超过30分钟，升级过程中会重启数据库代理Proxy或内核引擎DB，可能会导致数据库连接闪断。请您尽量在业务低峰期执行升级操作，并且确保您的应用有自动重连机制。详情请参见版本管理。
Q：如何进行故障自动切换？
A：PolarDB采用双活（Active-Active）的高可用集群架构，可读写的主节点和只读节点之间自动进行故障切换（Failover），系统自动选举新的主节点。PolarDB每个节点都有一个故障切换（Failover）优先级，决定了故障切换时被选举为主节点的概率高低。当多个节点的优先级相同时，则有相同的概率被选举为主节点，详情请参见自动/手动主备节点切换。
备份与恢复
Q：PolarDB采用什么备份方式？
A：PolarDB采用快照（Snapshot）的方式进行备份，详情请参见备份方式1：自动备份和备份方式2：手动备份。
Q：数据库恢复的速度如何？
A：目前，基于备份集（快照）进行恢复（克隆）的速度是40分钟/TB。如果是恢复到任意时间点，则需要包含应用Redo日志的时间，这部分的恢复速度大概是20~70秒/GB，整个恢复时间是这两部分之和。
性能和容量
Q：为什么PolarDB MySQL版相比RDS MySQL性能提升不明显？
A：在您对PolarDB MySQL版和RDS MySQL进行性能对比前，请了解以下注意事项，以便能获得比较准确、合理的性能对比结果。
使用相同规格配置的PolarDB MySQL版和RDS MySQL进行性能对比。
使用相同版本的PolarDB MySQL版和RDS MySQL进行性能对比。
因为不同版本的实现机制不一样，例如MySQL 8.0针对多核数CPU做优化，单独抽象出来Log_writer、log_fluser、log_checkpoint、log_write_notifier等线程，但在CPU核数较少的情况下性能则不如MySQL 5.6或5.7。不推荐使用PolarDB MySQL版5.6和RDS MySQL 5.7或8.0进行对比，因为MySQL 5.6的优化器比较旧，不如新版本。
推荐使用模拟线上压力的场景进行实际性能对比，或者使用sysbench进行对比，这样获得的数据更接近线上实际场景。
在对比读性能的时候，不推荐您使用单条SQL进行比较。
因为PolarDB是计算存储分离的架构，所以单条语句有网络延迟的影响，导致读性能不如RDS。线上数据库的缓存命中率基本都在99%以上，只有第一次的读会调用I/O，因此读取性能会降低；后续数据都在缓存池（Buffer Pool）中，并不需要调用I/O，因此性能是一样的。
在对比写性能的时候，同样不推荐您使用单条SQL进行比较，推荐模拟线上环境进行压力测试。
如果要对比RDS性能，请使用PolarDB（主节点+只读节点）和RDS（主实例+半同步的只读实例）进行对比。这是因为PolarDB的架构在写入数据的时候默认采用Quorum机制，即写入数据时默认写入到三副本里面的大多数（在三个副本中的两个或两个以上写入成功，就认为写操作成功了）。PolarDB已经在存储层面做数据冗余，并保证三副本强同步高可靠，使用RDS MySQL的半同步复制（而不是异步复制）进行对比更合理。
PolarDB MySQL版与RDS MySQL的性能对比结果，请参见PolarDB MySQL版与RDS MySQL性能对比。
Q：删除数据库后为什么还是占用很多空间？
A：这是由于Redo日志文件占用了空间，通常在2 GB~11 GB左右，最多时会占用11 GB，其中包括缓冲池中8个Redo日志（8 GB）、正在写的Redo日志（1 GB）、提前创建的Redo日志（1 GB）以及最后一个Redo日志（1 GB）。
缓冲池内的Redo日志文件数量由参数
loose_innodb_polar_log_file_max_reuse控制，默认值为8。您可以修改这个参数从而减少日志空间占用量，但在压力大的情况下，性能可能会出现周期性的小幅波动。
Q：表个数上限是多少？表个数到多少时有可能会引起性能下降？
A：表个数的上限受文件数量限制，详情请参见使用限制。
Q：表分区能够提高PolarDB的查询性能吗？
A：通常来说，如果查询SQL能够落在某个分区内，是可以提升性能的。
Q：PolarDB是否支持创建1万个数据库？数据库个数上限是多少？
A：PolarDB支持创建1万个数据库。数据库个数上限受文件数量限制，详情请参见使用限制。
Q：只读节点的数量与最大连接数有关系吗？可以通过增加只读节点来增加最大连接数吗？
A：只读节点的数量与最大连接数无关，PolarDB的最大连接数由节点规格决定，详情请参见使用限制。若需更大的连接数，请升级规格。
Q：IOPS是怎么限制和隔离的？是否会出现多个PolarDB集群节点的I/O争抢？
A：PolarDB集群的每个节点根据规格大小设置IOPS，每个节点之间IOPS独立隔离，互不影响。
Q：只读节点的性能变慢是否会影响主节点？
A：只读节点的负载过高、复制延迟增高时，可能会少量增加主节点的内存消耗。
Q：打开Binlog之后，对性能有什么影响？
A：开启Binlog不会影响查询（SELECT）性能，只会影响写入更新（INSERT、UPDATE、DELETE）性能。一般情况下，在读写均衡的数据库中，开启Binlog后对性能影响不超过10%。
Q：打开SQL洞察（全量SQL日志审计），对性能有什么影响？
A：无影响。
Q：PolarDB使用了什么高速网络协议？
A：PolarDB的数据库计算节点和存储节点之间，以及存储数据多副本之间，都使用了双25 Gbps RDMA技术，提供低延迟、高吞吐的强劲I/O性能。
Q：PolarDB外网连接的带宽上限是多少？
A：PolarDB外网连接的带宽上限为10 Gbit/s。
大表问题
Q：对比传统本地盘的数据库，PolarDB MySQL版中的大表存储有什么优势？
A：PolarDB MySQL版中的一张表，物理上会被拆分到N台存储服务器上存储，因此对一张表的I/O会被分摊到多块存储磁盘中，I/O读取的整体吞吐性能（而不是I/O延迟）要远优于集中式的本地盘数据库。
Q：大表如何优化？
A：推荐使用分区表。
Q：哪种情况下适合使用分区表？
A：需要通过裁剪大表来控制查询访问的数据量并且希望该裁剪对业务代码透明（无需修改业务代码）的场景下，适合使用分区表。例如您可以通过使用分区表来定期清理业务历史数据（如删除最早的一个月份分区并新建下个月份分区，实现只保留最近6个月份数据的效果）。
Q：在同一个PolarDB MySQL版的数据库里复制一个数据量很大的表（如将整张表A复制到表B中），什么方式比较合适？
A：您可以使用如下SQL语句直接复制：
create table B as select * from A
稳定性
Q：是否可以对高并发下的PHP短连接进行优化？
A：可以。在集群地址中，可以通过开启会话级连接池进行优化，详情请参见设置集群地址。
Q：如何规避个别执行效率低下的SQL拖垮整个数据库？
A：如果您的PolarDB MySQL版集群是5.6或8.0版本，您可以使用语句并发控制Concurrency Control特性来实现针对指定语句的限流。
Q：PolarDB是否支持空闲会话超时？
A：支持。您可以通过修改wait_timeout参数来自定义空闲会话的超时时间，具体操作步骤请参见设置集群参数和节点参数。
Q：如何发现慢SQL？
Q：如何终止慢SQL？
A：发现慢SQL后，您可以先查看慢SQL的ID，然后执行
kill <Id>终止慢SQL。
数据生命周期
Q：PolarDB MySQL版针对热、温数据是如何实现冷存归档的？
A：PolarDB MySQL版支持将PolarStore中InnoDB引擎的热数据和X-Engine引擎的温数据，通过指定DDL策略以CSV或ORC格式归档至OSS冷存储介质上，归档后，PolarStore上的存储空间将有效得到释放，同时整体数据库存储成本得到有效降低。更多详细信息，请参见手动归档冷数据。
Q：PolarDB MySQL版是否支持热温冷数据自动分离存储，是如何实现的？
A：PolarDB MySQL版支持热数据、温数据和冷数据分离自动归档。通过指定DLM策略，可将PolarStore中的数据自动归档存储到低成本的OSS存储介质上，从而达到数据库存储成本降低优化的效果，更多详细信息。请参见自动归档冷数据。