innodb_flush_log_at_trx_commit

innodb_flush_log_at_trx_commit。官方手册对这个值解释如下：

Controls the balance between strict ACID compliance for commit operations and higher performance that is possible when commit-related I/O operations are rearranged and done in batches. You can achieve better performance by changing the default value but then you can lose up to a second of transactions in a crash.
​
The default value of 1 is required for full ACID compliance. With this value, the contents of the InnoDB log buffer are written out to the log file at each transaction commit and the log file is flushed to disk.
​
With a value of 0, the contents of the InnoDB log buffer are written to the log file approximately once per second and the log file is flushed to disk. No writes from the log buffer to the log file are performed at transaction commit. Once-per-second flushing is not guaranteed to happen every second due to process scheduling issues. Because the flush to disk operation only occurs approximately once per second, you can lose up to a second of transactions with any mysqld process crash.
​
With a value of 2, the contents of the InnoDB log buffer are written to the log file after each transaction commit and the log file is flushed to disk approximately once per second. Once-per-second flushing is not 100% guaranteed to happen every second, due to process scheduling issues. Because the flush to disk operation only occurs approximately once per second, you can lose up to a second of transactions in an operating system crash or a power outage.
​
InnoDB log flushing frequency is controlled by innodb_flush_log_at_timeout, which allows you to set log flushing frequency to N seconds (where N is 1 ... 2700, with a default value of 1). However, any mysqld process crash can erase up to N seconds of transactions.
​
DDL changes and other internal InnoDB activities flush the InnoDB log independent of the innodb_flush_log_at_trx_commit setting.
​
InnoDB crash recovery works regardless of the innodb_flush_log_at_trx_commit setting. Transactions are either applied entirely or erased entirely.
​
For durability and consistency in a replication setup that uses InnoDB with transactions:
​
If binary logging is enabled, set sync_binlog=1.
​
Always set innodb_flush_log_at_trx_commit=1.
​
Caution
Many operating systems and some disk hardware fool the flush-to-disk operation. They may tell mysqld that the flush has taken place, even though it has not. In this case, the durability of transactions is not guaranteed even with the setting 1, and in the worst case, a power outage can corrupt InnoDB data. Using a battery-backed disk cache in the SCSI disk controller or in the disk itself speeds up file flushes, and makes the operation safer. You can also try to disable the caching of disk writes in hardware caches.

• 1 默认值，最慢，每次事务提交都要写入log并刷新到磁盘上，这是最保险的方式

• 0 最快，每隔1S将log刷新到磁盘，但是不保证。事务提交不会触发log写入。很不安全，mysql挂了，那么上一秒的数据就都丢了。

• 2 折中的一种，事务提交会写入log，但是log刷新还是每秒一次，不保证。这种时候，就算mysql崩了，但是只要操作系统还在运转，数据还是会被写到磁盘上。

sync_binlog

Controls how often the MySQL server synchronizes the binary log to disk.
​
sync_binlog=0: Disables synchronization of the binary log to disk by the MySQL server. Instead, the MySQL server relies on the operating system to flush the binary log to disk from time to time as it does for any other file. This setting provides the best performance, but in the event of a power failure or operating system crash, it is possible that the server has committed transactions that have not been synchronized to the binary log.
​
sync_binlog=1: Enables synchronization of the binary log to disk before transactions are committed. This is the safest setting but can have a negative impact on performance due to the increased number of disk writes. In the event of a power failure or operating system crash, transactions that are missing from the binary log are only in a prepared state. This permits the automatic recovery routine to roll back the transactions, which guarantees that no transaction is lost from the binary log.
​
sync_binlog=N, where N is a value other than 0 or 1: The binary log is synchronized to disk after N binary log commit groups have been collected. In the event of a power failure or operating system crash, it is possible that the server has committed transactions that have not been flushed to the binary log. This setting can have a negative impact on performance due to the increased number of disk writes. A higher value improves performance, but with an increased risk of data loss.

• 0 不刷新 binlog，也就是 mysql 只管写数据，至于数据啥时候刷新，由操作系统负责。

• 1 每1次事务都要强制刷新，写入磁盘，可以看出，这是一种非常保险的方式，但是可想而知，性能会比较差，取决于存储介质的读写速度

• N，每 N 次事务强制刷新一次磁盘。设的大一些，可以得到一定的性能提升，但是遇到系统崩溃，会丢失 N 个事务的数据。

• sync_binlog=1

• innodb_flush_log_at_trx_commit=1

mysql> set GLOBAL innodb_flush_log_at_trx_commit = 0;
mysql> set GLOBAL sync_binlog = 0;

另外一些可以设置的地方

• innodb_autoextend_increment 表空间自增值

• innodb_log_buffer_size log 缓存区大小

• innodb_log_file_size binlog 文件大小

• bulk_insert_buffer_size 批量写入的数据大小

这些变量全都可以在 mysql 官方的文档里面查到，不同的版本有不同的默认值，最新版本的 mysql，这些变量的默认值已经非常大了，都是几十 MB 级别的，一般不会成为性能瓶颈。笔者自己不怎么用这几个参数。

net_buffer_length

Each client thread is associated with a connection buffer and result buffer. Both begin with a size given by net_buffer_length but are dynamically enlarged up to max_allowed_packet bytes as needed. The result buffer shrinks to net_buffer_length after each SQL statement.
​
This variable should not normally be changed, but if you have very little memory, you can set it to the expected length of statements sent by clients. If statements exceed this length, the connection buffer is automatically enlarged. The maximum value to which net_buffer_length can be set is 1MB.

max_allowed_packet

The maximum size of one packet or any generated/intermediate string, or any parameter sent by the mysql_stmt_send_long_data() C API function. The default is 4MB.
​
The packet message buffer is initialized to net_buffer_length bytes, but can grow up to max_allowed_packet bytes when needed. This value by default is small, to catch large (possibly incorrect) packets.
​
You must increase this value if you are using large BLOB columns or long strings. It should be as big as the largest BLOB you want to use. The protocol limit for max_allowed_packet is 1GB. The value should be a multiple of 1024; nonmultiples are rounded down to the nearest multiple.
​
When you change the message buffer size by changing the value of the max_allowed_packet variable, you should also change the buffer size on the client side if your client program permits it. The default max_allowed_packet value built in to the client library is 1GB, but individual client programs might override this. For example, mysql and mysqldump have defaults of 16MB and 24MB, respectively. They also enable you to change the client-side value by setting max_allowed_packet on the command line or in an option file.
​
The session value of this variable is read only. The client can receive up to as many bytes as the session value. However, the server will not send to the client more bytes than the current global max_allowed_packet value. (The global value could be less than the session value if the global value is changed after the client connects.)

mysql>show variables like 'max_allowed_packet';
mysql>show variables like 'net_buffer_length'; 

mysql -h127.0.0.1 -uroot -proot123 data_base_name --max_allowed_packet=16777216 --net_buffer_length=16384<your_sql_script.sql

其他需要注意的事情

mongo 公认的速度快，好用，但是对于数据的安全性确实不太好保证，我自己曾经碰到过 mongo 莫名其妙丢数据的情况，还是只有几百万条数据的一个系统。

(*￣︿￣)

参考

https://dev.mysql.com/doc/refman/8.0/en/innodb-parameters.html

05-29

06-08 1163
03-28 1万+
11-09 1万+
06-23 1709
05-07 1303
11-19 7268
05-31 1万+
05-11 1万+
11-21 5386
04-01 529