MySQL中出现很多latch锁,而这个很大程度上和MySQL自适应hash索引有关。
AHI概述
MySQL InnoDB存储引擎的自适应哈希(Adaptive Hash Index,下简称AHI)功能
若用户的访问模式基本都是类似KV操作的点查询(point select),则InnoDB存储引擎会自动创建哈希索引。
在有了哈希索引后,查询无需走B+树搜索,而直接通过hash就能直接定位查询的数据。
因此,通过AHI功能,MySQL的查询性能就能得到大幅提升。
查询能提升多少呢?对于写入操作又是否有影响呢?AHI有什么副作用么?
AHI对读写性能影响
查询压测
[root@VM-16-10-centos ~]# sysbench /usr/share/sysbench/oltp_point_select.lua --mysql-host=10.0.16.10 --mysql-port=3307 --mysql-user=cjr --mysql-password=cjr --mysql-db=sysbench --db-driver=mysql --tables=1 --table-size=10000000 --report-interval=1 --threads=2 --rand-type=uniform --max-requests=1000000 run >sysbench_off.log
[root@VM-16-10-centos ~]# sysbench /usr/share/sysbench/oltp_point_select.lua --mysql-host=10.0.16.10 --mysql-port=3307 --mysql-user=cjr --mysql-password=cjr --mysql-db=sysbench --db-driver=mysql --tables=1 --table-size=10000000 --report-interval=1 --threads=2 --rand-type=uniform --max-requests=1000000 run >sysbench_on.log
从下图可以看到,在AHI的加持下,主键查询可以达到2540的QPS:
但若当我们通过参数 innodb_adaptive_hash_index 关闭AHI功能后,主键查询的性能下跌了最高只达到2371QPS:
set global innodb_adaptive_hash_index =off;
DML压测
对于写入操作,开启和关闭AHI功能对性能的影响都没有太大的区别。
这是因为当DML测试时, MySQL 的瓶颈主要是在磁盘写入。
具体可以通过 sysbench 的 oltp_update_index.lua 基准测试进行观察。
sysbench /usr/share/sysbench/oltp_update_index.lua --mysql-host=10.0.16.10 --mysql-port=3307 --mysql-user=cjr --mysql-password=cjr --mysql-db=sysbench --db-driver=mysql --tables=1 --table-size=10000000 --report-interval=1 --threads=2 --rand-type=uniform --max-requests=1000000 run >sysbench_off.log
sysbench /usr/share/sysbench/oltp_update_index.lua --mysql-host=10.0.16.10 --mysql-port=3307 --mysql-user=cjr --mysql-password=cjr --mysql-db=sysbench --db-driver=mysql --tables=1 --table-size=10000000 --report-interval=1 --threads=2 --rand-type=uniform --max-requests=1000000 run >sysbench_on.log
打开AHI的情况
关闭AHI的情况
可以观察不管是否打开AHI,TPS都差不多
AHI的副作用
作为一个几乎透明的功能,其实一般用户无需关心,基本可以认为AHI是即开即用的功能。
默认AHI参数的设置也是比较合理的,例如参数 innodb_adaptive_hash_index_parts 设置为 8 。
然而,AHI存在一个副作用:当删除大表,且缓冲池(Buffer Pool,下简称BP)比较大,如超过32G,则MySQL数据库可能会有短暂被hang住的情况发生。
这时会对业务线程造成一定影响,从而导致业务系统的抖动。
产生这个问题的原因是在删除表的时候,InnoDB存储引擎会将该表在BP中的内存都淘汰掉,释放可用空间。
这其中包括数据页、索引页、自适应哈希页等。
当BP比较大是,扫描BP中flush_list链表需要比较长的时间,因此会产生系统的抖动。
因此在海量的互联网并发业务中,删除表操作需要做精细的逻辑控制,如:
-
业务低峰期删除大表;
-
删除表前禁用AHI功能;
-
控制脏页链表长度,只有长度小于一定阈值,才发起删除操作;
-
删除表后启用AHI功能;
不过呢,所有这么麻烦的处理在 MySQL 8.0.23 版本之后,就都不再需要了。
因为官方已经彻底修复了这个问题:
注意,截至目前最新的 MySQL 5.7.34 版本并没有进行修复,所以 5.7 还需要用户自己做控制。
总结
AHI真的是一个InnoDB的好功能,这才是真正的AI数据库该有的样子。
但InnoDB存储引擎在2001年发布时,就支持了这个功能,创始人Heikki Tuuri真可谓具有卓越的远见。
但在使用时,要特别注意删除大表可能产生的hang住问题。
这会对业务产生一定的影响,对于较高要求的业务来说,或许是不能接受的。
不过,若升级到 MySQL 8.0.23 版本后,这些问题将不复存在。
本文参考https://zhuanlan.zhihu.com/p/379683912
标签:--,性能,AHI,db,mysql,MySQL,sysbench From: https://blog.csdn.net/DBA_ChenJR/article/details/136857122