Tim Westervoorde added a comment - 2017-08-24 06:38 This seems valid for my case. A table with ~450k rows is completely rebuild along with a 2nd table with 1.7m rows which references this table. So there are a lot of insert / delete statements in a short period of time, within a transaction. If there is anything I can debug for you let me know, I can trigger this to happen by running the same update script over and over again Kind regards, Tim

Marko Mäkelä added a comment - 2017-08-24 06:48 A prerequisite of this bug is that a non-root node pointer page is filled with records that carry the (garbage) delete-mark flag. There is no problem if all root page records are ‘delete-marked’ or if all leaf page records are delete-marked. So, the minimum required index tree height is 3, that is, 2 levels of node pointers above the leaf level. Because the maximum PRIMARY KEY length is so small (768 bytes on innodb_page_size=4k; 3072 bytes on innodb_page_size=16k), I thought that it is infeasible to create an ’organic’ test for this. Yes, I could pad the leaf page record sizes with non-key columns, but if each node pointer page will have at least 4 records, I’d still need quite a few row before the node pointer page is split. I was able to reproduce this by using debug instrumentation, adapting the great innodb.innodb_bug14676111 test painstakingly created by Yasufumi Kinoshita: --source include/have_innodb.inc --source include/have_debug.inc   CREATE TABLE t(a INT UNSIGNED PRIMARY KEY) ENGINE=InnoDB STATS_PERSISTENT=1 STATS_SAMPLE_PAGES=1;   BEGIN; # Create an index tree of height 3. # This is adapted from innodb.innodb_bug14676111.   SET @save_debug = @@GLOBAL.innodb_limit_optimistic_insert_debug; SET GLOBAL innodb_limit_optimistic_insert_debug=2;   INSERT t VALUES(1),(5); DELETE FROM t; INSERT t VALUES(4); DELETE FROM t; INSERT t VALUES(3); DELETE FROM t; SET GLOBAL innodb_limit_optimistic_insert_debug = @save_debug;   connect(con1, localhost, root,,); ANALYZE TABLE t; disconnect con1;   connection default; DROP TABLE t;

Marko Mäkelä added a comment - 2017-08-24 07:09 I introduced this bug in MDEV-12698 in MySQL 10.2.7 with the following change: @@ -1392,13 +1388,10 @@ dict_stats_scan_page( Because offsets1,offsets2 should be big enough, this memory heap should never be used. */ mem_heap_t* heap = NULL; - const rec_t* (*get_next)(const rec_t*); - - if (scan_method == COUNT_ALL_NON_BORING_AND_SKIP_DEL_MARKED) { - get_next = page_rec_get_next_non_del_marked; - } else { - get_next = page_rec_get_next_const; - } + const rec_t* (*get_next)(const rec_t*) + = srv_stats_include_delete_marked + ? page_rec_get_next_const + : page_rec_get_next_non_del_marked; const bool should_count_external_pages = n_external_pages != NULL; This change wrongly causes the bogus (garbage) delete-mark flags to be considered on node pointer pages. The only MariaDB Server releases that are affected by this bug are 10.2.7 and 10.2.8.

Andrii Nikitin (Inactive) added a comment - 2017-09-08 10:59 To workaround the problem (besides upgrade when 10.2.9 is released) one may try to disable persistent statistics : put following line into [mysqld] section of .cnf file: innodb_stats_persistent=0 To disable persistent stats for current server without restart - execute SQL command: set global innodb_stats_persistent=0;

Guangpu Feng added a comment - 2019-06-17 02:21 set global innodb_stats_persistent= 0 ; will not workaround this bug, verified in 10.2.8.