-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
bad index stats after table cut-over #875
Comments
@cenkore 👋 thanks for reporting this, I think this solution makes sense 👍 Initially I was concerned about the overhead of running
I've also confirmed that the index stats are persisted through a |
As discussed with @tomkrouper (offline): if the server running the cut-over is In this case only the replica that ran This logic would work if the server running the cut-over is |
https://dev.mysql.com/doc/refman/5.7/en/analyze-table.html |
we are facing an issue lately that query plan maybe go wrong in a short time after alter a small table (180,000 rows).
After in-depth analysis, we found a _gho table cut-over before the statistics persisted, the new table initial opening would read persistent data in mysql.innodb_index_stats / mysql.innodb_table_stats, but there is no statistics at this time , and execution plan will go wrong in a short time until persistent recalculation requested.
repro:
after row-copy complete,query 2 sqls,
show index from _xx_gho
andmysql.innodb_index_stats
, and after cut-over , query again.first stage < after row-copy complete >:
second stage < after row-copy complete >:
solution:
Add analyze table operation (on the _gho table) after row copy complete, the statistics would be persisted then cut-over table.
Thanks.
The text was updated successfully, but these errors were encountered: