innodb表級鎖

Question

我們幾乎每天在測試服務器上都面臨表級鎖定問題。

TRANSACTION 0, not started
mysql tables in use 97, locked 97
MySQL thread id 429, OS thread handle 0x2aff6ff59700, query id 24900 ec2-*-*-*-*.compute-1.amazonaws.com *.*.*.* sminq cleaning up
---TRANSACTION 10631403, not started
MySQL thread id 321, OS thread handle 0x2aff7b359700, query id 24901 115.112.140.139 sminq init
show engine innodb status
---TRANSACTION 10632661, not started
MySQL thread id 13, OS thread handle 0x2aff4e39a700, query id 24817 localhost 127.0.0.1 rdsadmin cleaning up
---TRANSACTION 10632664, not started
MySQL thread id 6, OS thread handle 0x2aff396c5700, query id 24873 ec2-*-*-*-*.ap-southeast-1.compute.amazonaws.com *.*.*.* sminq cleaning up
---TRANSACTION 10632655, not started
MySQL thread id 7, OS thread handle 0x2aff39706700, query id 24783 ec2-*-*-*-*.ap-southeast-1.compute.amazonaws.com *.*.*.* sminq cleaning up
---TRANSACTION 10632652, not started
MySQL thread id 3, OS thread handle 0x2aff37d28700, query id 24745 ec2-*-*-*-*.ap-southeast-1.compute.amazonaws.com *.*.*.* sminq cleaning up
---TRANSACTION 10627075, not started
MySQL thread id 1, OS thread handle 0x2aff37ca6700, query id 0 Waiting for background binlog tasks
---TRANSACTION 10632663, ACTIVE 7 sec
mysql tables in use 1, locked 1
MySQL thread id 431, OS thread handle 0x2aff37daa700, query id 24863  172.31.3.120 sminq Waiting for table level lock
insert into `sminq`.`Queue_token` (`token_queue_id`,    `total_process_time`, `token_user`, `created_on`, `join_date`, `join_time`, `app_type`, `token_user_group`, `uuid`) values (13, 10, 87, '2016-07-21 04:47:04.157000', '2016-07-21 10:17:04', '10:10:00', 1, NULL, 'D<??BY??7?gk?Uo')
Trx #rec lock waits 0 #table lock waits 0
Trx total rec lock wait time 0 SEC
Trx total table lock wait time 0 SEC
---TRANSACTION 10632646, ACTIVE 45 sec

這些僅發生在插入中，我們從未遇到過更新或刪除的問題。

我的隔離級別為READ-COMMITTED，以及innodb_autoinc_lock_mode = 2

同一服務器的mysqltuner輸出

[--] Up for: 2h 11m 55s (25K q [3.230 qps], 478 conn, TX: 3M, RX: 1M)
[--] Reads / Writes: 82% / 18%
[--] Binary logging is enabled (GTID MODE: OFF)
[--] Total buffers: 1.5G global + 17.0M per thread (100 max threads)
[!!] Maximum reached memory usage: 3.0G (152.35% of installed RAM)
[!!] Maximum possible memory usage: 3.1G (156.50% of installed RAM)
[OK] Slow queries: 0% (0/25K)
[!!] Highest connection usage: 95%  (95/100)
[OK] Aborted connections: 0.00%  (0/478)
[!!] Query cache is disabled
[OK] Sorts requiring temporary tables: 0% (0 temp sorts / 1K sorts)
[OK] Temporary tables created on disk: 24% (424 on disk / 1K total)
[OK] Thread cache hit rate: 80% (95 created / 478 connections)
[OK] Table cache hit rate: 129% (291 open / 224 opened)
[OK] Open file limit used: 0% (64/65K)
[OK] Table locks acquired immediately: 99% (6K immediate / 6K locks)
[OK] Binlog cache memory access: 100.00% ( 1618 Memory / 1618 Total)

-------- MyISAM Metrics -----------------------------------------------------
[!!] Key buffer used: 18.5% (1M used / 8M cache)
[OK] Key buffer size / total MyISAM indexes: 8.0M/2.4M
[!!] Read Key buffer hit rate: 82.2% (90 cached / 16 reads)

-------- InnoDB Metrics -----------------------------------------------------
[--] InnoDB is enabled.
[OK] InnoDB buffer pool / data size: 1.3G/29.0M
[!!] InnoDB buffer pool instances: 8
[!!] InnoDB Used buffer: 1.32% (1139 used/ 86584 total)
[OK] InnoDB Read buffer efficiency: 99.86% (713109 hits/ 714137 total)
[!!] InnoDB Write buffer efficiency: 0.00% (0 hits/ 1 total)
[OK] InnoDB log waits: 0.00% (0 waits / 4915 writes)

由於這是測試服務器，因此我們在t2.small上運行測試

Answer 1

1.3GB buffer_pool是否在2GB RAM中？ 這可能導致大量交換，這確實對性能不利。

對於2GB的RAM和僅29M的數據，讓我們設置innodb_buffer_pool_size = 100M 。 現在就足夠了，以后再用（隨着數據的增長）就可以了。

（建議70％或80％僅適用於至少具有4GB RAM的計算機。）

解決這個。 如果問題仍然存在，請使用較新的值以及有關表的SHOW CREATE TABLE更新問題。

Answer 2

AUTO-INC鎖是一種特殊的表級鎖，由插入到具有AUTO_INCREMENT列的表中的事務獲取。 在最簡單的情況下，如果一個事務正在向表中插入值，那么任何其他事務都必須等待自己在該表中進行插入，以便第一個事務插入的行接收連續的主鍵值。

innodb_autoinc_lock_mode配置選項控制用於自動增量鎖定的算法。 它使您可以選擇如何在可預測的自動增量值序列與插入操作的最大並發性之間進行權衡。

對於“傳統”，“連續”或“交錯”鎖定模式，允許的值為0、1或2

innodb_autoinc_lock_mode = 2（“交錯”鎖定模式）

在這種鎖定模式下，沒有“類似於INSERT的”語句使用表級的AUTO-INC鎖定，並且可以同時執行多個語句。 這是最快，最具擴展性的鎖定模式，但是當使用基於語句的復制或恢復方案從二進制日志中重放SQL語句時，這是不安全的。

在這種鎖定模式下，可以確保自動增量值是唯一的，並且在所有同時執行的“類似INSERT”語句中單調遞增。 但是，由於多個語句可以同時生成數字（也就是說，在語句之間交錯分配數字），因此為任何給定語句插入的行生成的值可能不是連續的。

如果唯一執行的語句是“簡單插入”，其中要提前知道要插入的行數，則為“除混合模式插入”外，為單個語句生成的數字將沒有間隙。 但是，執行“批量插入”時，任何給定語句分配的自動增量值可能存在間隙。

請參閱源鎖定，然后根據需要修改配置。