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
Performance issue for the MySQLSchema doEmpty() call #2123
Comments
I don't believe using What definitely should be done though is replacing those |
Seems legit. If you wish, I can try the query beforehand. |
Yes, could you try: Select
(Select 1 from information_schema.TABLES Where TABLE_SCHEMA=? limit 1) +
(Select 1 from information_schema.VIEWS Where TABLE_SCHEMA=? limit 1) +
(Select 1 from information_schema.TABLE_CONSTRAINTS Where TABLE_SCHEMA=? limit 1) +
(Select 1 from information_schema.EVENTS Where EVENT_SCHEMA=? limit 1) +
(Select 1 from information_schema.TRIGGERS Where TRIGGER_SCHEMA=? limit 1) +
(Select 1 from information_schema.ROUTINES Where ROUTINE_SCHEMA=? limit 1) Don't forget to replace |
The limit does not change the performance. |
This has now been fixed. The new query is Select SUM(found) from(
(Select 1 as found from information_schema.TABLES Where TABLE_SCHEMA='flyway_db' limit 1) union all
(Select 1 as found from information_schema.VIEWS Where TABLE_SCHEMA='flyway_db' limit 1) union all
(Select 1 as found from information_schema.TABLE_CONSTRAINTS Where TABLE_SCHEMA='flyway_db' limit 1) union all
(Select 1 as found from information_schema.EVENTS Where EVENT_SCHEMA='flyway_db' limit 1) union all
(Select 1 as found from information_schema.TRIGGERS Where TRIGGER_SCHEMA='flyway_db' limit 1) union all
(Select 1 as found from information_schema.ROUTINES Where ROUTINE_SCHEMA='flyway_db' limit 1)) as all_found; |
@axelfontaine I hit this issue on MySQL 5.7 using a Flyway version that contains the above mentioned fix. I believe it is not really solving the problem due to one specific "feature" of information_schema in mysql 5.x. As you can see here https://dev.mysql.com/doc/refman/5.7/en/information-schema-optimization.html (see the table there) the problem is around TRIGGERS query. With where on TRIGGER_SCHEMA, it scans all databases (confirmed with EXPLAIN). E.g. in my case it takes 45s, while I have 0 triggers, but around 2k DBs. |
…y-triggers-where Fix slow doEmpty by using EVENT_OBJECT_SCHEMA (#2123)
Which version and edition of Flyway are you using?
5.0.7.
But it's irrelevant as it's still in the last version of the file
Which client are you using? (Command-line, Java API, Maven plugin, Gradle plugin)
Java via Maven plugin
Which database are you using (type & version)?
MySQL 5.6 and 5.7
Which operating system are you using?
Linux. I don't put more info on that because it's (a priori) not relevant here.
Usage context
We have 1086 schema. In these schema, ~1000 have the same structure with 845 tables and views.
So our
information_schema
is a little heavy.What did you do?
flyway.migrate()
on a non Flyway migrated yet db (and so withbaselineOnMigrate
to true).What did you expect to see?
Relatively fast first migration.
What did you see instead?
Relatively slow first migration.
Why ?
The db has not been migrated with Flyway yet. So
schemaHistory
is empty.And, by following the Flyway process from here, a
schema.empty()
is called, which call thedoEmpty()
ofMySQLSchema
(in our case).But the
doEmpty()
is done via theinformation_schema
. And takes approximately 1min to do this method in our case.So ? What is the question ?
Why did you not use the SHOW methods ?
They are much more efficient than go through the
information_schema
.And another question would be is this performance problem can also exist on the other
Schema
children ?Thanks for the reading and have a great day !
The text was updated successfully, but these errors were encountered: