rvexcludeuser may be the problem here. Queries with explicitly exclude something are usually expensive (where not exists, where X not in, or where A <> B). Maybe this is causing the query to not using the proper indices.

The odd thing here is that even using page_timestamp it should only have to touch a maximum of about 1676 rows when using the page_timestamp index, since that's how many rows pass rev_page = 6097020. This reminds me of T196526: Geodata running long running queries on Commons, and in fact I find the same oddities here that I described in T196526#4276656.

It's starting to look like MariaDB 10.1.33 has a planner bug where multiple candidate indexes cause it to choose a completely stupid plan that wants to scan the whole table using the index and filesort it.

As discussed via email, this bug was fixed on 10.1.37: https://jira.mariadb.org/browse/MDEV-17155 which could end up "fixing" this issue. We'll see once 10.1.37 is released and we can test it with these queries.

https://downloads.mariadb.org/ 10.1.37 not yet considered stable at the time of writing this. While we could deploy something from the tree, that is a big no for database code (unlike other kinds of code I don't have a problem with doing that) unless there is an unbreak now bug. Once it is officially released I will build it and test it.

As discussed via email, this bug was fixed on 10.1.37: https://jira.mariadb.org/browse/MDEV-17155 which could end up "fixing" this issue. We'll see once 10.1.37 is released and we can test it with these queries.

Looks like we were indeed hit by this bug. Upgrading to 10.1.37 shows a decent query plan now:
I have tested upgrading db2071 (enwiki) to 10.1.37

All the core replicas that receive this query are now running > 10.1.36 which doesn't have this optimizer "bug".
The masters aren't running those version, but they are not receiving (or shouldn't be) this queries so this is pretty much solved.