-
Notifications
You must be signed in to change notification settings - Fork 190
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Run ANALYZE TABLE after table copy #109
Comments
I guess we will need this indeed.. |
No manual run, however is this even needed after an LHM? My understanding is that the LHM pretty much creates a new table, @sroysen will know for sure if it is of any benefit. One thing to keep in mind regardless on any kind of high troughput table is that the LHM lock as is already can cause problems, this might increase the lock time, if implemented I'd say opt-in is the way to go. cc @shuhaowu |
I think you are right that it's not needed by default: if innodb_stats_auto_recalc is enabled then index stats are automatically recalculated whenever the table changes more than 10%. It looks like it's enabled by default, so that's fine. I've seen some recommendations to temporarily disable auto recalc while running a large import, since it makes sense that it would slow things down to recalculate continuously while adding new records. I don't remember now, but I might have been playing with that as an optimization around LHM, hence this ticket. Do you think it's worth investigating this as an optimization? Otherwise feel free to close this ticket. |
I think it could be an opt-in feature but never the default. My 2 cents. |
@camilo is right and I share his opinion: innodb_stats_auto_recalc is enabled by default, so under normal circumstances there is no need to run an |
From the MySQL docs on the matter:
Because it involves a table read-lock, I would propose it's a good opportunity to do this after copying all the data into the new table, before swapping the names back. Thoughts?
The text was updated successfully, but these errors were encountered: