ENH Speed up query in stagesDifferInLocale by hinting the use of index

[juanjosegzl]

Description

We found a case where the query in stagesDifferInLocale takes a long time to complete, because it is not using the right index.

The issue doesn't seem to occur for other accounts. On closer look, the
site is waiting for the following SQL query

SELECT VL.Version
  FROM LOExtension_Localised_Versions as VL
  INNER JOIN LOExtension_Versions as V
    ON VL.RecordID = V.RecordID AND VL.Version = V.Version
  WHERE VL.RecordID = 154 AND VL.Locale = 'en_US' AND V.WasPublished = 0
  ORDER BY VL.Version DESC
  LIMIT 1;

which takes about nearly 3 minutes(!) to complete, because LIMIT 1
lures MariaDB into not using the right index. Compare the query plans
without the LIMIT 1 (execution time 1.359s)

+------+-------------+-------+--------+-----------------------------------+---------------+---------+----------------------------------+------+-----------------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+------+-------------+-------+--------+-----------------------------------+---------------+---------+----------------------------------+------+-----------------------------+
| 1 | SIMPLE | V | ref | RecordID_Version,RecordID,Version | RecordID | 4 | const | 8414 | Using where; Using filesort |
| 1 | SIMPLE | VL | eq_ref | Fluent_Record,Fluent_Version | Fluent_Record | 41 | const,const,extensions.V.Version | 1 | Using where; Using index |
+------+-------------+-------+--------+-----------------------------------+---------------+---------+----------------------------------+------+-----------------------------+

and now with the LIMIT 1 (execution time 165.333s)

+------+-------------+-------+--------+-----------------------------------+---------------+---------+----------------------------------+------+--------------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+------+-------------+-------+--------+-----------------------------------+---------------+---------+----------------------------------+------+--------------------------+
| 1 | SIMPLE | V | index | RecordID_Version,RecordID,Version | Version | 4 | NULL | 227 | Using where |
| 1 | SIMPLE | VL | eq_ref | Fluent_Record,Fluent_Version | Fluent_Record | 41 | const,const,extensions.V.Version | 1 | Using where; Using index |
+------+-------------+-------+--------+-----------------------------------+---------------+---------+----------------------------------+------+--------------------------+

Using an index hint to force MySQL to use the right index

SELECT VL.Version
  FROM LOExtension_Localised_Versions as VL
  INNER JOIN LOExtension_Versions as V USE INDEX (RecordID_VERSION)
    ON VL.RecordID = V.RecordID AND VL.Version = V.Version
  WHERE VL.RecordID = 154 AND VL.Locale = 'en_US' AND V.WasPublished = 0
  ORDER BY VL.Version DESC
  LIMIT 1;

completes in 1.114s.

Manual testing steps

Querying the modified queries directly in mysql client.

Issues

Pull request checklist

• The target branch is correct
  • See picking the right version
• All commits are relevant to the purpose of the PR (e.g. no debug statements, unrelated refactoring, or arbitrary linting)
  • Small amounts of additional linting are usually okay, but if it makes it hard to concentrate on the relevant changes, ask for the unrelated changes to be reverted, and submitted as a separate PR.
• The commit messages follow our commit message guidelines
• The PR follows our contribution guidelines
• Code changes follow our coding conventions
• This change is covered with tests (or tests aren't necessary for this change)
• Any relevant User Help/Developer documentation is updated; for impactful changes, information is added to the changelog for the intended release
• CI is green

[GuySartorelli]

... takes about nearly 3 minutes(!) to complete, because LIMIT 1 lures MariaDB into not using the right index

Do you have any insights into why that is? If possible I'd prefer to find a solution to this that doesn't require specifying what index to use, since this class of problem is likely to be all over the place.