【环境介绍】
系统环境：Linux + mysql 5.7.18 + 主从复制架构
【背景描述】
客户反映用在mysql数据库上truncate一个innode引擎的list分区100G左右表时，耗时时间非常久，执行命令期间数据库运行非常缓慢，新连接无法登录，连旧连接都是卡主。
【问题处理】
数据库后台日志信息：
2018-04-17T07:01:50.963763Z 0 [Warning] InnoDB: A long semaphore wait:
--Thread 139922526992128 has waited at btr0sea.ic line 90 for 241.00 seconds the semaphore:
X-lock (wait_ex) on RW-latch at 0xa49e6a08 created in file btr0sea.cc line 195
a writer (thread id 139922526992128) has reserved it in mode wait exclusive
number of readers 1, waiters flag 1, lock_word: ffffffffffffffff
Last time read locked in file btr0sea.ic line 128
Last time write locked in file /export/home/pb2/build/sb_0-22759043-1489826356.96/mysql-5.7.18/storage/innobase/btr/btr0cur.cc line 3874
InnoDB: ###### Starts InnoDB Monitor for 30 secs to print diagnostic info:
InnoDB: Pending preads 0, pwrites 0
---BUFFER POOL 1
……
---BUFFER POOL 7
Buffer pool size 786336
Free buffers 240156
Database pages 546149
Old database pages 201625
Modified db pages 2
Pending reads 0
Pending writes: LRU 0, flush list 2, single page 0
Pages made young 116, not young 8649813
0.00 youngs/s, 0.00 non-youngs/s
Pages read 1978853, created 5, written 1217
0.00 reads/s, 0.00 creates/s, 0.00 writes/s
Buffer pool hit rate 1000 / 1000, young-making rate 0 / 1000 not 0 / 1000
Pages read ahead 0.00/s, evicted without access 0.00/s, Random read ahead 0.00/s
LRU len: 546149, unzip_LRU len: 0
I/O sum[0]:cur[0], unzip sum[0]:cur[0]
--------------
ROW OPERATIONS
--------------
0 queries inside InnoDB, 0 queries in queue
0 read views open inside InnoDB
Process ID=32294, Main thread ID=139922602555136, state: making checkpoint
Number of rows inserted 19058, updated 51, deleted 15, read 767102669
0.00 inserts/s, 0.00 updates/s, 0.00 deletes/s, 0.00 reads/s
从日志报错看跟innodb引擎的buffer pool相关
mysql> show VARIABLES like '%pool%'
-> ;
+-------------------------------------+----------------+
| Variable_name | Value |
+-------------------------------------+----------------+
| innodb_buffer_pool_chunk_size | 134217728 |
| innodb_buffer_pool_dump_at_shutdown | ON |
| innodb_buffer_pool_dump_now | OFF |
| innodb_buffer_pool_dump_pct | 25 |
| innodb_buffer_pool_filename | ib_buffer_pool |
| innodb_buffer_pool_instances | 8 |
| innodb_buffer_pool_load_abort | OFF |
| innodb_buffer_pool_load_at_startup | ON |
| innodb_buffer_pool_load_now | OFF |
| innodb_buffer_pool_size | 103079215104 |
从日志跟参数可以看出数据库innodb_buffer_pool_size96G，该参数相对较大，怀疑是有其他业务操作该表，但是客户反映该数据库为历史数据库，使用人很少。
| innodb_buffer_pool_size | 103079215104 |是96G，
---BUFFER POOL 7 Buffer pool size 786336 786336*16/1024/1024*8 是96G
truncate表清理数据是非常快的，从Old database pages上面信息推断数据在dirty_pages较多，扫描链表时间过长。于是查看dirty_pages_pct参数。
mysql> show variables like '%dirty%';
+--------------------------------+-----------+
| Variable_name | Value |
+--------------------------------+-----------+
| innodb_max_dirty_pages_pct | 90.000000 |
| innodb_max_dirty_pages_pct_lwm | 0.000000 |
+--------------------------------+-----------+
InnoDB tries to flush data from the buffer pool so that the percentage of dirty pages does not exceed
this value. The default value is 75.
从官方文档看出，innodb_max_dirty_pages_pct默认值为75%，但是当前数据库为90%，可以说是很高的了。咨询该参数修改情况，为之前模板复制过来直接运用。
【解决办法】
根据当前数据库为历史数据库，应用连接数据库操作非常少，建议innodb_max_dirty_pages_pct参数调为50%。
当前数据库内存较高，暂时不建议对innodb_buffer_pool_size 调小，可根据后续调整该参数。