Even after specifying all the 3 columns to coerce MySQL into choosing
the right multi-column index, it sometimes uses 2 separate indices
and does an index_merge of them.
This creates problems because the DeleteAt=0 search is essentially
the entire Posts table, and causes a disastrously bad performance
than even choosing the wrong index (idx_create_at).
The problem with this approach is that we hardcode the decision
to a specific index when MySQL was free to choose the right index
depending on table statistics. However, there does not appear to be
a case where this index can cause regressions than using some other index.
Another option here was to set optimizer_switch="index_merge_intersection=off"
at a session level for a transaction and then switch it back on after the
query is done.
However, this can cause some unintentional consequences because this setting
is only available at a session level and not at a query level.
There is no need to set something at the session level when an index hint suffices.
https://mattermost.atlassian.net/browse/MM-27575
8138600dd1