Thanks, in the case of last two indexes, we saw a reduction of 10k queried rows due the multiplication factor of the later joins so even though the reduction in the primary table wasn't very large, the overall impact was worth it.
Also index on xf_resource (resource_state, resource_category_id) yes that way round, for:
SELECT resource.*,
category.*, category.last_update AS category_last_update, resource.last_update,
version.version_string...
Another one, less major but still likely worth it is an index on find_new on xf_forum for:
SELECT thread.*,
user.*, IF(user.username IS NULL, thread.username, user.username) AS username,
node.title AS node_title...
Hi guys I enabled logging of queries without indexes and spotted the following query running:-
SELECT notice_id
FROM xf_notice_dismissed
WHERE user_id = '389'
This is very expensive as there is no index on user_id, adding this dropped queried rows significantly as you might expect.
If its commented out its the default which is 1000, and yes this could be causing may more issues and silently hiding them, I've raised the bug here:-
http://xenforo.com/community/threads/max_input_vars-errors-silently-hidden.34171/
We hit a problem using the plugin User Ranked Ribbons, with the new version it added more ribbon options to the style control panel, this broke saving of the style group properties. After digging around the problem is cause by xenForo's _getInputFromSerialized method which reads in a large block...
Actually found the real cause, xenForo's input method is blowing up with the error "parse_str(): Input variables exceeded 1000. To increase the limit change max_input_vars in php.ini." unfortunately this is hidden as "throw" is set to false so it silently fails. This will only happen on PHP >...
Just installed this on a test site and if you attempt to edit the style it disables everything.
Ticking "Enable / Disable User Rank Ribbons" and saving at the doesn't stick its just disabled when you go back in :(
xenForo 1.1.3