MySQL实例配置最佳实践

MySQL实例配置最佳实践概述

该部分主要从MySQL RDS 套餐选择MySQL数据库参数设置两个方面来为用户提供一些套餐选择和参数配置建议,帮助用户尽快上手配置RDS实例。

MySQL RDS 套餐选择最佳实践

百度公有云RDS MySQL为用户提供的MySQL版本为常见的5.5、5.6版本及最新的5.7版本。同时有丰富的产品套餐供用户选择,产品套餐规格从单核256M内存到20核64G内存。用户可根据自身的业务规模和数据量选择相应的套餐,以下是一些建议,供用户在创建MySQL RDS实例时参考。

MySQL版本选择

  • MySQL 5.5
    当前较为流行版本,从兼容性角度出发,百度公有云RDS提供了该版本的MySQL。如果用户从自有MySQL 5.5数据库迁移到百度RDS MySQL数据库中,从兼容性角度考虑,可以选择该版本,但是对于新建MySQL数据库的用户,不建议选择该版本,推荐选择MySQL 5.6。

  • MySQL 5.6
    当前主流版本,较MySQL 5.5相比有诸多新增功能和性能改进。大多数情况下,如果没有特殊原因,用户应该选择该版本MySQL。同时,该版本的MySQL还支持半同步复制,为用户数据提供更高的可靠性保障。关于半同步,可参考半同步复制的说明文档。

  • MySQL 5.7
    目前最新的稳定版本,较之前的版本相比,增强了安全性能,提供了更丰富的功能,例如更多的SQL Mode,原生支持JSON数据类型,基于组提交的并行复制,组复制(Group Replication)等,以及多项性能改进。详细的新功能和性能提升列表,可参考MySQL官方文档。对新功能和性能要求较高的用户可以选择该版本的MySQL。与5.6版本一样,5.7版本的MySQL也支持半同步复制。

RDS MySQL套餐选择建议

  • CPU和内存的选择
产品系列 CPU/核 内存/G 最大本地磁盘 最大连接数 参考QPS
小微型 1 1 200G 300 2400
小微型 1 2 500G 560 3500
标准型 1 4 1000G 1050 4500
标准型 2 8 1000G 2000 6000
标准型 4 16 3000G 4000 10000
标准型 8 32 3000G 8000 18000
标准型 16 64 3000G 16000 28800
标准型 32 128 3000G 32000 34000
内存增强型 1 8 1000G 2000 5000
内存增强型 2 16 3000G 4000 7000
内存增强型 4 32 3000G 8000 12000
内存增强型 8 64 3000G 16000 20000
内存增强型 16 128 3000G 32000 30000
内存增强型 32 256 3000G 64000 40000
内存增强型 56 480 3000G 100000 48000
CPU增强型 2 4 1000G 1050 5000
CPU增强型 6 8 1000G 2000 8000
CPU增强型 8 16 3000G 4000 12000
CPU增强型 12 24 3000G 6000 16000
CPU增强型 16 32 3000G 8000 20000
CPU增强型 20 48 3000G 12000 26000
CPU增强型 20 64 3000G 16000 30000

每个系列的适用场景请参考产品系列

  • 磁盘容量的选择

    百度RDS MySQL为用户提供了从5GB到1TB容量的本地高性能SSD磁盘存储,用户可以根据实际的业务需要选择合适的磁盘大小。

    建议:选择套餐时用户需要考虑随着业务的增长,对数据库的数据处理和存储要求会随之增长。当然,百度RDS for MySQL也提供了套餐升级功能,用户可以随时对RDS for MySQL套餐配置进行调整和更改。

游戏类型应用的RDS套餐选择建议

目前大多数游戏都采用了分区分服的策略,针对这一特点,在数据库选择上,推荐使用全局数据库配合分表分库DRDS数据库的方案,即:

  • 登录数据、商城、聊天等全局数据统一存放在全局数据库中;
  • 游戏数据按照分区分服存在不同数据库分片的不同分表中;

如果希望了解分布式关系型数据库DRDS的详细情况,请查看DRDS相关文档,或前往DRDS主页申请免费试用。

MySQL数据库参数设置最佳实践

MySQL有大量的参数影响数据库运行时的行为及性能表现,接下来我们介绍一些常见参数的说明及调优:

  • innodb_concurrency_tickets

    每个进入InnoDB引擎的线程获得的ticket数量。线程每进入InnoDB一次,就会消费一个ticket,在ticket消费完之前,该线程重新请求时无须再进行前面线程是否达到并发限制的检查。在小事务频繁的场景,innodb_concurrency_tickets可以设置的小些;在大事务频繁的场景,innodb_concurrency_tickets可以设置的大些

  • innodb_max_dirty_pages_pct

    InnoDB脏页率最大值,超过这个值,InnoDB会尝试刷新缓冲池数据。减小innodb_max_dirty_pages_pct会加快InnoDB刷脏页的频率

  • innodb_old_blocks_pct

    指定Innodb的缓冲池里旧数据部分的比例。一般来讲,如果有大量全表扫描,可以调小innodb_old_blocks_pct,使数据块进入少量sublist of old blocks区域,并移动到sublist of new blocks区域,从而让更多的热数据保存在Buffer Pool中

  • innodb_old_blocks_time

    指定数据从old sublist移动到new sublist的延时值,单位是毫秒。同innodb_old_blocks_pct,如果有大量的全表扫描,可以调大innodb_old_blocks_time,尽量延迟Buffer Pool中的热点数据被移除

  • innodb_purge_threads

    InnoDB后台清理线程个数。如果数据库的写压力比较大的话。可以调大innodb_purge_threads,增大purge并发的线程数量

  • innodb_stats_sample_pages

    InnoDB收集表的行数等信息所抽样的索引页数,增大innodb_stats_sample_pages一定程度上会提高统计信息的准确度,但同时也会增大ANALYZE TABLE的执行时间

  • innodb_flush_log_at_trx_commit

    0:log buffer大约每秒一次写入到Redo日志文件并刷写到磁盘,如果MySQL崩溃,通常会损失最后一秒的事务

    1:当事务提交前,保证事务的Redo日志刷写到磁盘,无论是MySQL还是操作系统崩溃,都不会丢失数据

    2:每次事务提交会写入Redo日志文件,但不会立即刷写到磁盘,大约每秒一次刷写到磁盘,如果操作系统崩溃,通常会损失最后1秒的事务