RDS for MySQL参数调优建议
说明数据库参数是数据库系统运行的关键配置信息，设置不合适的参数值可能会影响业务。本文列举了一些重要参数说明，更多参数详细说明，请参见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。更多信息，请参见MySQL官方文档。
range和index连接类型时，如果SQL请求变慢，业务又不断重发请求，导致并行SQL查询比较多，会导致应用线程释放变慢，最终连接池耗尽，影响整个业务。
您可以在控制台的查看实例的当前连接数指标。
- 解决方案
根据执行计划分析索引使用情况、扫描的行数等，预估查询效率，重构SQL语句、调整索引，提升查询效率。
参数设置不当
- 原因及现象
部分参数（如innodb_spin_wait_delay）设置不当会导致性能变慢。
您可以在控制台查看实例的参数修改情况。
- 解决方案
调整相关参数，使其适合业务场景。
批量操作
- 原因及现象
如果有大批量的数据导入、删除、查询操作，会导致SQL执行变慢。
您可以在控制台查看实例的磁盘总大小、磁盘使用量、IOPS等指标。
- 解决方案
在业务低峰期执行大批量操作，或将大批量操作拆分后分批执行。
定时任务
- 原因及现象
如果实例负载随时间有规律性变化，可能是存在定时任务。
您可以在控制台查看实例的Delete语句执行频率、Insert语句执行频率、Insert_Select语句执行频率、Replace语句执行频率、Replace_Selection语句执行频率、Select语句执行频率、Update语句执行频率等指标，判断是否有规律性变化。
- 解决方案
调整定时任务的执行时间，建议在业务低峰期执行，并修改可维护时间段为业务低峰期。
