MYSQL 写入性能参数优化

最新推荐文章于 2024-09-20 09:09:37 发布
最新推荐文章于 2024-09-20 09:09:37 发布
阅读量1.6k 收藏 3
点赞数
分类专栏： MYSQL
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/zhwxl_zyx/article/details/113515118
版权

写入性能优化的一些参数

说完了如何修改和查看RDS参数，我们接下来看一下一些和写入性能相关的参数，限于篇幅，我们不能介绍所有的MYSQL参数。

innodb_buffer_pool_size

在MYSQL中buffer pool用来缓存表和索引的数据，以便加速对数据的处理。如果在buffer在pool中无法获取数据（所谓cache miss），那么就会产生磁盘的随机IO请求，这会降低处理速度，所以配置一个合适大小的buffer pool对性能至关重要。RDS中innodb_buffer_pool_size会设置为{DBInstanceClassMemory*3/4}。

我们可以通过show engine innodb status \G和SHOW GLOBAL STATUS命令观察innodb_buffer_pool_size设置是否合适。

通过show engine innodb status \G我们可以看到free buffers、buffer pool hit rate以及evicted without access（数据被加载到buffer pool没有被访问前就又被推出buffer pool）。

  • 如果较长时间内即使业务高峰期，free buffers都很大，buffer pool hit rate 高于99.5%，evicted without access为0，则innodb_buffer_pool_size可能过量设置了。
  • 如果较长时间内尤其业务高峰期，free buffers都很小，buffer pool hit rate 低于99%，evicted without access不为0，则说明innodb_buffer_pool_size设置得太小，需要增大。

 

show global status where variable_name in (‘Innodb_buffer_pool_read_requests’, ‘Innodb_buffer_pool_reads’); 我们可以关注以下数据，来判断innodb_buffer_pool_size设置的是否合适。

  • innodb_buffer_pool_reads表示InnoDB缓冲池无法满足的请求数。需要从磁盘中读取。
  • innodb_buffer_pool_read_requests表示从内存中逻辑读取的请求数。
  • Innodb_buffer_pool_read_requests / (Innodb_buffer_pool_read_requests + Innodb_buffer_pool_reads) * 100 = InnoDB Buffer Pool hit ratio

 

注意：对于 MySQL 5.7，管理 InnoDB 缓冲池的方式当前存在错误https://bugs.mysql.com/bug.php?id=79379。MySQL 5.7 可能将 innodb_buffer_pool_size 参数的值调整为较大的值，这会导致 InnoDB 缓冲池增长得过大并占用过多内存。此效果会导致 MySQL 数据库引擎停止运行或阻止 MySQL 数据库引擎启动。可用内存较少的数据库实例类更易出现此问题。要解决此问题，请将 innodb_buffer_pool_size 参数的值设置为 innodb_buffer_pool_instances 参数值和 innodb_buffer_pool_chunk_size 参数值的积的倍数。例如，您可以将 innodb_buffer_pool_size 参数值设置为 innodb_buffer_pool_instances 参数值和 innodb_buffer_pool_chunk_size 参数值的积的 8 倍，如以下示例所示。

innodb_buffer_pool_chunk_size = 536870912

innodb_buffer_pool_instances = 4

innodb_buffer_pool_size = (536870912 * 4) * 8 = 17179869184

innodb_log_file_size

在mysql 5.5和5.5以前innodb的logfile最大设置为4GB,在5.6以后的版本中innodb_log_file_size * innodb_log_files_in_group（每个log group中日志文件的个数，默认为2）不能超过512GB。innodb的logfile就是事务日志，用来在mysql 崩溃后的恢复，设置合理的大小对于mysql的性能非常重要。logfile大小对于性能的影响主要体现在checkpoint上，对于 checkpoint的原理可以参考相关的关系数据库理论，更大的logfile大小可以减少checkpoint的次数，减少disk I/O，但是也会增加崩溃后恢复时间。

在MYSQL RDS默认参数组中，innodb_log_file_size默认值为134,217,728 (大约128 MB)，通常对您的应用来说该数值嫌小。那么设置多大的logfile合适呢？ 通常我们建议innodb_log_file_size * innodb_log_files_in_group要可以承载我们业务高峰期一个小时的日志量，我们可以用命令show engine innodb status\G select sleep(60); show engine innodb status\G 计算每分钟的日志量，进而确定参数的合适大小。此外，基于Bug #69477，日志文件大小应该至少是数据库中最大的BLOB的大小的十倍。

 

 

 

5.0以上版本的MYSQL也可以通过以下命令去查询一分钟内生成日志的大小：

show global status like ‘Innodb_os_log_written%’;

 

 

innodb_io_capacity与innodb_io_capacity_max

innodb_io_capacity决定了innodb后台任务（譬如从buffer pool刷新页面或从change pool合并页面）每秒可用的IO操作次数（IOPS）。innodb_io_capacity默认值是200， 可选范围100–18,446,744,073,709,551,615，而innodb_io_capacity_max是当刷新滞后时，后台任务可以执行的最大IOPS，可选范围100–18,446,744,073,709,551,615，如果您设置了innodb_io_capacity但没有设置innodb_io_capacity_max，则innodb_io_capacity_max默认是innodb_io_capacity的两倍，。

关于这两个参数，若你真的需要对它进行调整，最好的方法是要了解系统可以支持多大的 IOPS。对于SSD我们可以设置innodb_io_capacity为1000，虽然可以设置很大值，但是innodb_io_capacity一般很少设置超过20000，除非您已经尝试过较低的值否则不要设置较大的值。

那么我们如何判断脏页刷新不够快呢？我们可以通过SHOW GLOBAL STATUS LIKE ‘Innodb_buffer_pool_%’;命令，如下图所示，脏页在buffer中的百分比就是Innodb_buffer_pool_pages_dirty/Innodb_buffer_pool_pages_total * 100%

 

  • Innodb_buffer_pool_pages_data 和Innodb_buffer_pool_bytes_data: buffer pool中buffer总数。
  • Innodb_buffer_pool_pages_dirty 和Innodb_buffer_pool_bytes_dirty: buffer pool中脏buffer的数量。
  • Innodb_buffer_pool_pages_total: buffer pool总页数。

如果使用了information_schema，我们也可以通过以下语句来查询

mysql> SELECT dirty.Value AS 'Dirty Pages', total.Value AS 'Total Pages', ROUND(100*dirty.Value/total.Value, 2) AS 'Dirty Pct' FROM (SELECT VARIABLE_VALUE AS Value FROM information_schema.GLOBAL_STATUS WHERE VARIABLE_NAME = 'Innodb_buffer_pool_pages_total') AS total INNER JOIN (SELECT VARIABLE_VALUE AS Value FROM information_schema.GLOBAL_STATUS WHERE VARIABLE_NAME = 'Innodb_buffer_pool_pages_dirty') AS dirty;
+-------------+-------------+-----------+
| Dirty Pages | Total Pages | Dirty Pct |
+-------------+-------------+-----------+
| 0         | 131072        |      0.00 |
+-------------+-------------+-----------+
1 row in set (0.00 sec)

总之，如果脏页占比长时间较高且从监控看IO有较大余裕，则可调大innodb_io_capacity，但不要一下调整过大，要逐步提高。

innodb_flush_log_at_trx_commit

innodb_flush_log_at_trx_commit定义数据库写log buffer到磁盘的频率以及方式 ，磁盘写入会影响性能，故而此参数让您可以在性能和持久性之间做出选择。

  • 如果innodb_flush_log_at_trx_commit设置为0，每秒一次会将log buffer写入log file（这时数据只是从innodb内存到了操作系统的cache，依然没有进入磁盘）， log file的flush(刷到磁盘)操作也同时进行。该模式下，在事务提交的时候，不会主动触发写入磁盘的操作。
  • 如果innodb_flush_log_at_trx_commit设置为1，每次事务提交时MySQL都会把log buffer的数据写入log file，并且flush(刷到磁盘)中去。
  • 如果innodb_flush_log_at_trx_commit设置为2，每次事务提交时MySQL都会把log buffer的数据写入log file.但是flush(刷到磁盘)操作并不会同时进行。该模式下,MySQL会每秒执行一次 flush(刷到磁盘)操作。

当设为0和2的时候，flush操作不能100%保证，所以在崩溃或断电的时候可能会丢失最后一秒的数据，而1是默认也是最安全的设置，保证commit的数据不会丢失。MYSQL RDS默认 innodb_flush_log_at_trx_commit也是1，这会对性能有消极影响但除非您可以接受丢失数据，否则不建议修改。

sync_binlog

sync_binlog 控制 MySQL server 将 binary log 同步到磁盘的频率，MYSQL RDS默认设置为最安全的1，但是同样会对性能有消极影响，除非您可以接受丢失数据，否则不建议修改。

  • sync_binlog=0: MySQL不控制binlog的刷新，由文件系统自己控制它的缓存的刷新。这时候的性能是最好的，但是风险也是最大的。因为一旦系统崩溃，在binlog_cache中的所有binlog信息都会被丢失。
  • sync_binlog=1: 这是最安全的设置，表示每次事务提交，MySQL都会把binlog刷下去，不过最安全也是性能损耗最大的设置，尤其对高并发的场景sync_binlog设置为0和1之间写入性能相差会很大，甚至达到5倍之多。
  • sync_binlog=N, N 是 0 和1以外的正整数: binary log 会在收集N 个binary log commit groups 之后同步，同样在系统崩溃的时候 ，可能会丢失数据，N越大性能越好但同时丢失数据的风险也越大。

tmp_table_size 与max_heap_table_size

MYSQL在很多场景譬如UNION操作，子查询，排序分组操作中都可能会生成temporary table，我们通过 EXPLAIN 输出执行计划的Extra列可以看到SQL是否使用了temporary table。temporary table的最大大小由tmp_table_size 与max_heap_table_size其中较小的值决定（MYSQL RDS这两个参数默认值都是16777216即16M），temporary table在大小未超过上限时创建在内存中，一旦超过该上限，temporary table就会自动转为磁盘上的表，这将增加磁盘IO和消耗的时间。我们可能都遇到过复杂查询执行很长时间，从show full processlist可以看到copying to tmp table on disk的状态，这就说明我们的temporary table超过了上限，转为了磁盘上的表。

我们可以通过命令SHOW GLOBAL STATUS LIKE ‘Created_tmp%’;查看内存和磁盘中temporary table得数量，我们可以通过 Created_tmp_disk_tables 和 Created_tmp_tables 了解在磁盘中temporary table的比例。

如果您的应用有大量复杂查询，Created_tmp_disk_tables 比例居高不下，IO成为系统瓶颈而内存又有较大余裕，您可以考虑逐步调大tmp_table_size 与max_heap_table_size。但是请注意，这会给内存带来压力，此外，某些场景下，temporary table一定会创建在磁盘而不是内存中，譬如：

  • 表中存在BLOB或文本列。这包括具有字符串值的用户定义变量，依据列值是二进制还是非二进制字符串而分别被视为BLOB或文本列。
  • 在一个GROUP BY或DISTINCT子句中存在大于512字节(二进制字符串)或大于512字符(非二进制字符串)的任何字符串列。
  • 使用UNION或UNION ALL，且选择列表中存在最大长度大于512(二进制字符串为字节，非二进制字符串为字符)的任何字符串列。
  • SHOW列和DESCRIBE语句使用BLOB作为某些列的类型，因此用于结果的临时表是磁盘上的表

 

foreign_key_checks与unique_checks

当我们对MYSQL RDS进行大批量数据导入或加载，尤其涉及大表时，我们可以通过暂时关闭外键和唯一约束检查来提高插入性能，但是这会带来潜在的风险，您务必要确保相应的数据一致和唯一性。否则约束检查不能通过。

我们可以按以下方式进行数据库导入：

SET FOREIGN_KEY_CHECKS = 0;
SET UNIQUE_CHECKS = 0;
SET AUTOCOMMIT = 0;
... SQL加载语句 ...
SET foreign_key_checks=1;
SET UNIQUE_CHECKS =1;
commit;

Innodb_read_io_threads 和 Innodb_write_io_threads

innodb_read_io_threads and innodb_write_io_threads决定了InnoDB使用多少后台线程来处理各种类型的IO请求。通过这个配置InnoDB可以有更好的扩展性，每个后台进程可以处理256个IO请求，InnoDB希望可以平衡请求的负载。两个参数有效值范围是1-64，默认值是4。参数决定后台进程数，但是linux系统默认会设置innodb_use_native_aio 不为0，启动异步IO，就会突破参数限制

如果您有高端的IO系统，且在SHOW ENGINE INNODB STATUS的输出中看到64 × innodb_read_io_threads的pending read requests，那么提升innodb_read_io_threads的值会对提升性能有帮助。

 

测试

 硬件环境

本次测试将通过sysbench软件对AWS MYSQL5.6 RDS default参数组以及调整后的参数组进行压测，比对调优效果。请注意：sysbench测试是用来辅助我们判断系统性能的一个方法，用您的实际业务进行压测永远更有针对性。而且在性能测试中，不同的资源配置（包括测试客户端，数据库本身以及网络等），参数配置乃至测试流程都会导致不同的结果，所以进行比对分析永远要先统一测试环境、流程才有意义。

随着软件迭代，本文中描述的测试流程可能需要更新，请读者把握测试流程和指标含义，在工作中按实际情况进行调整。

本文所用硬件环境如下：

2个sysbench客户端配置如下：

机型vCPU内存(GiB)磁盘IOPS
r5.2xlarge EC2864IO1 SSD 50G2020

数据库配置如下：数据库开启了multi-AZ,保证数据库高可用,但是会对写入性能有较大影响

数据库instance classvCPU内存(GiB)磁盘IOPS多AZ
MYSQL5.6 RDSdb.r5.2xlarge864IO1 SSD 500G18000是

参数调整

根据硬件环境以及测试时产生的日志量，对参数做了针对性调整，有些参数需要数据库重启才能生效，请在执行相应测试步骤前确认参数值。

请注意：下面的参数仅仅针对本测试中的硬件环境和测试工作量负载，并不具有普遍性，请读者理解参数的含义，根据自身环境和工作负载进行相应配置。正如前述，除非您可以接受丢失数据，否则不建议修改innodb_flush_log_at_trx_commit、sync_binlog等参数为了性能而牺牲安全性，所以本次测试没有对这两个参数进行修改，如果您有类似需求，可以根据本文提供的方法自行测试。

参数默认值调整后的值
innodb_io_capacity2002000
innodb_io_capacity_max200018000
innodb_log_file_size1342177284294967296
innodb_read_io_threads48
innodb_write_io_threads48
innodb_flush_log_at_trx_commit11
sync_binlog11
多可用区是是

 

注意：因为sysbench1.0.18会有大量prepared statement，所以要设置max_prepared_stmt_count为最大值1048576保证测试顺利进行，否则初始化时可能遇到错误FATAL: MySQL error: 1461 “Can’t create more than max_prepared_stmt_count statements (current value: 16382)”

测试环境准备

在2台测试客户端安装sysbench1.0.18

1.从git中下载sysbench

sudo yum install gcc gcc-c++ autoconf automake make libtool bzr mysql-devel git mysql
git clone https://github.com/akopytov/sysbench.git

 

2.打开sysbench目录

cd sysbench

 

3.切换到sysbench 1.0.18版本，运行autogen.sh

git checkout 1.0.18
sudo ./autogen.sh

 

4.编译

sudo ./configure --prefix=/usr --mandir=/usr/share/man
sudo make
sudo make install

 打开限制

开始测试前，需要在Sysbench客户端执行 以下配置，告诉Linux kernel可以用所有的CPU cores 去处理 packets（默认只可以用两个）,且减少cores 之间的context switching. 这两个设置是为了用更少的Sysbench 客户端达成吞吐目标.( ffffffff表示使用32个核。请根据实际配置修改，例如实际只有8核，则输入ff)

sudo sh -c 'for x in /sys/class/net/eth0/queues/rx-*; do echo ff > $x/rps_cpus; done'
sudo sh -c "echo 32768 > /proc/sys/net/core/rps_sock_flow_entries"
sudo sh -c "echo 4096 > /sys/class/net/eth0/queues/rx-0/rps_flow_cnt"
sudo sh -c "echo 4096 > /sys/class/net/eth0/queues/rx-1/rps_flow_cnt"
vim /etc/security/limits.conf
*                              soft    nofile  65536
*                              hard    nofile  65536
*                              soft    nproc  65536
*                              hard    nproc  65536

 

 测试流程

只读负载测试

测试数据注入

首先通过sysbench客户端在测试数据库上生成测试表，这里生成250个表，每个表有行数25000条，您也可以根据您的目标，调整表的数目和大小，请替换<>之中的各种连接信息，再执行命令，如果您直接从blog拷贝命令请注意格式。后续命令的注意事项相同，将不再赘述

sysbench --db-driver=mysql --mysql-host=<mysql host> --mysql-port=<port> --mysql-user=<username> --mysql-password=<password> --mysql-db=<dbname> --table_size=25000 --tables=250 --events=0 --time=600  oltp_read_only prepare

 

测试

在所有sysbench client同时执行命令模拟负载，每次持续20分钟，同时从console查看数据库CPU，IO，网络等metrics。在这里我们将通过修改num_threads参数连续测试2*32, 2*64,2*128,2*256多种并发连接的场景。

sysbench --db-driver=mysql --mysql-host=<mysql host>  --mysql-user=<username> --mysql-password=<password> --mysql-port=<port>  --mysql-db=<dbname>   --table_size=25000 --tables=250 --events=0 --max-time=1200   --threads=32 --percentile=95 --range_selects=0 --skip-trx=1 --report-interval=20 oltp_read_only run >> <dbname>_read.log
sysbench --db-driver=mysql --mysql-host=<mysql host>  --mysql-user=<username> --mysql-password=<password> --mysql-port=<port>  --mysql-db=<dbname>   --table_size=25000 --tables=250 --events=0 --max-time=1200   --threads=64 --percentile=95 --range_selects=0 --skip-trx=1 --report-interval=20 oltp_read_only run >> <dbname>_read.log
sysbench --db-driver=mysql --mysql-host=<mysql host>  --mysql-user=<username> --mysql-password=<password> --mysql-port=<port>  --mysql-db=<dbname>   --table_size=25000 --tables=250 --events=0 --max-time=1200   --threads=128 --percentile=95 --range_selects=0 --skip-trx=1 --report-interval=20 oltp_read_only run >> <dbname>_read.log
sysbench --db-driver=mysql --mysql-host=<mysql host>  --mysql-user=<username> --mysql-password=<password> --mysql-port=<port>  --mysql-db=<dbname>   --table_size=25000 --tables=250 --events=0 --max-time=1200   --threads=256 --percentile=95 --range_selects=0 --skip-trx=1 --report-interval=20 oltp_read_only run >> <dbname>_read.log

 

清除测试数据

测试后清除数据命令如下：

sysbench --db-driver=mysql --mysql-host=<mysql host> --mysql-port=<port> --mysql-user=<username> --mysql-password=<password> --mysql-db=<dbname> --table_size=25000 --tables=250 --events=0 --time=600  oltp_read_only cleanup

 只写负载测试

数据注入

sysbench --db-driver=mysql --mysql-host=<mysql host> --mysql-port=<port> --mysql-user=<username> --mysql-password=<password> --mysql-db=<dbname> --table_size=25000 --tables=250 --events=0 --time=600  oltp_write_only prepare

 

测试

同样地，在所有sysbench client同时执行命令模拟只写负载，每次持续20分钟，同时从console查看数据库CPU，IO，网络等metrics。在这里我们将通过修改num_threads参数连续测试4*32,4*64,4*128和4*256多种并发连接的场景。

sysbench --db-driver=mysql --mysql-host=<mysql host>  --mysql-user=<username> --mysql-password=<password> --mysql-port=<port>  --mysql-db=<dbname>   --table_size=25000 --tables=250 --events=0 --max-time=1200   --threads=32 --percentile=95  --report-interval=20 oltp_write_only run >> <dbname>_write.log
sysbench --db-driver=mysql --mysql-host=<mysql host>  --mysql-user=<username> --mysql-password=<password> --mysql-port=<port>  --mysql-db=<dbname>   --table_size=25000 --tables=250 --events=0 --max-time=1200   --threads=64 --percentile=95  --report-interval=20 oltp_write_only run >> <dbname>_write.log
sysbench --db-driver=mysql --mysql-host=<mysql host>  --mysql-user=<username> --mysql-password=<password> --mysql-port=<port>  --mysql-db=<dbname>   --table_size=25000 --tables=250 --events=0 --max-time=1200   --threads=128 --percentile=95  --report-interval=20 oltp_write_only run >> <dbname>_write.log
  sysbench --db-driver=mysql --mysql-host=<mysql host>  --mysql-user=<username> --mysql-password=<password> --mysql-port=<port>  --mysql-db=<dbname>   --table_size=25000 --tables=250 --events=0 --max-time=1200   --threads=256 --percentile=95  --report-interval=20 oltp_write_only run >> <dbname>_write.log

 

清除测试数据

sysbench --db-driver=mysql --mysql-host=<mysql host> --mysql-port=<port> --mysql-user=<username> --mysql-password=<password> --mysql-db=<dbname> --table_size=25000 --tables=250 --events=0 --time=600  oltp_write_only cleanup

 

 读/写混合压力测试

测试数据注入

sysbench --db-driver=mysql --mysql-host=<mysql host> --mysql-port=<port> --mysql-user=<username> --mysql-password=<password> --mysql-db=<dbname> --table_size=25000 --tables=250 --events=0 --time=600  oltp_read_write  prepare

 

测试

同样地，在所有sysbench client同时执行命令模拟读写混合负载，每次持续20分钟，同时从console查看数据库CPU，IO，网络等metrics。在这里我们将通过修改num_threads参数连续测试4*32,4*64，4*128和4*200多种并发连接的场景。

sysbench --db-driver=mysql --mysql-host=<mysql host>  --mysql-user=<username> --mysql-password=<password> --mysql-port=<port>  --mysql-db=<dbname>   --table_size=25000 --tables=250 --events=0 --max-time=1200   --threads=32 --percentile=95  --report-interval=20 oltp_read_write  run >> <dbname>_read_write.log
sysbench --db-driver=mysql --mysql-host=<mysql host>  --mysql-user=<username> --mysql-password=<password> --mysql-port=<port>  --mysql-db=<dbname>   --table_size=25000 --tables=250 --events=0 --max-time=1200   --threads=64 --percentile=95  --report-interval=20 oltp_read_write  run >> <dbname>_read_write.log
sysbench --db-driver=mysql --mysql-host=<mysql host>  --mysql-user=<username> --mysql-password=<password> --mysql-port=<port>  --mysql-db=<dbname>   --table_size=25000 --tables=250 --events=0 --max-time=1200   --threads=128--percentile=95  --report-interval=20 oltp_read_write  run >> <dbname>_read_write.log
sysbench --db-driver=mysql --mysql-host=<mysql host>  --mysql-user=<username> --mysql-password=<password> --mysql-port=<port>  --mysql-db=<dbname>   --table_size=25000 --tables=250 --events=0 --max-time=1200   --threads=200--percentile=95  --report-interval=20 oltp_read_write  run >> <dbname>_read_write.log

 

清除测试数据

sysbench --db-driver=mysql --mysql-host=<mysql host> --mysql-port=<port> --mysql-user=<username> --mysql-password=<password> --mysql-db=<dbname> --table_size=25000 --tables=250 --events=0 --time=600  oltp_read_write cleanup

 结果分析

结果解读

数据库性能测试输出结果中的指标包括：

  • 每秒执行事务数TPS（Transactions Per Second） 数据库每秒执行的事务数，以COMMIT成功次数为准。
    • SysBench标准OLTP读写混合场景中一个事务包含18个读写SQL。
    • SysBench标准OLTP只读场景中一个事务包含14个读SQL（10条主键查询、4条范围查询）。
    • SysBench标准OLTP只写场景中一个事务包含4个写SQL（2条UPDATE、1条DETELE、1条INSERT）。
  • 每秒执行请求数QPS（Queries Per Second） 数据库每秒执行的SQL数。

 

结果统计

在不同并发连接数下，使用默认参数组和优化参数组的MYSQL RDS只读负载测试数据如下：

 64并发128并发256并发512并发
QPS MYSQL RDS默认参数组125.8K125K123.8K116.8K
QPS MYSQL RDS优化参数组129.4K129.8K123.9K118.5K
Response time MYSQL RDS默认参数组(ms)5.0810.1920.6543.73
Response time MYSQL RDS优化参数组(ms)4.879.8220.643.05

在不同并发连接数下，使用默认参数组和优化参数组的MYSQL RDS只写负载测试数据如下：

 64并发128并发256并发512并发
TPS MYSQL RDS默认参数组1723302522521554
TPS MYSQL RDS优化参数组1747337257708005
Response time MYSQL RDS默认参数组(ms)37.0942.27113.24325.31
Response time MYSQL RDS优化参数组(ms)36.8537.9444.2963.73

在不同并发连接数下，使用默认参数组和优化参数组的MYSQL RDS读/写混合负载测试数据如下：

 64并发128并发256并发400并发
TPS MYSQL RDS默认参数组1360212824301863
TPS AWS MYSQLP RDS1399212926232787
QPS MYSQL RDS默认参数组27.1K42.5K48.5K37.2K
QPS AWS MYSQLP RDS27.9K42.6K52.4K55.7K
Response time MYSQL RDS默认参数组(ms)46.9460.11105.31213.54
Response time MYSQL RDS优化参数组(ms)45.7259.9997.42142.87

 

 结论

通过以上测试数据，我们可以发现：

  • 因为我们调整的参数主要针对写入性能，故而对读取性能影响较小，而对写入性能影响较大 ，这从测试结果中得到了体现。
  • 并发连接越多，优化相关参数对MYSQL RDS写入和读写混合场景下的性能提升越明显，最多时，只写场景下同等负载，优化参数组后RDS的平均响应时间可以缩小到默认参数组RDS平均响应时间的约1/5，TPS可以提升到默认参数组TPS的约5倍。
  • 同理，对于读写混合场景，当并发数较大或者说写入负载达到一定量时，参数调整的效果才可以展现出来，这是因为同样的并发数读写混合场景的写入负载小于只写场景。
  • 测试数据库开启了Multi-AZ以保证安全性,这会对性能产生较大影响,在分析数据时也必须考虑。
优化MySQL存储写入速度：选择适当的分析方法
CsmbPascal的博客
10-01 416
通过优化数据库表结构，使用批量插入数据，调整事务提交频率和MySQL配置参数，我们可以改善MySQL存储写入速度的问题。然而，优化的效果取决于数据库的具体情况和应用场景，因此需要根据实际情况进行测试和调整。以上提供的方法和示例代码可以作为参考，帮助您优化MySQL的写入性能。可以考虑调整事务提交的频率，将多个写入操作合并为一个事务，从而减少事务提交的次数。然而，过多的索引会增加写入操作的负担，因此需要权衡索引的数量和类型。：将这个参数的值设置为0或2可以减少事务日志的写入频率，提高写入性能。
mysql 大量写入 优化_MYSQL大批量写入之性能优化
weixin_39849387的博客
02-27 2752
大家提到Mysql的性能优化都是注重于优化sql以及索引来提升查询性能，大多数产品或者网站面临的更多的高并发数据读取问题。然而在大量写入数据场景该如 何优化呢？今天这里主要给大家介绍，在有大量写入的场景，进行优化的方案。总的来说MYSQL数据库写入性能主要受限于数据库自身的配置，以及操作系统的性能，磁盘IO的性能。主要的优化手段包括以下几点：1：调整数据库参数(1) innodb_flush_l...
Rds mysql 内存配置_RDS MySQL内存管理
weixin_32771631的博客
01-30 581
内存的规格会决定该实例的性能。您可以根据业务情况调整RDS MySQL实例的innodb_buffer_pool_size大小，以便提升实例性能。背景信息RDS MySQL实例的内存主要用于以下几个方面：mysqld服务。主要是缓存(InnoDB Buffer Pool)占用内存，InnoDB Buffer Pool大小由参数innodb_buffer_pool_size指定。RDS相关管理服务。...
MySQL插入性能优化
蒋先生
01-17 748
MySQL插入性能优化 标签： 博客 文章目录MySQL插入性能优化代码优化values 多个一个事务插入字段尽量少，尽量用默认值关闭 unique_checksbulk_insert_buffer_size配置优化innodb_buffer_pool_size 缓冲区配置什么是 innodb_buffer_pool_size设置多大的 innodb_buffer_pool_size 合适？...
mysql性能优化-延迟写和异步写优化
最新发布
Flying_Fish_roe的博客
09-20 1101
MySQL 的延迟写和异步写技术可以显著提高写操作的性能，尤其是在高并发、大量写入的场景下，它们通过减少磁盘 I/O 操作、提高写入吞吐量，改善了系统的响应速度。然而，这些技术在提升性能的同时，也带来了数据一致性和持久性方面的风险。在实际项目中，开发者需要根据业务需求和应用场景权衡性能与数据安全，合理配置 MySQL 的延迟写和异步写机制。通过调整等关键参数，可以在性能和安全性之间找到最佳的平衡点，确保系统在高负载下依然能够稳定高效运行。
mysql 大量写入 优化_优化了MYSQL大量写入问题，老板奖励了1000块给我
weixin_29023079的博客
01-21 763
摘要：大家提到Mysql的性能优化都是注重于优化sql以及索引来提升查询性能，大多数产品或者网站面临的更多的高并发数据读取问题。然而在大量写入数据场景该如何优化呢？今天这里主要给大家介绍，在有大量写入的场景，进行优化的方案。总的来说MYSQL数据库写入性能主要受限于数据库自身的配置，以及操作系统的性能，磁盘IO的性能。主要的优化手段包括以下几点：1、调整数据库参数(1) innodb_flush_...
AWS RDS 默认最大连接数
qq_35031937的博客
10-12 1342
实际得出的 max_connections。由于为操作系统和 RDS 管理进程预留了内存。通过连接数据库，运行。
MySQL性能调优my.cnf详解
weixin_33916256的博客
02-09 1266
为什么80%的码农都做不了架构师？>>> ...
MySQL性能优化：优化思路、查询优化、索引优化、存储优化、数据库结构优化、数据库结构优化
weixin_41942838的博客
12-16 1万+
MySQL性能优化 1 优化介绍 ​在进行优化讲解之前，先请大家记住不要听信你看到的关于优化的“绝对真理”，而应该是在实际的业务场景下通过测试来验证你关于执行计划以及响应时间的假设。给大家提供一些优化方面的方向和思路，而具体业务场景的不同，使用的MySQL服务版本不同，都会使得优化方案的制定也不同。 1.1 MySQL介绍 ​MySQL凭借着出色的性能、低廉的成本、丰富的资源，已经成为绝大多数互联网公司的首选关系型数据库。可以看到Google，Facebook，Twitter，百度，新浪，腾讯，淘宝，网易，
优化了MYSQL大量写入问题，老板奖励了1000块给我
热门推荐
华为云官方博客
01-04 2万+
摘要：大家提到Mysql的性能优化都是注重于优化sql以及索引来提升查询性能，大多数产品或者网站面临的更多的高并发数据读取问题。然而在大量写入数据场景该如何优化呢？ 今天这里主要给大家介绍，在有大量写入的场景，进行优化的方案。 总的来说MYSQL数据库写入性能主要受限于数据库自身的配置，以及操作系统的性能，磁盘IO的性能。主要的优化手段包括以下几点： 1、调整数据库参数 （1） innodb_flush_log_at_trx_commit 默认为1，这是数据库的事务提交设置参数，可选值如下： 0
Mysql 性能优化教程
大鹏
08-13 2602
Mysql 性能优化教程 目录 目录................................................................................................................................. 1 背景及目标..........................................
MySQL DBA教程：Mysql性能优化之缓存参数优化
12-15
本教程将聚焦于MySQL的缓存参数优化，旨在通过调整相关参数，最大化利用内存资源，减少磁盘IO，从而提升数据库性能。 首先，我们关注`query_cache_size`和`query_cache_type`。Query Cache是MySQL为SELECT语句提供...
MySQL性能全面优化方法参考,从CPU,文件系统选择到mysql.cnf参数优化
09-09
5. 优化日志文件大小（innodb_log_file_size）以平衡写入性能和恢复速度。 6. 调整binlog格式和同步策略，例如使用ROW格式的binlog并调整sync_binlog参数以平衡性能和数据安全。 此外，监控和分析工具如pt-query-...
python测试mysql写入性能完整实例
09-09
Python对MySQL数据库的...总的来说，Python测试MySQL写入性能需要综合考虑多种因素，包括但不限于数据库配置、批量处理策略、事务使用以及硬件资源。通过优化这些方面，可以有效地提高数据写入的效率和系统的整体性能。
MySQL大量写入问题优化方案 MySQL参数调优
xzh_blog
07-21 2212
innodb_flush_log_at_trx_commit是数据库的事务提交设置参数，默认为1。设置为0时，数据写入是最快的，但有可能丢失上1秒的数据。 0：log buffer每隔1s进行刷盘。当机器出现宕机时，最多丢失1s的事务 1：事务提交后立即进行log buffer刷盘。 2：MySQL先将log buffer写入到os buffer，然后每隔1s将os buffer中的数据刷新到磁盘。...
mysql 写入性能 datafile_mysql 性能优化(数据导入)
weixin_39988476的博客
02-01 192
mysql数据导入性能优化(代码级别)1. 使用preparedStatment2. 使用批量处理，一次提交3. mysql 批量插入数据添加参数rewriteBatchedStatements时，性能比不添加时要最高可提高10倍以上的速度。URL如下：jdbc:mysql://%IP%:3306/%SID%?rewriteBatchedStatements=true4. 使用load data ...
MySQL插入语句insert性能优化
Jerry的一亩三分地
08-16 905
对于一些数据量较大的系统，面临的问题除了是查询效率低下，还有一个很重要的问题就是插入时间长。当导入的数据量较大时，插入操作耗费的时间相当可观。因此，提高大数据量系统的MySQL insert效率是很有必要的。 1. 一条SQL语句插入多条数据。 常用的插入语句如： [sql] view plaincopy INSERT INTO 
MySQL批量SQL插入各种性能优化
weixin_33883178的博客
07-04 196
对于一些数据量较大的系统。数据库面临的问题除了查询效率低下，还有就是数据入库时间长。特别像报表系统，每天花费在数据导入上的时间可能会长达几个小时或十几个小时之久。因此。优化数据库插入性能是非常有意义的。 经过对MySQL innodb的一些性能測试，发现一些能够提高insert效率的方法。供大家參考參考。 1、一条SQL语句插入多条数据。 经常使用的插入语句如： ...
MySQL性能优化
qq_41494158的博客
05-22 547
本文从多个方面介绍了使用MySQL数据库的优化方案，但具体实践还需要对每个优化方案的利弊进行深入了解，并结合具体情况分析，从而设计出适合自己的最优方案。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值