-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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 loss in MySQL 5 and MariaDB schema introspection #5195
Comments
@xprojects-de please provide the steps to reproduce the scenario where you see the performance loss. |
It is best seen when you call the createSchema in the AbstractSchemaManager using an exsiting Connection. ###EDIT Especially the fetchAllAssociative inside the listTableForeignKeys is much slower, finally at the PDO->query... Do you need more informations? |
but I think that the mass of requests make up the loss here. In the profile files you can see that every query itself is just a bit slower, e.g. from 1 to 2ms. This is not so noticeable with smaller queries ... |
@xprojects-de given that only you can reproduce the issue, you could look into the 3.3.0 release notes and see if there are any changes that look like a root cause. Then try reverting them and comparing the resulting performance with 3.2.2. If the offending change cannot be identified logically, you could try using Once you point out a specific change, we can see if we can reproduce the performance issue in a generic way. |
Hello, the performance loss comes as follow: From 932c596 (932c596) Reason for that is the getListTableForeignKeysSQL(). from: ` public function getListTableForeignKeysSQL($table, $database = null)
To:
This fits with the assumption that it is specifically due to the createSchema ... Greetings |
Thanks, @xprojects-de. The changes you're referring to were made in #5071. Could you look at the description and see which of the following changes causes the issue:
|
-- Good one
SELECT k.CONSTRAINT_NAME,
k.COLUMN_NAME,
k.REFERENCED_TABLE_NAME,
k.REFERENCED_COLUMN_NAME /*!50116,
c.UPDATE_RULE,
c.DELETE_RULE */
FROM INFORMATION_SCHEMA.KEY_COLUMN_USAGE k /*!50116
INNER JOIN INFORMATION_SCHEMA.REFERENTIAL_CONSTRAINTS c
ON c.CONSTRAINT_NAME = k.CONSTRAINT_NAME AND c.TABLE_NAME = 'tl_alpdeskbookingcm_channels' */
WHERE k.TABLE_NAME = 'tl_alpdeskbookingcm_channels'
AND k.TABLE_SCHEMA = 'contaoalpdeskbooking' /*!50116
AND c.CONSTRAINT_SCHEMA = 'contaoalpdeskbooking' */
ORDER BY k.ORDINAL_POSITION;
-- Bad One
SELECT k.CONSTRAINT_NAME,
k.COLUMN_NAME,
k.REFERENCED_TABLE_NAME,
k.REFERENCED_COLUMN_NAME /*!50116,
c.UPDATE_RULE,
c.DELETE_RULE */
FROM INFORMATION_SCHEMA.KEY_COLUMN_USAGE k /*!50116
INNER JOIN INFORMATION_SCHEMA.REFERENTIAL_CONSTRAINTS c
ON c.CONSTRAINT_NAME = k.CONSTRAINT_NAME AND c.TABLE_NAME = k.TABLE_NAME AND
c.CONSTRAINT_SCHEMA = k.CONSTRAINT_SCHEMA */
WHERE k.TABLE_NAME = 'tl_alpdeskbookingcm_channels'
AND k.TABLE_SCHEMA = 'contaoalpdeskbooking'
ORDER BY k.ORDINAL_POSITION; So it´s the third change on replacing the c.constraint_schema to an ON condition... Greetings |
When I run the above queries against an arbitrary test table that has foreign keys, I get identical execution plans:
@xprojects-de, could you do the same on some table(s) from your schema and see if the two queries yield different plans? Additionally, it's not clear if it's the |
Now i don´t understand it anymore: Try on MYSQL:
Try on MariaDB:
But doing the same using PHP there is a massive performance loss!?!?!? Does the "Scanned all databases" has an impact here? Maybe we have to keep in mind that every query itself is just a bit slower (in my case from 3ms to 18ms) and maybe the time adds up. But you should also see that via mysql !?!? ###edit Also logged the real SQL-Code from PHP and it differs just a bit but result is the same...
|
Yeah, probably the "Scanned all databases" is the culprit. As I understand it, using What MySQL version are you using? Your execution plans yield just two rows while mine yield thirteen on MySQL 8.0.23. Although I see the two-row plans on Maria DB 10.6.5 (which corresponds to some older MySQL). From the documentation:
It looks like MySQL stores the information schema (specifically, the Unless I find a good way to avoid scanning all databases, I'll revert the offending change in the query. |
Thanks a lot! Sound great. Yeah!! ... currently i use MYSql5 and MariaDB 10.5... @m-vo Thanks for help and the hint "Scanning all databases"!!! |
@xprojects-de Can you check against the latest 3.3.x-dev version and tell us if the problem is gone now? |
Tested! Now it works great! Thanks to all... |
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
Bug Report
Summary
After upgrading dbal from 3.2 to 3.3 there is a massive performance loss. (In my case over 50%)!
Same code, same query, same environment (LAMP-Stack, PHP 8.1, MariaDB 10.x).
Testet and profiled also on different servers and different requests. Same behaviour...
Also the database process is fully utilized!
The weird thing is that finally the native php::PDO->query is extremly slow! Don´t know exactly why, maybe there are different preconditions......
(see also Call-Tree in profile files...)
Expected behaviour
maybe as fast or faster than 3.2.x :-)
installtool_3.2.gz
installtool_3.3.gz
###Edit
Profilefiles are normal xdebug profiles files... :-)
The text was updated successfully, but these errors were encountered: