常见问题
本文介绍PolarDB MySQL版的常见问题和解答。
基本问题
Q：什么是PolarDB？
A：PolarDB是一个关系型数据库云服务，目前已在全球十多个地域（Region）的数据中心部署，向用户提供开箱即用的在线数据库服务。PolarDB目前支持3种独立的引擎，分别可以100%兼容MySQL、100%兼容PostgreSQL、高度兼容Oracle语法，存储容量最高可达100 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：支持哪些存储引擎？
Q：是否支持自建Slave实例，是否有推荐的实现方式？
A：支持。启用Binlog后可以将PolarDB MySQL版同步到其他MySQL库，构成Master-Slave架构。为方便后续维护，建议您使用数据传输服务DTS（Data Transmission Service）实现同步。
Q：PolarDB是分布式数据库吗？
A：是的，PolarDB是基于Parallel Raft一致性协议的分布式存储集群，计算引擎是由1~16个分布在不同服务器上的计算节点构成，存储容量最高可达100 TB，最高支持120核920 GB内存，可在线动态扩容存储和计算资源，扩容时不会影响业务的正常运行。
Q：购买PolarDB后，如果需要分库分表是否还需要购买PolarDB-X数据库中间件？
A：是的。
Q：PolarDB是否支持表的分区？
A：支持。
Q：PolarDB是否已经自动包含了分区机制？
A：PolarDB在存储层做了分区，对用户透明，无感知。
Q：对比原生MySQL，PolarDB单表最多支持存储多少数据量？
A：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：锁机制和社区版MySQL是否存在差异？
A：PolarDB MySQL版会将DDL中涉及到的Exclusive MDL锁同步到读节点上（同样通过Redo日志），并且使读节点持有MDL锁直到DDL操作结束，来阻止读节点上其它用户线程在DDL执行过程中访问表数据。与社区版MySQL不同，PolarDB MySQL版的主节点和读节点是基于共享存储的，这会导致主节点在做DDL的时候，读节点可能会查询到DDL过程中的中间数据而出现错误。
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：只需在应用程序中使用集群地址，即可根据配置的读写模式实现读写分离，详情请参见配置数据库代理。
Q：一个PolarDB集群内最多可以支持多少个只读节点？
A：PolarDB采用分布式集群架构，一个集群包含一个主节点和最多15个只读节点（至少一个，用于保障高可用）。
Q：多个只读节点间负载不均衡的原因是什么？
A：只读节点间负载不均衡的原因有只读节点连接数较少、自定义集群地址分配时未包括某个只读节点等。
Q：造成主节点负载高或低的原因是什么？
A：造成主节点（主库）负载高的原因有直连主地址、主库接受读请求、存在大量的事务请求、主从复制延迟高导致请求被路由到主库、只读节点异常导致读请求被路由到主库等。
而主节点负载较低的原因可能是主库开启了不接受读选项。
Q：怎么降低主节点的负载？
Q：为什么读不到刚插入的数据？
A：该问题可能是由于一致性级别的配置导致的，PolarDB的集群地址支持如下几种一致性级别：
最终一致性：不论是同一会话（连接）或不同会话，最终一致性都不保证读能够马上读到刚插入的数据。
会话一致性：一定能够读到同一会话插入之后的数据。
全局一致性：保证同一会话和不同会话都能够读到最新数据。
说明一致性等级越高，性能越差，对主库的压力越大，请谨慎选择。对于大多数应用场景会话一致性能够保证业务正常工作，对于少数有强一致性的需求的语句，可以通过Hint
/* FORCE_MASTER */来实现，详情请参见一致性级别。Q：如何强制SQL到主节点执行？
使用集群地址时，在SQL语句前加上
/* FORCE_MASTER */或/* FORCE_SLAVE */，即可强制指定这条SQL的路由方向，详情请参见HINT语法。/* FORCE_MASTER */强制请求被路由到主库。该用法可以用于解决少数一致性要求较高的读请求的场景。/* FORCE_SLAVE */强制请求被路由到从库。该用法可以用于解决少数PolarDB代理由于保证正确性，要求特殊语法被路由到从库的场景（比如存储过程的调用，multistatement的使用等语句默认是会被路由到从库）。
说明若您需要通过MySQL官方命令行执行上述Hint语句，请在命令行中加上-c参数，否则该Hint会被MySQL官方命令行过滤导致Hint失效，具体请参见MySQL官方命令行。
Hint的路由优先级最高，不受一致性级别和事务拆分的约束，使用前请进行评估。
Hint语句里不要有改变环境变量的语句，例如
/*FORCE_SLAVE*/ set names utf8;等，这类语句可能导致查询结果非预期。
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：重启节点需要的时间很长怎么办？
A：当您的集群中存在的文件数量越多，节点重启需要的时间会越长。此时您可以通过修改innodb_fast_startup参数值为ON来加速重启，关于如何修改参数，请参见设置集群参数和节点参数。
说明仅PolarDB MySQL版8.0和5.6版本支持配置该参数。
大表问题
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。
