问题：

db30.56 从0807 开始，每天晚上0点到1点10分左右，数据库被select堵死。

cpu（30%）有点高，内存(free 70G),IO 几乎没有。

20180808调整：

1、隔离级别从repetable read 降低到read committed。无效

2、具体的select 语句，在从库执行很快

3、从engine 日志里面，看不到死锁语句。

4、从engine 日志里面，看到大部分是rw-latch 锁。

InnoDB: ###### Diagnostic info printed to the standard error stream

InnoDB: Warning: a long semaphore wait:

--Thread 139562561287936 has waited at row0ins.cc line 2730 for 923.00 seconds the semaphore:

X-lock (wait_ex) on RW-latch at 0x7ef7b756b4a0 '&block->lock'

a writer (thread id 139562561287936) has reserved it in mode wait exclusive

number of readers 1, waiters flag 1, lock_word: ffffffffffffffff

Last time read locked in file row0sel.cc line 4152

Last time write locked in file /home/buildbot/buildbot/build/mariadb-10.0.28/storage/xtradb/row/row0ins.cc line 2730

InnoDB: Warning: a long semaphore wait:

--Thread 139562523481856 has waited at row0ins.cc line 2730 for 921.00 seconds the semaphore:

X-lock (wait_ex) on RW-latch at 0x7ef9c7eb5500 '&block->lock'

a writer (thread id 139562523481856) has reserved it in mode wait exclusive

number of readers 1, waiters flag 1, lock_word: ffffffffffffffff

Last time read locked in file buf0flu.cc line 1069

Last time write locked in file /home/buildbot/buildbot/build/mariadb-10.0.28/storage/xtradb/btr/btr0sea.cc line 979

根据rw-latch 资源锁的报错，重点怀疑两个参数有问题。

innodb_thread_concurrency=0 调整为128. 0 是不限制内核同时执行线程数。128是限制为同时最大跑128个线程。

innodb_adaptive_hash_index=on，暂时未做调整。自适应hash索引，默认开启，对于定值查询可以提高查询效率。

5、SQL 语句，有时候执行很快，有时候执行很慢。部署语句本身问题。

20180809：

问题有所缓解：原本堵70分钟的，现在晚上堵12分钟左右。

engine 内部资源竞争信息如下：

OS WAIT ARRAY INFO: reservation count 894320193, signal count 65638759

--Thread 139691756820224 has waited at btr0cur.c line 576 for 0.0000 seconds the semaphore:

S-lock on RW-latch at 0x5462c708 '&new_index->lock'

a writer (thread id 139692134643456) has reserved it in mode wait exclusive

number of readers 3, waiters flag 1, lock_word: fffffffffffffffd

Last time read locked in file btr0cur.c line 576

Last time write locked in file /mnt/workspace/percona-server-5.5-binaries/label_exp/centos5-64/Percona-Server-5.5.34-rel32.0/storage/innobase/ibuf/ibuf0ibuf.c line 411

--Thread 139692490811136 has waited at btr0cur.c line 576 for 0.0000 seconds the semaphore:

S-lock on RW-latch at 0x7f0c2bd1fdc8 '&new_index->lock'

a writer (thread id 139692778780416) has reserved it in mode exclusive

number of readers 0, waiters flag 1, lock_word: 0

Last time read locked in file btr0cur.c line 576

Last time write locked in file /mnt/workspace/percona-server-5.5-binaries/label_exp/centos5-64/Percona-Server-5.5.34-rel32.0/storage/innobase/btr/btr0cur.c line 569

20180813：

数据库从库升级到5.6，业务数据源切到从库。 原主库升级到5.6，做为slave

此时该参数故意设置为开启状态（自适应hash 索引）。

innodb_adaptive_hash_index=on            （没解决问题）

20180813 晚上

继续设置 innodb_adaptive_hash_index=off ,把自适应hash 索引关闭;

同时发现buffer 参数innodb_change_buffering为inserts， 表示只对insert索引列进行merge。 而本系统大部分并发4000个连接基本都是select。 

设置innodb_change_buffering=all

问题没有复现。

innodb_change_buffering：表示索引列merge对象，all表示对IDU索引列都起作用，都进行merge，如果只想对insert索引列进行merge，就把all改为inserts。

总结：

本次处理，主要了解MySQL中2个参数使用。

innodb_thread_concurrency、innodb_change_buffering

详细使用方法见上文。