公司开发人员在测试环境中执行一条 insert 语句时,需要花费 10 几秒才可以执行成功。查看测试环境数据库性能、数据量、死锁等信息,均为发现异常。最后通过修改日志写入方式解决此问题。
1. 修改办法
修改/etc/my.cnf文件,将 innodb_flush_log_at_trx_commit = 1改为0, 但这样就要承担数据库Crash后,1秒内未存储到数据库数据丢失可能的风险。MySQL文档中对该参数的描述如下:
If the value of innodb_flush_log_at_trx_commit is 0, the log buffer is written out to the log file once per second and the flush to disk operation is performed on the log file, but nothing is done at a transaction commit. When the value is 1 (the default), the log buffer is written out to the log file at each transaction commit and the flush to disk operation is performed on the log file. When the value is 2, the log buffer is written out to the file at each commit, but the flush to disk operation is not performed on it. However, the flushing on the log file takes place once per second also when the value is 2. Note that the once-per-second flushing is not 100% guaranteed to happen every second, due to process scheduling issues.
2. 参数说明
- 0:log buffer将每秒一次地写入log file中,并且log file的flush(刷到磁盘)操作同时进行。该模式下在事务提交的时候,不会主动触发写入磁盘的操作
- 1:每次事务提交时MySQL都会把log buffer的数据写入log file,并且flush(刷到磁盘)中去,该模式为系统默认
- 2:每次事务提交时MySQL都会把log buffer的数据写入log file,但是flush(刷到磁盘)操作并不会同时进行。该模式下,MySQL会每秒执行一次 flush(刷到磁盘)操作
3. 注意事项
当设置为0时,该模式速度最快,但不太安全,mysqld进程的崩溃会导致上一秒钟所有事务数据的丢失。
当设置为1时,该模式是最安全的,但也是最慢的一种方式。在mysqld 服务崩溃或者服务器主机crash的情况下,binary log 只有可能丢失最多一个语句或者一个事务。
当设置为2时,该模式速度较快,也比0安全,只有在操作系统崩溃或者系统断电的情况下,上一秒钟所有事务数据才可能丢失。
innodb_flush_log_at_trx_commit和sync_binlog 两个参数是控制MySQL 磁盘写入策略以及数据安全性的关键参数,当两个参数都设置为1的时候写入性能最差,推荐做法是innodb_flush_log_at_trx_commit=2,sync_binlog=500 或1000。
到此这篇关于MySQL删除和插入数据很慢的问题解决的文章就介绍到这了,更多相关MySQL删除和插入数据很慢内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家!
您可能感兴趣的文章:- 详解Navicat远程连接mysql很慢
- Mysql查询很慢卡在sending data的原因及解决思路讲解
- MySQL数据库远程连接很慢的解决方案
- 解决MySQL Sending data导致查询很慢问题的方法与思路
- 解决远程连接mysql很慢的方法(mysql_connect 打开连接慢)
- 禁止mysql做域名解析(解决远程访问mysql时很慢)