本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# Aurora MySQL 資料庫引擎更新 2017-10-24 (1.15 版) (已棄用)
**版本：**1.15
Aurora MySQL 1.15 已全面推出。所有新的資料庫叢集 (包括從快照還原的叢集) 將會以 Aurora 1.15 建立。您可自行選擇 (非必要) 將現有的資料庫叢集升級至 Aurora 1.15。您可以在 Aurora 1.14.1 中建立新的資料庫執行個體。您可以使用 AWS CLI 或 Amazon RDS API 並指定引擎版本來執行此操作。
Aurora 1.15 採用叢集修補模式，在此模式中，Aurora 資料庫叢集中的所有節點都會同時修補。更新時，資料庫需要重新啟動，因此您會經歷 20 到 30 秒的停機時間，之後就可以繼續使用資料庫叢集或叢集。如果您的資料庫叢集目前執行 Aurora 1.14 或 Aurora 1.14.1，Aurora MySQL 中的零停機時間修補功能，或許可讓用戶端到 Aurora MySQL 主要執行個體的連線撐過整個升級期間，視您的工作負載而定。
如果您有任何問題或疑慮，可在社群論壇和透過 AWS Support 取得 [AWS Support](https://aws.amazon.com/support)。如需詳細資訊，請參閱《Amazon Aurora 使用者指南》**中的[維護 Amazon Aurora 資料庫叢集](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_UpgradeDBInstance.Maintenance.html)。
## 零停機時間修補
零停機時間修補 (ZDP) 功能以*最佳作法*為基礎，試圖在整個引擎修補作業中維持用戶端正常連線。如需 ZDP 的詳細資訊，請參閱《Amazon Aurora 使用者指南》**中的[使用零停機修補](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Updates.Patching.html#AuroraMySQL.Updates.ZDP)。
## 新功能
+ **非同步索引鍵預先提取** – 非同步索引鍵預先提取 (AKP) 功能可在需要時預先提取記憶體中的索引鍵，藉此提升非快取索引聯結的效能。AKP 的主要使用案例，是小型外部資料表與大型內部資料表間的索引聯結，其中較大資料表的索引具有高度選擇性。此外，啟用多範圍讀取 (MRR) 界面期間，若需以次要索引查詢主要索引，就會使用 AKP。只要具備正確的索引鍵基數，部分情況下，具記憶體限制的較小執行個體可能可以使用 AKP。如需詳細資訊，請參閱《Amazon Aurora 使用者指南》**中的[使用非同步索引鍵預先擷取最佳化 Aurora 編製索引的聯結查詢](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.BestPractices.html#Aurora.BestPractices.AKP)。
+ **快速 DDL** – 我們已將 [Aurora v1.13](AuroraMySQL.Updates.20170515.md) 推出的功能擴展至含有預設值的操作。擴展後，不論資料欄是否具有預設值，如需將可為 Null 的資料欄新增至資料表結尾，快速 DDL 都可適用。此功能仍處於 Aurora 實驗室模式。如需詳細資訊，請參閱《Amazon Aurora 使用者指南》**中的[使用快速 DDL 更改 Amazon Aurora 中的資料表](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Managing.FastDDL.html)。
## 改進
+ 修正之前在 WITHIN/CONTAINS 空間查詢期間導致空結果集合的計算錯誤。
+ 修正 `SHOW VARIABLE` 命令，只要參數群組的 `innodb_buffer_pool_size` 參數有所變更，便顯示更新後的參數值。
+ 調適性雜湊索引功能停用時，若要插入的記錄為頁面的第一筆記錄，則在大量插入以快速 DDL 更改的資料表期間，主要執行個體的穩定性已獲得改善。
+ 使用者嘗試將 **server\$1audit\$1events** 資料庫叢集參數值設為 **default** 時，Aurora 的穩定性已獲得改善。
+ 修正以下問題：對於 Aurora 主要執行個體上執行的 ALTER TABLE 陳述式，資料庫字元集的變更要等到 Aurora 複本重新啟動之後才會複寫。
+ 先前，即使主要執行個體已關閉其磁碟區，系統仍會允許註冊 Aurora 複本，如今修正主要執行個體的競爭條件，藉以改善穩定性。
+ 變更鎖定通訊協定，在建置索引期間支援並行資料操作語言 (DML) 陳述式，改善主要執行個體在大型資料表上建立索引期間的效能。
+ 修正 InnoDB 中繼資料在 ALTER TABLE RENAME 查詢期間的不一致性，藉此改善穩定性。範例：資料表 t1(c1, c2) 欄位在相同的 ALTER 陳述式中，以循環方式重新命名為 t1(c2,c3)。
+ 在 Aurora 複本沒有作用中的工作負載，且主要執行個體沒有回應的情況下，Aurora 複本的穩定性已獲改善。
+ Aurora 複本明確鎖定資料表並封鎖複寫執行緒，使其無法套用主要執行個體發出的任何 DDL 變更，在此情況下，Aurora 複本的可用性已獲改善。
+ 同時在兩個獨立工作階段，將外部索引鍵和資料欄新增至資料表，且快速 DDL 已啟用的情況下，主要執行個體的穩定性已獲改善。
+ 復原記錄清除前，先行封鎖截斷記錄的功能，藉此改善龐大的寫入工作負載期間，主要執行個體上清除執行緒的穩定性。
+ 修正卸除資料表的交易在遞交流程期間的鎖定釋放順序，藉此改善穩定性。
+ 修正 Aurora 複本缺失，亦即資料庫執行個體無法完成啟動作業，因而提出系統早已使用 3306 連接埠的投訴。
+ 針對在特定 information\$1schema 資料表 (innodb\$1trx、innodb\$1lock、innodb\$1lock\$1waits) 上執行的 SELECT 查詢，修正會增加叢集不穩定性的競爭條件。
## MySQL 錯誤修正整合
+ CREATE USER 接受外掛程式及密碼雜湊，但忽略密碼雜湊 (錯誤編號 78033)
+ 分割引擎將欄位新增至讀取位元組，以傳回自分割索引排序的項目。這導致聯結緩衝區會嘗試讀取不需要的欄位。不將所有分割欄位新增至 read\$1set，僅排序 read\$1set 中已設定的字首欄位，藉以修正這項錯誤。新增 DBUG\$1ASSERT，一旦執行 key\$1cmp，則至少必須讀取第一個欄位 (錯誤編號 16367691)。
+ MySQL 執行個體拖延「製作 SYNC 索引」(錯誤編號 73816)
+ 在 ALTER TABLE CHANGE COLUMN 中宣告 RBT\$1EMPTY(INDEX\$1CACHE->WORDS) (錯誤編號 17536995)
+ 涉及儲存點時，InnoDB 全文搜尋找不到記錄 (錯誤編號 70333)