[MDEV-18396] InnoDB table/index stats are incorrect if DISABLE/ENABLE keys is used Created: 2019-01-28 Updated: 2019-01-31 Resolved: 2019-01-31 |
|
| Status: | Closed |
| Project: | MariaDB Server |
| Component/s: | Data Definition - Alter Table |
| Affects Version/s: | 10.2 |
| Fix Version/s: | N/A |
| Type: | Bug | Priority: | Major |
| Reporter: | Jan Lindström (Inactive) | Assignee: | Jan Lindström (Inactive) |
| Resolution: | Not a Bug | Votes: | 0 |
| Labels: | None | ||
| Attachments: |
|
||||||||
| Issue Links: |
|
||||||||
| Description |
|
I did not test earlier releases but they could be also effected. I have attached mtr test case. If ENABLE/DISABLE keys clause is commented I see correct results (note that mysqldump will include those ENABLE/DISABLE keys clause by default):
If I remove the comment from ENABLE/DISABLE keys clause, I see incorrect results on index cardinality, table_rows and avg_row_length.
|
| Comments |
| Comment by Jan Lindström (Inactive) [ 2019-01-29 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
I have tested that MyISAM is not effected. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Marko Mäkelä [ 2019-01-29 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
This bug would have to be fixed outside InnoDB. I tried the following test case:
The output is rather clear:
Neither ha_innobase::check_if_supported_inplace_alter() nor ha_innobase::rename_table() was invoked. So, the DISABLE KEYS is invoking neither the ALGORITHM=INPLACE nor the ALGORITHM=COPY logic. I would not want to extend the persistent InnoDB data dictionary to allow metadata about disabled keys to be stored, because I would like to get rid of the InnoDB data dictionary (MDEV-11655) at some point. What is the use case for that? Bulk-loading would be better fixed by | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Jan Lindström (Inactive) [ 2019-01-30 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Why upper layer would somehow disable InnoDB clustered index (i.e. primary key in my example) and how that would effect InnoDB internal statistics calculation ? Or does it mean that result from that statistics calculation is not "published" to upper layer ? This is user reported problem on https://jira.mariadb.org/browse/MDEV-18226 but it has nothing to do with Galera. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Elena Stepanova [ 2019-01-31 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
The problem allegedly revealed by the test case has nothing to do with DISABLE KEYS / ENABLE KEYS, you'll have the same effect if you replace ENABLE KEYS with, for example, COMMENT 'foo', while DISABLE KEYS makes no difference at all:
In fact, the test case just has an insufficient sleep time. My wild uneducated guess would be that ALTER "queues" the second statistics recalculation, so at the end it takes twice as much time as it would normally have. If you double the sleep time, you'll get expected results.
Same happens if you keep sleep=5, but add another one before ALTER. |