https://bugzilla.wikimedia.org/show_bug.cgi?id=57285
--- Comment #2 from Sean Pringle <[email protected]> --- The example query above had a FORCE INDEX (page_random) removed during testing: mysql wmf db1043 root enwiki> explain SELECT page_title, page_namespace FROM `page` force index (page_random) WHERE page_namespace = '446' AND page_is_redirect = '0' AND (page_random >= 0) ORDER BY page_random LIMIT 1\G *************************** 1. row *************************** id: 1 select_type: SIMPLE table: page type: range possible_keys: page_random key: page_random key_len: 8 ref: NULL rows: 15821483 Extra: Using index condition; Using where 1 row in set (0.25 sec) Simply removing the force allows invalid namespaces to be optimized away: mysql wmf db1043 root enwiki> explain SELECT page_title, page_namespace FROM `page` WHERE page_namespace = '446' AND page_is_redirect = '0' AND (page_random >= 0) ORDER BY page_random LIMIT 1\G *************************** 1. row *************************** id: 1 select_type: SIMPLE table: page type: ref possible_keys: name_title,page_random,page_redirect_namespace_len key: name_title key_len: 4 ref: const rows: 1 Extra: Using where; Using filesort 1 row in set (0.25 sec) This is actually a problem with both RandomPage::selectRandomPageFromDB and ApiQueryRandom::runQuery; both are showing up in slow logs with large index scans. Seems like the FORCE INDEX (page_random) isn't necessary for the mediawiki pseudo-random approach to function. The second example above allows a filesort but this is much lower impact than the massive index scan. Consider removing the force so that more appropriate indexes can be chosen (or added). -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
