A large install is reporting performance issues with the primary query on the Audit dashboard. It looks roughly like this:

SELECT commits WHERE <YOU ARE THE AUTHOR> OR <YOU ARE AN AUDITOR>

MySQL can't use a single key to satisfy both parts of this, and ends up doing a full table scan in the EXPLAIN:

1	SIMPLE	commit	ALL	phid,authorPHID,key_author	NULL	NULL	NULL	<HUGE NUMBER>	Using where; Using temporary; Using filesort

We execute a similar query in Differential, which I simplified into a UNION in D6343 after some other efforts. This seems to have been a reasonable choice and has held up since 2013. It is likely that we can apply an essentially identical strategy here, which allows MySQL to use the "author" key for the author part and the "auditor" key for the auditor part.

An adjacent concern is that this query includes this subclause:

... commit.auditStatus IN ('2', '1', '5', '3') ...

I vaguely recall this -- use of strings when passing IDs to the query layer -- preventing key use in the past. It's worth double checking that we aren't missing any keys over the construction IN (2, 1, 5, 3), without quotes.