To work around an optimizer bug in MySQL where the
index on (rev_page, rev_id) is picked which mysteriously
leads to very slow execution times and timeouts.
In theory, the index being forced here is (rev_id),
which is fine for this query. In WMF production,
it can also be (rev_id, rev_user) (still fine), or
(rev_page, rev_id) (the index we're trying to avoid).
Mysteriously, the optimizer bug doesn't happen if
(rev_page, rev_id) is the primary key, so this still
behaves OK.
Bug: T104313
Change-Id: I15c68ba29309dca8dea274f19389d139a82784aa
'rev_page' => $this->title->getArticleID(),
'rev_id' => $ids,
],
- 'options' => [ 'ORDER BY' => 'rev_id DESC' ],
+ 'options' => [
+ 'ORDER BY' => 'rev_id DESC',
+ 'USE INDEX' => [ 'revision' => 'PRIMARY' ] // workaround for MySQL bug (T104313)
+ ],
'join_conds' => [
'page' => Revision::pageJoinCond(),
'user' => Revision::userJoinCond(),