下文主要給大家?guī)?lái)MySQL參數(shù)壓測(cè)的全過(guò)程，希望這些內(nèi)容能夠帶給大家實(shí)際用處，這也是我編輯MySQL參數(shù)壓測(cè)的全過(guò)程這篇文章的主要目的。好了，廢話不多說(shuō)，大家直接看下文吧。

北屯ssl適用于網(wǎng)站、小程序/APP、API接口等需要進(jìn)行數(shù)據(jù)傳輸應(yīng)用場(chǎng)景，ssl證書(shū)未來(lái)市場(chǎng)廣闊！成為創(chuàng)新互聯(lián)公司的ssl證書(shū)銷(xiāo)售渠道，可以享受市場(chǎng)價(jià)格4-6折優(yōu)惠！如果有意向歡迎電話聯(lián)系或者加微信：13518219792（備注：SSL證書(shū)合作）期待與您的合作！

1.測(cè)試背景

首先分別了解一下這兩個(gè)參數(shù)的官方解釋:

sync_binlog

Controls how often the MySQL server synchronizes the binary log to disk.
控制MySQL server 同步binlog到磁盤(pán)的頻率

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.
關(guān)閉MySQL server binlog同步到磁盤(pán)，由OS不時(shí)的刷新到磁盤(pán)，這是MySQL最好的性能，但是當(dāng)斷電或者系統(tǒng)崩潰，MySQL server已經(jīng)提交的事物可能還沒(méi)有同步到binlog，導(dǎo)致事物丟失。

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.
在事物提交之前同步binlog到磁盤(pán)，這是最安全的，但是由于增加了磁盤(pán)的寫(xiě)操作，會(huì)有一些消極的性能影響。當(dāng)斷電或者系統(tǒng)崩潰，從binlog中丟失的事物僅僅處于準(zhǔn)備狀態(tài)。這個(gè)允許自動(dòng)恢復(fù)程序去rollback事物，保證binlog沒(méi)有事物丟失。

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.
在N個(gè)binlog提交組被收集到之后，binglog同步到磁盤(pán)。當(dāng)斷電或者系統(tǒng)崩潰，已經(jīng)提交的事物可能還沒(méi)有刷新到binlog。這樣的配置增加了磁盤(pán)的寫(xiě)操作，會(huì)有一些消極的性能影響。N值越高，數(shù)據(jù)庫(kù)性能越好，但是數(shù)據(jù)越可能丟失。

For the greatest possible durability and consistency in a replication setup that uses InnoDB with transactions, use these settings:
為了使使用InnoDB的復(fù)制設(shè)置具有最大的持久性和一致性，請(qǐng)使用以下設(shè)置:

sync_binlog=1.
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 recommended settings, 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.
許多操作系統(tǒng)和一些磁盤(pán)硬件欺騙了刷新磁盤(pán)的操作。它們可能會(huì)告訴sqmyld flush已經(jīng)發(fā)生了，盡管沒(méi)有發(fā)生。在這種情況下，即使使用推薦的設(shè)置，事務(wù)的持久性也不能得到保證，在最壞的情況下，斷電可能損壞InnoDB數(shù)據(jù)。在SCSI磁盤(pán)控制器或磁盤(pán)本身中使用電池支持的磁盤(pán)緩存可以加速文件刷新，并使操作更加安全。您還可以嘗試禁用硬件緩存中的磁盤(pán)寫(xiě)緩存。

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.
控制提交操作嚴(yán)格遵守ACID和提高性能之間的平衡，這在批量重新安排和執(zhí)行與提交相關(guān)的I/O操作時(shí)是可能的，通過(guò)更改默認(rèn)值，您可以獲得更好的性能，但是在崩潰時(shí)，你可能會(huì)損失多達(dá)一秒鐘的事務(wù)

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.
默認(rèn)值1是必須的對(duì)ACID性.InnoDB日志緩沖區(qū)的內(nèi)容在每個(gè)事務(wù)提交時(shí)被寫(xiě)到日志文件，日志文件被刷新到磁盤(pán)。

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.
值為0時(shí)，InnoDB日志緩沖區(qū)的內(nèi)容大約每秒寫(xiě)入一次日志文件，日志文件被刷新到磁盤(pán)。事務(wù)提交時(shí)不執(zhí)行從日志緩沖區(qū)寫(xiě)入日志文件的操作。由于進(jìn)程調(diào)度問(wèn)題，不能保證每秒一次刷新。由于對(duì)磁盤(pán)的刷新操作大約每秒鐘只發(fā)生一次，因此您可以在任何mysqld進(jìn)程中損失最多一秒鐘的事務(wù)

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.
當(dāng)值為2時(shí)，InnoDB日志緩沖區(qū)的內(nèi)容在每次事務(wù)提交后被寫(xiě)入日志文件，日志文件大約每秒被刷新一次。由于進(jìn)程調(diào)度問(wèn)題，每秒一次的刷新不能100%保證每秒發(fā)生。由于磁盤(pán)刷新操作大約每秒發(fā)生一次，所以在操作系統(tǒng)崩潰或斷電時(shí)，最多可能損失1秒的事務(wù)。

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 recommended settings, 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.

2.測(cè)試配置

這里TPCC和MySQL分別在兩臺(tái)機(jī)器上面，是為了排除TPCC運(yùn)行過(guò)程中對(duì)MySQL服務(wù)資源的占用的影響

IP:172.16.101.54

CPU:2core

Memory:8G

軟件:tpcc-mysql-master

IP:172.16.101.55

CPU:2core

Memory:6G

軟件:MySQL5.7.21 

MySQL其他部分參數(shù)配置:

key_buffer_size = 8M
sort_buffer_size = 2M
read_buffer_size = 2M
read_rnd_buffer_size = 4M
query_cache_size= 0M
query_cache_type= off
max_allowed_packet = 64M
myisam_sort_buffer_size=128M
tmp_table_size=32M
table_open_cache = 2000
thread_cache_size = 8
wait_timeout = 300
interactive_timeout = 300
max_connections = 8000
max_user_connections=0
innodb_thread_concurrency = 4 
transaction_isolation = READ-COMMITTED
gtid-mode = on
enforce-gtid-consistency = true
log_slave_updates = on
innodb_buffer_pool_size = 5120M
innodb_log_buffer_size = 16M
innodb_lock_wait_timeout = 100

3.測(cè)試過(guò)程

測(cè)試主要分兩種情況，通過(guò)tpcc測(cè)得MySQL server的tps和qps，每一種情況測(cè)試三遍，取平均值，并做成表格和折線圖。

innodb_flush_log_at_trx_commit = 1 && sync_binlog = 1

or

innodb_flush_log_at_trx_commit = 0 && sync_binlog = 0

4.測(cè)試結(jié)果

首先說(shuō)明一下，因?yàn)槭诸^上只有這樣低配置的云服務(wù)器，所以測(cè)試結(jié)果不是那么的可靠，所以僅僅參考測(cè)試思想和過(guò)程即可，不要太在意測(cè)試結(jié)果，哈哈。

（1）TpmC

即每分鐘的事物數(shù)

線程數(shù)	4	8	16	32	64	128	256	512	1024	1536	2048
i=1&s=1	864.433	1411.367	2020.667	2465.867	2666.533	2666.633	2614.333	2431.267	2011.233	1507.733	1266.1
i=0&s=0	2761.383	3160.05	2835.817	2510.683	2366.017	2303.25	2367.517	2251.817	1834.583	1439.684	1166.3

從圖中我們可以看到：

• 并發(fā)0-32的時(shí)候，雙0的MySQL TpmC遠(yuǎn)遠(yuǎn)大于雙1;

• 并發(fā)>32后，兩者之間的TpmC數(shù)量差不多

（2）雙1情況下的 slow queries，open tables，Queries per second avg等指標(biāo)的情況

從圖中我們可以看到：

• 隨著并發(fā)越來(lái)越大，slow queries也越來(lái)越多；

• 當(dāng)并發(fā)達(dá)到512左右，open tables也達(dá)到參數(shù)table_open_cache = 2000的設(shè)定值；

• 隨著并發(fā)越來(lái)越大，QPS越來(lái)越小，剛開(kāi)始并不明顯，一度處于平衡，知道并發(fā)太大，QPS性能下降；

對(duì)于以上關(guān)于MySQL參數(shù)壓測(cè)的全過(guò)程，大家是不是覺(jué)得非常有幫助。如果需要了解更多內(nèi)容，請(qǐng)繼續(xù)關(guān)注我們的行業(yè)資訊，相信你會(huì)喜歡上這些內(nèi)容的。

文章名稱：簡(jiǎn)單了解MySQL參數(shù)壓測(cè)的全過(guò)程
URL地址：http://jinyejixie.com/article36/gpgssg.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供、建站公司、外貿(mào)建站、定制開(kāi)發(fā)、網(wǎng)站設(shè)計(jì)、動(dòng)態(tài)網(wǎng)站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)