You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[ ] latest
[ ] @next
[ ] 0.x.x (or put your version here)
Steps to reproduce or a small repository showing the problem:
In `MysqlQueryRunner`, `loadTables` performs queries to `INFORMATION_SCHEMA`, which is not optimized.
MySQL recommends adding a where clause with the schema and table for better performance - https://dev.mysql.com/doc/refman/5.7/en/information-schema-optimization.html.
There are 2 queries with a JOIN that have a where clause on the schema and table, but the where clause is only for one of the tables in the join.
In the foreign key query, this causes an actual bug (which is what https://github.com//pull/6169/files solves).
For large databases with many schemas, this can be a crucial improvement.
In our database, for example, each of these queries takes about **7.5 seconds**.
If a where clause is added to the second table in the join, the query takes around **200 milliseconds**.
The text was updated successfully, but these errors were encountered:
Issue type:
[x] bug report
[ ] feature request
[ ] documentation issue
Database system/driver:
[ ]
cordova
[ ]
mongodb
[ ]
mssql
[x]
mysql
/mariadb
[ ]
oracle
[ ]
postgres
[ ]
cockroachdb
[ ]
sqlite
[ ]
sqljs
[ ]
react-native
[ ]
expo
TypeORM version:
[ ]
latest
[ ]
@next
[ ]
0.x.x
(or put your version here)Steps to reproduce or a small repository showing the problem:
In `MysqlQueryRunner`, `loadTables` performs queries to `INFORMATION_SCHEMA`, which is not optimized.MySQL recommends adding a where clause with the schema and table for better performance - https://dev.mysql.com/doc/refman/5.7/en/information-schema-optimization.html.
There are 2 queries with a JOIN that have a where clause on the schema and table, but the where clause is only for one of the tables in the join.
In the foreign key query, this causes an actual bug (which is what https://github.com//pull/6169/files solves).
For large databases with many schemas, this can be a crucial improvement.
In our database, for example, each of these queries takes about **7.5 seconds**.
If a where clause is added to the second table in the join, the query takes around **200 milliseconds**.
The text was updated successfully, but these errors were encountered: