Feature #23724
closedOptimize query to determine whether a frontend user has access to content elements or pages
0%
Description
The WHERE part of the query to determine whether a frontend user has access to a particular element (tt_content in this example) looks like this:
(tt_content.fe_group='' OR tt_content.fe_group IS NULL OR tt_content.fe_group='0' OR FIND_IN_SET('0',tt_content.fe_group) OR FIND_IN_SET('-2',tt_content.fe_group) OR FIND_IN_SET('2',tt_content.fe_group))
It could look like the following (to simplify the OR parts for each group):
(pages.fe_group='' OR pages.fe_group IS NULL OR pages.fe_group='0' OR pages.uid IN (SELECT uid_local FROM pages_fe_groups_rel_mm WHERE uid_foreign IN (0,-2,2)))
(issue imported from #M15985)
Files
Updated by Björn Pedersen about 14 years ago
Be careful with subselects, mysql seems t have some performance problems:
http://bugs.mysql.com/bug.php?id=16159
See also http://bugs.typo3.org/view.php?id=15984 where this affects crawler (here up to 200 sec for a single update).
Updated by Björn Pedersen about 14 years ago
from: http://dev.mysql.com/doc/refman/5.1/en/subquery-restrictions.html (same also for 5.5) #
Subquery optimization for IN is not as effective as for the = operator or for the IN operator.
A typical case for poor IN subquery performance is when the subquery returns a small number of rows but the outer query returns a large number of rows to be compared to the subquery result.
The problem is that, for a statement that uses an IN subquery, the optimizer rewrites it as a correlated subquery. Consider the following statement that uses an uncorrelated subquery:
SELECT ... FROM t1 WHERE t1.a IN (SELECT b FROM t2);
The optimizer rewrites the statement to a correlated subquery:
SELECT ... FROM t1 WHERE EXISTS (SELECT 1 FROM t2 WHERE t2.b = t1.a);
If the inner and outer queries return M and N rows, respectively, the execution time becomes on the order of O(M×N), rather than O(M+N) as it would be for an uncorrelated subquery.
An implication is that an IN subquery can be much slower than a query written using an IN operator that lists the same values that the subquery would return. #
Updated by Oliver Hader about 14 years ago
Thanks Björn for pointing this out. What would be alternatives in this case? Use separate queries? Or rewrite this part to use LEFT JOIN?
I just added the current version of the patch (without further optimization to the subqueries)...
Updated by Xavier Perseguers over 13 years ago
- Category deleted (
Communication) - Target version deleted (
4.6.0-beta1)
Updated by Wouter Wolters almost 10 years ago
- Status changed from New to Needs Feedback
Hi,
as this issue is very old. Does the problem still exists within newer versions of TYPO3 CMS (6.2.9)?
Updated by Alexander Opitz over 9 years ago
- Status changed from Needs Feedback to Closed
No feedback within the last 90 days => closing this issue.
If you think that this is the wrong decision or experience this issue again, then please write to the mailing list typo3.teams.bugs with issue number and an explanation or open a new ticket and add a relation to this ticket number.