Details
-
Task
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
Description
Based on the performance testing that was conducted in MDEV-17492, the InnoDB adaptive hash index could only help performance in specific, almost-read-only workloads. It could slow down all kinds of workloads (especially DROP TABLE, TRUNCATE TABLE, ALTER TABLE, or DROP INDEX operations), and it can become corrupted, causing crashes (such as MDEV-18815, MDEV-20203) and possibly data corruption. Furthermore, the adaptive hash index consumes space from the InnoDB buffer pool, which could hurt performance when the working set would almost fit in the buffer pool.
Given all this, it is best to disable the adaptive hash index.
Attachments
Issue Links
- relates to
-
MDEV-22646 Assertion `table2->cached' failed in dict_table_t::add_to_cache
- Closed
-
MDEV-24505 innodb.innodb-ucs2 test failed, assertion: list.count > 0, in file storage/innobase/include/ut0lst.h line 334
- Closed
-
MDEV-12121 Introduce build option WITH_INNODB_AHI to disable innodb_adaptive_hash_index
- Closed
-
MDEV-17492 Benchmark AHI to find cases where it's useful
- Closed
-
MDEV-18815 Server crashes on TRUNCATE TABLE
- Closed
-
MDEV-20203 InnoDB: Failing assertion: (block)->index || (block)->n_pointers == 0
- Confirmed
-
MDEV-31668 With certain queries, 10.6 is slower than 10.3
- Closed
- mentioned in
-
Page Loading...