MySQL自增列鎖模式 innodb_autoinc_lock_mode不一樣參數下性能測試

 

20190701：感謝@接天居士的提示，在多核心CPU的配置環境下測試，確實是有差別的，感謝糾錯，原本想刪除這篇文章的，留着當錯教訓吧，測試環境差別形成的錯誤教訓

 

對於innodb_autoinc_lock_mode 各類參數的值的含義，網上也有各類詳解，看完以爲意猶未盡，這裏不作闡述，只動手測試，看看性能上，到底有沒有理論上所說的差異。
對於自增列的鎖定，聽說是innodb_autoinc_lock_mode = 2模式下有較高的性能，MySQL 8.0下innodb_autoinc_lock_mode 默認值爲2。
因而經過修改改參數，測試不一樣參數下的一些性能表現，其結果仍是比較出乎意料的……

 

測試環境：
MySQL 8.0.12 ON CentOS 7，1核1G內存
雖然環境資源配置有限，這裏目的不是作性能測試，主要是對比在innodb_autoinc_lock_mode = 0和 2模式下的性能對比（沒有作參數爲1的狀況）

測試方法：
本地Python開啓多個線程，每一個線程循環必定的數量，向某一個表中插入數據，看最終的時間表現狀況
測試代碼以下，開啓20個線程，每一個線程循環插入10000條數據，同時將當前線程Id寫入當前數據行中（用來多個線程的執行是不是均勻或者說是交替的），看最終的時間。

#coding=utf-8
import threading
import pymysql
from time import ctime,sleep

connstr_tencent = {'host': '***.***.***.***', 'port': 3306, 'user': 'root', 'password': 'root', 'db': 'db01', 'charset': 'utf8mb4'}
def access_mysql(para):
    conn = pymysql.connect(host=connstr_tencent['host'],
                           port=connstr_tencent['port'],
                           user=connstr_tencent['user'],
                           password=connstr_tencent['password'],
                           db=connstr_tencent['db'],
                           charset=connstr_tencent['charset'],
                           connect_timeout = 100000 )
    cursor = conn.cursor()
    for i in range(10000):
        cursor.execute(" insert into test_autoicrement(col2,col3,col4) values ('thread:{0}','thread:{0}','thread:{0}'); ".format(str(para)))
    cursor.close()
    conn.commit()
    conn.close()

def main():
    # 生成線程
    threads = []
    for i in range(20):
        t = threading.Thread(target=access_mysql, args=(i,))
        threads.append(t)
for t in threads:
        t.setDaemon(True)
        t.start()
    for t in threads:
        t.join()

if __name__ == '__main__':
    print("begin at {0}".format(ctime()))
    main()
    print("finsh at {0}".format(ctime()))

 

測試結果1，未開啓binlog的狀況

測試結果2，開啓binlog的狀況

測試結果僅僅是本地軟硬件環境下表出現來的結果，主要目的是不一樣參數的性能對比

測試說明：
1，每次修改innodb_autoinc_lock_mode 以後，truncate測試表，並重啓MySQL服務。
2，innodb_autoinc_lock_mode =0或者2作交叉測試，
　  也即測試一次innodb_autoinc_lock_mode =0的，truncate 測試表，重啓MySQL服務，而後再測試innodb_autoinc_lock_mode =2的狀況。
3，無論是innodb_autoinc_lock_mode 爲0或者2，（當前測試條件下）均未發現跳號的狀況。
4，多線程測試下，記錄都記錄是當前線程的id，每次檢驗最終測試數據的分佈狀況，基本上都是每一個線程均勻交替執行插入的，參考下圖。

結論：
1，至少在MySQL 8.0下，innodb_autoinc_lock_mode 的值設置爲0或者2的狀況下，在性能上，沒有發現明顯的差別。
2，開啓binlog的狀況下，多是測試數據量或者併發量不夠，未發現比沒有開啓binlog有明顯的性能降低。

 

另外：
一開始本地的Python鏈接5.7是沒有問題的，鏈接MySQL8.0是直接報錯，而後升級pymysql便可，
pymysql的版本筆者直接從0.7升級到0.9，不知道0.8版本的是否能夠鏈接MySQL 8.0。

 

 

20190701：感謝@接天居士的提示，在多核心CPU的配置環境下測試，確實是有差別的，感謝糾錯，原本想刪除這篇文章的，留着當錯教訓吧，測試環境差別形成的錯誤教訓

 

關於innodb_autoinc_lock_mode參數，參考:
http://seanlook.com/2017/02/16/mysql-autoincrement/
http://www.javashuo.com/article/p-ruuehzgg-hu.html