Optimize query to determine whether a frontend user has access to content elements or pages
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)
Updated by Björn Pedersen over 10 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 Alexander Opitz almost 6 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.