my.cnf parameter configuration to optimize InnoDB engine performance

I have read countless my.cnf configurations on the Internet, and most of the configurations mentioned are nothing more than these:

1. innodb_buffer_pool_size
2. innodb_log_file_size
3. innodb_log_buffer_size
4. innodb_flush_log_at_trx_commit

Then I wrote two examples, one single-threaded and one multi-threaded, to test whether the performance was improved by changing the configuration parameters. The result shows that only innodb_flush_log_at_trx_commit can improve performance. For parameters 1, 2, and 3, whether one of them is turned on or all three are adjusted at the same time, the test performance is not affected. I thought about it and it might be because the amount of my test data was not large enough. I will test these three parameters with a larger amount of data when conditions permit.

Here is a detailed description of innodb_flush_log_at_trx_commit:

If innodb_flush_log_at_trx_commit is set to 0, the log buffer will be written to the log file once per second, and the flush (brush to disk) operation of the log file will be performed simultaneously. In this mode, when a transaction is committed, the operation of writing to disk is not actively triggered.
If innodb_flush_log_at_trx_commit is set to 1, MySQL will write the data in the log buffer to the log file and flush it to disk each time a transaction is committed.
If innodb_flush_log_at_trx_commit is set to 2, MySQL will write the log buffer data to the log file each time a transaction is committed. However, the flush operation does not occur simultaneously. In this mode, MySQL will perform a flush operation once per second.

result :

When set to 0, this mode is the fastest, but less secure. A crash of the mysqld process will result in the loss of all transaction data in the last second.
When set to 1, this mode is the safest, but also the slowest. In the event of a mysqld service crash or a server host crash, the binary log may lose at most one statement or one transaction.
When set to 2, this mode is faster and safer than 0. All transaction data in the last second may be lost only if the operating system crashes or the system loses power.

Note : Due to process scheduling issues, this "flush operation once per second" is not guaranteed to be 100% "per second".

Conclusion : The speed is similar when innodb_flush_log_at_trx_commit is set to 0 or 2, and both are much faster than when it is set to 1.

This reminds me of the difference between InnoDB and MyISAM engines. The advantage of InnoDB is that it is faster than MyISAM in concurrent processing. The number of my thread pools is set according to the number of CPU threads. Then I set the number of thread pools to be larger, larger, and larger than the number of CPU threads. As a result, the performance of my test program improved again. I was drunk. It turned out that my understanding of thread pools was too superficial. Optimal thread pool size