Comment 3 for bug 1607300

Was this data stored within tokudb prior to 5.6.27-76.0? If so I suspect it is a row count error as described in here https://www.percona.com/doc/percona-server/5.6/tokudb/tokudb_background_analyze_table.html where TokuDB used to report the PerconeFT row counts, which were physical row counts and not logical row counts, meaning they could be >100% different between the two and eventually reach 0 which would result in a cardinality that does not reflect the make up of the index at all, possibly 0.

Tokudb follows the InnoDB model of reporting cardinality as a ratio of actual rows sampled to unique rows sampled * scaling% (where scaling % is 50% by default). The server then takes this information, along with the reported row counts and produces the index cardinality that you can see in the "SHOW INDEX ..." results.

The analysis starts from the left side of the index, if at half way through the specified time limit it is not yet half way through the reported number of rows, it will reverse direction and begin scanning from the right side of the index. This is to try to avoid one sided activity (deletions and/or insertions).

Can you also post the result of show table status as that might have some info that is useful.

Worst case, brute force would be to run RECOUNT_ROWS ANALYZE on the table, which might take some time depending the size of the table and how much garbage (unapplied messages) is in it followed by a STANDARD ANALYZE with a reasonably long timeout or even 0 for a full scan, but I would like to try to understand how it got here before blowing the evidence away.