fhumanes 6/26/2021 | |
I think the product version has included variations in the construction of the SELECT of that page. From my point of view, you should see the SELECT that runs and analyze it. I advise you to use the information of this article: https://fhumanes.com/blog/guias-desarrollo/guia-12-phprunner-optimizar-accesos-a-mysql/ Greetings, |
admin 6/30/2021 | |
What Fernando says, you need to see SQL query of both apps to notice the difference. Most likely in 10.5 you are using a feature that doesn't exist in version 10.4 and some database indexes are missing making this feature slow. |
M
|
ManniS author 7/20/2021 |
Hi all, |
admin 7/20/2021 | |
So, what is the SQL query that runs slow? |
M
|
ManniS author 7/20/2021 |
its the upper log . |
A
|
acpan 7/20/2021 |
SQL search on concatenated fields will not use the index and will perform full table scan, try to select individual fields than concatenate fields. Read this |
admin 7/23/2021 | |
What @acpan says. Another option is to add a new index on the concatenated expression. |
A
|
acpan 7/23/2021 |
Yes, @admin on the concat index. Proper index is most important when comes to speed. You need to ensure that esp with a complex query. Also you should probably cut out the query that is slow in TEXT form, and place it here to examine or run EXPLAIN SQL to analyze the index efficiency.
The slow part is highlighted, 6 sec longer on the upper log, in which the sql statement seems not the same with the lower one, it is "thicker" than the lower one, and i can see the left-join statement on the lower log but not the upper log. As said, no one can tell by looking at screenshots full of characters, need to see how the SQL is constructed and if the two are exactly the same, i.e. only PHPR version different and you did not change anything, sometimes we change something but we may forget. eg. we may just check on one more quick search field, that is not indexed and that alone can cause a full table scan when it forms part of the query statement. |
HJB 7/26/2021 | |
|