本文介紹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：叢集購買後不支援變更地區。
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：如果增加一個唯讀節點，價格如何收費？
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 MySQL版終止串連需要什麼許可權？
A：在 MySQL中，終止一個串連（使用
KILL命令）需要具備相應的許可權。具體而言，終止其他普通使用者的串連需要擁有PROCESS許可權。說明終止自己的串連：任何使用者都可以終止自己的串連，無需額外許可權。
終止同一使用者的其他會話：需要具備
PROCESS許可權。終止其他普通使用者的串連：在 PolarDB MySQL 中，高許可權賬戶應謹慎使用
KILL命令。
Q：作業記錄中出現
[ERROR] InnoDB: fil_space_extend space_name:xxx錯誤，是否對現有業務有影響？A：對現有業務沒有影響。該日誌表明，PolarDB叢集的讀寫節點在擴充檔案大小後，唯讀節點會在記憶體中同步檔案大小的資訊。MySQL 5.7版本叢集並未調整日誌的
ERROR層級，因此在唯讀節點層面可視為INFO層級，這對業務本身並未造成影響。Q：資料庫代理的架構是怎樣的？是否具備故障切換機制？如何保障其高可用性？
A：資料庫代理採用雙節點高可用架構，流量按1:1均勻分配至兩個代理節點。系統會持續檢查代理節點的健康狀態。當發現某個節點故障時，會主動斷開該節點上的串連，剩餘的健康節點自動接管全部流量，確保服務不中斷。同時，系統會自動重建並恢複故障的代理節點，整個過程通常在2分鐘左右完成，在此期間，資料庫叢集仍可正常訪問。
在極端情況下，故障節點的串連可能未被及時斷開，但已無法響應請求。為應對此類情況，建議用戶端配置合理的逾時策略（如JDBC的
socketTimeout和connectTimeout），以便在應用程式層及時檢測並終止掛起的串連，進一步提升系統的容錯性和響應效率。Q：如何查看PolarDB MySQL版叢集的錯誤記錄檔？
A：您可以訪問PolarDB控制台，在目的地組群詳情頁的左側導覽列中，進入頁面，在作業記錄頁簽下查看對應的錯誤記錄檔。
Q：PolarDB MySQL版的無主鍵表會自動建立隱藏主鍵嗎？
A：PolarDB MySQL版預設會給無主鍵表建立隱式主鍵。
隱式主鍵查看方式
您可以登入叢集，並設定
SET show_ipk_info = 1後，即可通過SHOW CREATE TABLE的方式查看。-- 設定參數，顯示隱式主鍵 SET show_ipk_info = 1; -- 查看錶結構 SHOW CREATE TABLE t;查看錶結構，其中
__#alibaba_rds_row_id#__列為隱式主鍵。+-------+------------------------------------------------------------------------------------------------------------+ | 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：為什麼業務出現
Lock wait timeout exceeded報錯，且排查發現有trx_mysql_thread_id為0的事務？A：當您的應用程式在與PolarDB MySQL版互動時，如果遇到因鎖等待導致的業務中斷，並觀察到資料庫中存在
thread_id為0的線程時，通常意味著有未完成的XA（分布式）事務正在持有鎖。本文將引導您如問題現象
應用程式或用戶端串連資料庫時，收到
ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction報錯。登入資料庫並執行
SELECT * FROM information_schema.innodb_trx;進行查詢後，發現在輸出結果中存在一條trx_mysql_thread_id欄位值為0的事務，該事務長時間運行並阻塞了其他事務。
問題原因
在InnoDB儲存引擎中，
trx_mysql_thread_id為0是XA事務的標誌。問題通常發生在XA事務的兩階段交易認可過程中：當事務成功執行XA PREPARE進入準備狀態後，如果外部的交易管理員（Transaction Manager）由於網路問題、程式異常或其他原因未能下發XA COMMIT（提交）或XA ROLLBACK（復原）指令，該事務就會一直停滯在準備狀態。處於此狀態的事務會持續持有其擷取的鎖資源，導致其他需要這些資源的事務被阻塞，最終引發鎖等待逾時。解決方案
您需要手動介入，根據業務的實際情況，將處於準備狀態的XA事務進行提交（COMMIT）或復原（ROLLBACK）。
尋找未提交的XA事務：執行
XA RECOVER;命令查詢當前未提交的XA事務。請記錄下您需要處理的目標事務的formatID、gtrid_length、bqual_length和data欄位的值，這些資訊在下一步中至關重要。
手動提交或復原XA事務：查詢到XA事務後，您可以根據業務需求選擇復原或者提交這些事務。
擷取XA事務的唯一識別碼（
xid）：xid由gtrid、bqual和formatID三部分構成。您需要根據上一步查詢到的資訊來構造xid。gtrid：從data欄位的起始位置截取gtrid_length長度的字串。bqual：從data欄位的末尾位置向前截取bqual_length長度的字串。formatID：直接使用formatID欄位的值。
以上一步：尋找未提交的XA事務為例，可以構造出
xid的三個部分。您可以使用substring來拆分data欄位。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
提交或復原XA事務：手動提交或復原可能導致XA事務的最終狀態與事務協調器的原始意圖不一致，從而引發資料不一致的風險。請在充分瞭解該事務的業務上下文，並確認可以安全操作後，再執行以下命令。
提交：如果您判斷該事務應當被提交，請執行：
XA COMMIT '192.168.1.2', '_app_name_test', 10000;復原：如果您判斷該事務應當被復原，請執行：
XA ROLLBACK '192.168.1.2', '_app_name_test', 10000;
執行成功後，未提交XA事務所持有的鎖將被釋放，資料庫服務恢複正常。
關於XA事務文法的更多資訊，請參見 MySQL官方文檔：XA Transactions。
不同的PolarDB MySQL版8.0叢集在比較非法日期和時間類型時，為什麼表現出不一致的錯誤處理行為？
問題描述：PolarDB MySQL版8.0叢集分為MySQL 8.0.1和MySQL 8.0.2兩個版本，二者分別完全相容MySQL 8.0.13與MySQL 8.0.18。然而，這兩個版本在處理非法日期和時間類型的行為上存在不一致。
具體來說，當一個字串常量與時間類型進行比較時，會嘗試將字串轉換為時間類型。如果字串為非法日期，此時轉換將會失敗。兩個版本在轉換失敗時的行為並不一致，8.0.13版本僅會提示
WARNING，而8.0.18版本則會直接返回錯誤碼ER_WRONG_VALUE。因此，在非法日期和時間欄位比較時，這兩個版本的PolarDB MySQL版叢集表現出不一致的報錯行為。解決方案：若希望相同的SQL執行結果保持一致（即均成功或均報錯），則多台PolarDB MySQL版叢集應採用相同的核心大版本，即都為MySQL 8.0.1或MySQL 8.0.2。
備份與恢複
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：表個數的上限受檔案數量限制，詳情請參見使用限制。
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儲存介質上，從而達到資料庫儲存成本降低最佳化的效果，更多詳細資料。請參見自動歸檔冷資料。