本文介紹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會被分攤到多Block Storage磁碟中，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中的資料自動Archive Storage到低成本的OSS儲存介質上，從而達到資料庫儲存成本降低最佳化的效果，更多詳細資料。請參見自動歸檔冷資料。