RDS for MySQL參數調優建議
說明數據庫參數是數據庫系統運行的關鍵配置信息，設置不合適的參數值可能會影響業務。本文列舉了一些重要參數說明，更多參數詳細說明，請參見。
修改敏感參數
若干參數相關說明如下：
- “lower_case_table_names”
云數據庫默認值 ：“1”。
作用 ：該參數表示創建數據庫及表時，表存儲是否大小寫敏感。默認值“1”，表示創建數據庫及表時，默認小寫，不區分大小寫。
說明RDS for MySQL 8.0版本不支持該參數。
影響： 修改該參數可能會導致主從復制異常，請謹慎修改。如果必須要修改，請根據以下場景設置數據庫參數：
參數值從1變為0的設置順序：先修改和重啟只讀庫，后修改和重啟主庫。
參數值從0變為1的設置順序：先修改和重啟主庫，在主庫執行 SELECT @@GLOBAL.GTID_EXECUTED 。然后在只讀庫執行 SELECT @@GLOBAL.GTID_EXECUTED ，直到結果集合大于或者等于主庫的SELECT @@GLOBAL.GTID_EXECUTED的結果集合，再修改和重啟只讀庫。
- “innodb_flush_log_at_trx_commit”
云數據庫默認值： “1”。
作用 ：該參數控制提交操作在嚴格遵守ACID合規性和高性能之間的平衡。設置為默認值“1”，是為了保證完整的ACID，每次提交事務時，把事務日志從緩存區寫到日志文件中，并刷新日志文件的數據到磁盤上；當設為“0”時，每秒把事務日志緩存區的數據寫入日志文件，并刷新到磁盤；如果設為“2”，每次提交事務都會把事務日志從緩存區寫入日志文件，每隔一秒左右會刷新到磁盤。
影響 ：參數設置為非默認值“1”時，降低了數據安全性，在系統崩潰的情況下，可能導致數據丟失。
- “sync_binlog”
云數據庫默認值 ：“1”。
作用 ：該參數控制MySQL服務器將二進制日志同步到磁盤的頻率。設置為默認值“1”，表示MySQL每次事務提交，binlog同步寫入磁盤，是最安全的設置；設置為“0”時，表示MySQL不控制binlog的刷新，由文件系統自己控制其緩存的刷新。此時的性能最好，但風險最大，因為一旦斷電或操作系統崩潰，在“binlog_cache”中的所有binlog信息都會被丟失。
影響 ：參數設置為非默認值“1”時，降低了數據安全性，在系統崩潰的情況下，可能導致binlog丟失。
- “innodb_large_prefix”
云數據庫默認值 ：“OFF”。
作用 ：InnoDB表允許單列索引的最大長度。
說明僅RDS for MySQL 5.6版本支持該參數。
影響 ：在DDL執行時修改該參數，有可能會導致主從復制異常，請謹慎修改。如果必須要修改，請根據以下場景設置數據庫參數：
參數值從OFF變為ON的設置順序：先修改只讀庫，后修改主庫。
參數值從ON變為OFF的設置順序：先修改主庫，后修改只讀庫。
修改性能參數
若干參數相關說明如下：
- “innodb_spin_wait_delay”和“query_alloc_block_size”依賴于實例的規格，設置過大時，可能會影響數據庫的使用。
- “max_connections”參數值設置較小，將影響數據庫訪問。
- “innodb_buffer_pool_size”、“max_connections”和“back_log”參數依賴于實例的規格，實例規格不同對應其默認值也不同。因此，這些參數在用戶未設置前顯示為“default”。
- “innodb_io_capacity_max”、“innodb_io_capacity”參數依賴于磁盤類型，用戶未設置前顯示為“default”。
參數修改限制
- “innodb_adaptive_hash_index”和“innodb_buffer_pool_size”參數同時修改時，“innodb_adaptive_hash_index”的值由“OFF”改為“ON”會失敗。
- “innodb_buffer_pool_size”參數值必須是“innodb_buffer_pool_instances”和“innodb_buffer_pool_chunk_size”參數值乘積的整數倍。
- “innodb_buffer_pool_instances”參數值設置為“2”時，“innodb_buffer_pool_size”值必須大于等于1GB。
- “max_prepared_stmt_count”：對于MySQL 8.0版本，如果內核版本低于8.0.18，參數取值上限為1048576，超過會修改失敗。
RDS支持的最大IOPS是多少
關系型數據庫服務支持的IOPS取決于云硬盤（Elastic Volume Service，簡稱EVS）的IO性能，具體請參見《云硬盤產品介紹》中“磁盤類型及功能特性”的內容。
如何提高RDS數據庫的查詢速度
可以參考如下建議：
- 如果產生了慢日志，可以通過查看慢日志來確定是否存在運行緩慢的SQL查詢，以及各個查詢的性能特征，從而定位查詢運行緩慢的原因。
- 查看云數據庫RDS實例的CPU使用率指標，協助定位問題。
- 可以創建只讀實例專門負責查詢，減輕主實例負載，分擔數據庫壓力。
- 如果是實例規格較小但負載過高，您可以提高CPU/內存規格。
- 多表關聯查詢時，關聯字段要加上索引。
- 可以指定字段或者添加where條件進行查詢，避免用select*語句進行全表掃描。
排查RDS for MySQL CPU使用率高的原因和解決方法
使用云數據庫RDS for MySQL時，如果您的CPU使用率很高或接近100%，會導致數據讀寫處理緩慢、連接緩慢、刪除出現報錯等，從而影響業務正常運行。
注意
解決方法一
分析慢SQL日志以及CPU使用率指標來定位效率低的查詢，再優化查詢效率低的語句。
- 查看慢SQL日志來確定是否存在運行緩慢的SQL查詢以及各個查詢的性能特征（如果有），從而定位查詢運行緩慢的原因。
- 查看關系型數據庫實例的CPU使用率指標，協助定位問題。
- 創建只讀實例專門負責查詢。減輕主實例負載，分擔數據庫壓力。
- 多表關聯查詢時，關聯字段要加上索引。
- 盡量避免用select*語句進行全表掃描，可以指定字段或者添加where條件。
解決方法二
分析當前數據庫運行線程來定位效率低的查詢，再通過數據管理服務（Data Admin Service，簡稱DAS）提供的建議優化這些SQL語句來降低實例的CPU使用率以提升系統效率。
步驟 1 連接RDS for MySQL實例。
步驟 2 執行以下命令，查看當前執行操作，定位效率低的查詢。
show full processlist
查看Time和State列，如上圖，長事務的ID為4038566。
步驟 3 得到需要優化的查詢后，您可以使用數據管理服務（Data Admin Service，簡稱DAS），通過SQL診斷查詢，您可獲知資源消耗大、執行耗時長、執行次數頻繁的SQL語句。可根據診斷建議進行優化，保持數據庫性能的穩定性。
1、登錄到數據管理服務控制臺。
2、在左側導航欄，選擇“DBA智能運維 > 實例列表”。
3、在實例上單擊“詳情”。
4、選擇“SQL > SQL診斷”。
5、選擇“數據庫”，輸入SQL語句，單擊“SQL診斷”。
6、查看診斷詳情，獲取語句優化建議。
說明
暫僅支持 select/insert/update/delete 語句診斷，其中insert 必須帶 select 子句。
暫不支持使用視圖的語句。
SQL診斷功能會獲取相關表結構和數據分布信息（非原始數據），該信息僅用于診斷邏輯，不會存儲到DAS服務器。
獲取表結構和數據分布信息的過程中，可能會對實例帶來額外負載，但對性能影響甚微。
SQL診斷歷史是唯一存儲在DAS服務器上的數據，如果執行刪除操作后，也將徹底從服務器上刪除。
----結束
RDS for MySQL數據庫內存使用率過高怎么處理
對于用戶核心業務相關的庫
請擴容實例規格。
對于非用戶核心業務相關的庫
查看本地計算機的內存使用率，如果使用率曲線持續平緩，則無需處理。
對于用戶核心業務相關但是數據庫規格配置很高的庫
- 在業務低峰期，將數據庫參數“performance_schema”的值調整為“OFF”，對于RDS for MySQL 5.6及以下版本，需要重啟數據庫才能生效。
- 通過CES監控面板，觀察實例的內存使用情況。
如果實例的內存使用率仍持續保持較高：
- 請擴容實例規格。
- 調整數據庫參數“innodb_buffer_pool_size”的值，參數建議值見下表，實際可修改的取值范圍以RDS界面為準。
表 不同內存規格對應的參數建議值
| 內存（GB） | 5.6建議值 | 5.7建議值 | 8.0建議值 |
|---|---|---|---|
| 2 | 536,870,912 Byte（512 MB） | 536,870,912 Byte（512 MB） | 536,870,912 Byte（512 MB） |
| 4 | 1,073,741,824 Byte（1 GB） | 1,073,741,824 Byte（1 GB） | 1,073,741,824 Byte（1 GB） |
| 8 | 4,294,967,296 Byte（4 GB） | 4,294,967,296 Byte（4 GB） | 5,368,709,120 Byte（5 GB） |
| 16 | 8,589,934,592 Byte（8 GB） | 8,589,934,592 Byte（8 GB） | 9,663,676,416 Byte（9 GB） |
| 32 | 22,548,578,304 Byte（21 GB） | 22,548,578,304 Byte（21 GB） | 21,474,836,480 Byte（20 GB） |
| 64 | 47,244,640,256 Byte（44 GB） | 47,244,640,256 Byte（44 GB） | 47,244,640,256 Byte（44 GB） |
| 128 | 96,636,764,160 Byte（90 GB） | 94,489,280,512 Byte（88 GB） | 94,489,280,512 Byte（88 GB） |
| 192 | 146,028,888,064 Byte（136 GB） | 146,028,888,064 Byte（136 GB） | 146,028,888,064 Byte（136 GB） |
| 256 | 193,273,528,320 Byte（180 GB） | 193,273,528,320 Byte（180 GB） | 193,273,528,320 Byte（180 GB） |
| 384 | 298,500,227,072 Byte（278 GB） | 300,647,710,720 Byte（280 GB） | 300,647,710,720 Byte（280 GB） |
| 512 | 412,316,860,416 Byte（384 GB） | 412,316,860,416 Byte（384 GB） | 412,316,860,416 Byte（384 GB） |
說明
請根據業務實際情況，調整參數“innodb_buffer_pool_size”的值。
MySQL本身具有內存動態平衡機制，內存使用率在90%以下您可無需關注，同時建議內存使用率告警閾值設置不低于90%。
在業務運行中緩沖池內存會逐漸增大至“innodb_buffer_pool_size”的值，可通過監控指標“緩沖池利用率”查看緩沖池內存的增長趨勢。
RDS for MySQL的內存分配可劃分為Engine層與Server層。
Engine層的內存包括InnoDB Buffer Pool、Log Buffer、Full Text Index Cache，其中InnoDB Buffer Pool為常駐內存，占用內存較大。
InnoDB緩沖池是一個內存區域，用于保存InnoDB表、索引和其他輔助緩沖區的緩存數據，可以通過參數“innodb_buffer_pool_size”定義緩沖池大小。
Server層的內存占用較高的包括Thread Cache、BinLog Cache、Sort Buffer、Read Buffer、Join Buffer等線程緩存，這類緩存非常駐內存，往往會隨著連接關閉而釋放。
以上內存的分配導致RDS for MySQL實例運行時內存使用率在80%左右。
RDS for MySQL慢SQL問題處理
SQL異常
- 原因及現象
SQL異常的原因很多，例如庫表結構設計不合理、索引缺失、掃描行數太多等。
您可以在控制臺的慢日志頁面，下載并查看執行緩慢的SQL，慢SQL的執行耗時等信息。
- 解決方案
根據實際業務情況優化SQL。
實例瓶頸
- 原因及現象
實例到達瓶頸的原因一般有如下幾種：
業務量持續增長而沒有擴容。
硬件老化，性能有損耗。
數據量一直增加，數據結構也有變化，導致原來不慢的SQL變成慢SQL。
您可以在控制臺的查看實例的資源使用情況。如果資源使用率各項指標都接近100%，可能是實例到達了瓶頸。
- 解決方案
確認實例到達瓶頸后，建議升級實例規格。
版本升級
- 原因及現象
實例升級版本可能會導致SQL執行計劃發生改變，執行計劃中連接類型從好到壞的順序是system>const>eq_ref>ref>fulltext>ref_or_null>index_merge>unique_subquery>index_subquery>range>index>all。更多信息，請參見。
range和index連接類型時，如果SQL請求變慢，業務又不斷重發請求，導致并行SQL查詢比較多，會導致應用線程釋放變慢，最終連接池耗盡，影響整個業務。
您可以在控制臺的查看實例的當前連接數指標。
- 解決方案
根據執行計劃分析索引使用情況、掃描的行數等，預估查詢效率，重構SQL語句、調整索引，提升查詢效率。
參數設置不當
- 原因及現象
部分參數（如innodb_spin_wait_delay）設置不當會導致性能變慢。
您可以在控制臺查看實例的參數修改情況。
- 解決方案
調整相關參數，使其適合業務場景。
批量操作
- 原因及現象
如果有大批量的數據導入、刪除、查詢操作，會導致SQL執行變慢。
您可以在控制臺查看實例的磁盤總大小、磁盤使用量、IOPS等指標。
- 解決方案
在業務低峰期執行大批量操作，或將大批量操作拆分后分批執行。
定時任務
- 原因及現象
如果實例負載隨時間有規律性變化，可能是存在定時任務。
您可以在控制臺查看實例的Delete語句執行頻率、Insert語句執行頻率、Insert_Select語句執行頻率、Replace語句執行頻率、Replace_Selection語句執行頻率、Select語句執行頻率、Update語句執行頻率等指標，判斷是否有規律性變化。
- 解決方案
調整定時任務的執行時間，建議在業務低峰期執行，并修改可維護時間段為業務低峰期。
