注:个人经验分享,转载请注明出处
优化配置文件my.ini文件中的配置
第一个重要指标:innodb_flush_log_at_trx_commit=2
可选值有0,1,2 mysql默认配置的是1
这里引用mysql官方解释这个指标:
# If set to 1, InnoDB will flush (fsynct同步) the transaction logs to the
# disk at each commit, which offers full ACID behavior. If you are
# willing to compromise this safety, and you are running small
# transactions, you may set this to 0 or 2 to reduce disk I/O to the
# logs. Value 0 means that the log is only written to the log file and
# the log file flushed to disk approximately(大约) once per second. Value 2
# means the log is written to the log file at each commit, but the log
# file is only flushed to disk approximately(大约) once per second.
innodb_flush_log_at_trx_commit=2
翻译下来就是:
innodb_flush_log_at_trx_commit = 0,Innodb 中的Log Thread 没隔1 秒钟会将log buffer中的数据写入到文件,同时还会通知文件系统进行文件同步的flush 操作,保证数据确实已经写入到磁盘上面的物理文件。但是,每次事务的结束(commit 或者是rollback)并不会触发Log Thread 将log buffer 中的数据写入文件。所以,当设置为0 的时候,当MySQL Crash 和OS Crash 或者主机断电之后,最极端的情况是丢失1 秒时间的数据变更。
innodb_flush_log_at_trx_commit = 1,这也是Innodb 的默认设置。我们每次事务的结束都会触发Log Thread 将log buffer 中的数据写入文件并通知文件系统同步文件。这个设置是最安全的设置,能够保证不论是MySQL Crash 还是OS Crash 或者是主机断电都不会丢失任何已经提交的数据。
innodb_flush_log_at_trx_commit = 2,当我们设置为2 的时候,Log Thread 会在我们每次事务结束的时候将数据写入事务日志,但是这里的写入仅仅是调用了文件系统的文件写入操作。而我们的文件系统都是有缓存机制的,所以Log Thread 的这个写入并不能保证内容真的已经写入到物理磁盘上面完成持久化的动作。文件系统什么时候会将缓存中的这个数据同步到物理磁盘文件Log Thread 就完全不知道了。所以,当设置为2 的时候,MySQL Crash 并不会造成数据的丢失,但是OS Crash 或者是主机断电后可能丢失的数据量就完全控制在文件系统上了。各种文件系统对于自己缓存的刷新机制各不一样,
综上所述:0是最不安全的,如果断电会丢失mysql缓存,文件系统缓存中将近一秒的数据。
1是最安全的,怎么都不会丢失数据,但是也是性能最差的。
2是居于中间。
通常优化的时候把该值设置为2可大约提升百分之200到300的性能。
下面针对该配置进行测试:
sql语句:
DROP TABLE IF EXISTS `supan`;
CREATE TABLE `supan` (
`name` varchar(30) DEFAULT NULL,
`id` int(11) NOT NULL AUTO_INCREMENT,
`grade` int(11) NOT NULL DEFAULT '0',
PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=utf8;
java程序:
import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.PreparedStatement;
public class InsertTestData
{
public static void main(String[] args)
{
String driver = "com.mysql.jdbc.Driver";
String url = "jdbc:mysql://127.0.0.1:3306/test";
String user = "root";
String password = "root";
try
{
Class.forName(driver);
Connection conn = DriverManager.getConnection(url, user, password);
//故意设置自动提交为false
conn.setAutoCommit(false);
PreparedStatement pst = (PreparedStatement) conn.prepareStatement("insert into supan(name,grade) values(?,?)");
//记录开始时间
Long startTime = System.currentTimeMillis();
for (long i = 0; i < 1000000; i++) {
pst.setString(1, "张三");
pst.setLong(2,i);;
pst.addBatch();
pst.executeBatch();
//故意每次都提交一个sql语句,增加事务的开启和关闭
conn.commit();
pst.clearBatch();
}
// 语句执行完毕,提交本事务
Long endTime = System.currentTimeMillis();
System.out.println(endTime - startTime);
conn.close();
} catch (Exception e)
{
System.out.println("Sorry,can`t find the Driver!");
e.printStackTrace();
}
}
}
上面测试代码插入一百万数据:在配置为1的情况下执行时间为:1337496
在配置为2的情况下执行时间为:434137
效率提升整200%
分享到:
相关推荐
MySQL 数据库中的 `innodb_flush_log_at_trx_commit` 和 `sync_binlog` 是两个非常重要的配置参数,它们直接影响到数据库的性能与数据安全性。理解并合理设置这两个参数对于优化数据库系统至关重要。 首先,`innodb...
[client] port=3306 [mysql] no-beep default-character-set=utf8 [mysqld] datadir=D:/Data port=3306 server-id=...log_file_size=1G innodb_log_buffer_size=8M innodb_flush_log_at_trx_commit=2 innodb_file_per_t
可以看到,只有1才能真正地保证事务的持久性,但是由于刷新操作 fsync() 是阻塞的,直到完成后才返回,我们知道写磁盘的速度是很慢的,因此 MySQL 的性能
- `innodb_flush_log_at_trx_commit`:决定日志何时刷新到磁盘。 #### 5. 恢复和性能 InnoDB的重做日志对于数据库的恢复和性能至关重要。在数据库崩溃后,InnoDB可以重放日志来恢复未提交的事务和重做已提交的事务...
6. **innodb_flush_log_at_trx_commit**:此参数控制事务日志的持久化策略,影响事务的ACID特性。设置为1确保每次提交都同步到磁盘,牺牲速度以保证强一致性;设置为0或2则可能牺牲一些一致性以换取性能提升。 7. *...
在网上看了无数的my....结果是只有innodb_flush_log_at_trx_commit可以提高性能,对于1,2,3参数无论是开其中某一个,还是三个同时调节都没有影响到测试性能。我想了下,可能是我的测试数据量还不够大造成的,后续有条
- **innodb_flush_log_at_trx_commit**:控制日志写入磁盘的策略,对于实时业务交易,一般配置为2,既保证了事务的一致性又减少了性能损耗,而设置为0或2时在系统崩溃时可能会有数据丢失的风险。 - **innodb_read_...
`innodb_flush_log_at_trx_commit` - **描述**:控制事务提交时是否同步写入日志文件,默认值为0。 - **应用场景**:设置为1可增强数据安全性,但可能会降低性能;设置为0则牺牲安全性换取更高性能。 ##### 9. `...
4. **INNODB_FLUSH_LOG_AT_TRX_COMMIT**: 这个变量控制事务日志何时写入磁盘。默认值1表示每次事务提交后立即同步,可能导致较高的磁盘I/O。值0和2可以减少同步频率,提高性能,但牺牲了一定的数据安全性。根据业务...
7. `innodb_log_files_in_group`、`innodb_flush_log_at_trx_commit`、`innodb_log_file_size` 和 `innodb_max_dirty_pages_pct` 与事务日志和脏页处理相关,确保事务安全性和性能平衡。 测试工具 Sysbench 被用来...
- innodb_flush_log_at_trx_commit:控制事务日志刷新时机,影响事务的持久性和性能。 - sync_binlog:这个变量控制二进制日志的刷新频率,影响数据同步和恢复的可靠性。 - innodb_flush_method:这个设置可以...
- **innodb_flush_log_at_trx_commit**: 写入redo log频率。 - **innodb_log_buffer_size**: InnoDB日志缓冲区大小。 - **innodb_log_file_size**: InnoDB日志文件大小。 - **innodb_log_files_in_group**: InnoDB...
- `innodb_flush_log_at_trx_commit`决定事务提交后如何同步InnoDB的日志,以确保数据一致性。 这些参数的优化对于MySQL数据库的性能、稳定性和安全性至关重要。正确调整这些参数可以帮助数据库更好地应对高并发、...
innodb_flush_log_at_trx_commit=2 key_buffer_size=268435456 sort_buffer_size=33554432 read_buffer_size=16777216 myisam_sort_buffer_size=134217728 thread_cache_size=64 tmp_table_size = 512M max_heap_...
- **配置调整**:例如调整buffer pool大小、innodb_flush_log_at_trx_commit参数等。 - **索引优化**:合理创建和使用索引可以显著提高查询速度。 - **查询优化**:避免使用复杂的子查询和全表扫描等低效查询方式...
- `innodb_flush_log_at_trx_commit` 设置为2,这意味着每次提交事务时,重做日志缓冲区会被写入日志文件,但不立即同步到磁盘,提供了一定的性能和数据安全平衡。 - `innodb_file_per_table` 开启,每个表的索引...
- `innodb_flush_log_at_trx_commit`:控制事务日志的刷新策略,确保数据的一致性。 - `sync_binlog`:控制二进制日志的同步频率,影响故障恢复的可靠性。 6. **查询缓存**: - `query_cache_size`:查询缓存的...
- `innodb_flush_log_at_trx_commit = 1`:控制事务提交时是否刷新重做日志到磁盘。 - `sync_binlog = 1`:控制二进制日志何时同步到磁盘。 - `binlog_format = ROW`:二进制日志格式为行级别。 - `log_bin = ON...
1. `innodb_flush_log_at_trx_commit=0`:最优化性能,每秒将Log Buffer内容批量写入OS cache并进行fsync,这样可能导致最多1秒内的数据丢失。 2. `innodb_flush_log_at_trx_commit=1`:强一致性的策略,每次事务...
- `innodb_flush_log_at_trx_commit`:控制事务日志刷新策略,影响事务安全性与性能。 - `innodb_lock_wait_timeout`:设置事务等待锁的时间,超过此时间的事务将被回滚。 - `innodb_file_per_table`:开启后,每...