Катастрофическое планирование запросов, неиспользование индекса в MySQL 8+ ⇐ MySql

[Anonymous]

У меня есть устаревший сайт Drupal 7, который используется строго внутри. Его замена находится в активной разработке, но в то же время он использует Aurora2, MySQL 5.7, совместимый и находится в очень дорогой расширенной поддержке. Я понимаю, что я не единственный, кто недовольен производительностью, но некоторые запросы занимают около 40 000 раз дольше. Мало того, что его оптимизация плохой, но он явно не использует доступный индекс.SELECT
n.nid,
n.type,
n.title,
u.name,
u.uid,
n.changed AS date
FROM node n
JOIN node_revision nr ON n.vid = nr.vid
JOIN users u ON nr.uid = u.uid
ORDER BY n.changed DESC
LIMIT 100;
< /code>
mysql 5.7
100 строк в наборе (0,002 сек) < /p>
mysql 9.3.0
100 строк в наборе (1 мин 37,906 сек) < /p>
11.4.5-mariadb
100 rows in set 23.10. />8.0.mysql_aurora.3.09.0
100 строк в наборе (1 мин 52,591 сек) < /p>
Вот объяснение на запросе, разбитый тип сервера: < /p>
mysql 5.7 < /p>
< /p>
< /p>


id < /th>
select_type < /th>
table < /th>
разделения < /th>
type < /th>
возможный /> key_len < /th>
ref < /th>
Rows < /th>
фильтровал < /th>
Extra < /th>
< /tr>
< /thead>


/> simple < /td>
n < /td>
null < /td>
index < /td>
vid < /td>
node_changed < /td>
4 4 /> null < /td>
100 < /td>
100.00> , где < /td>
< /tr>

1 < /td>
< /td>
1 < /td>
< /td>
1 < /td>
< /td>
/> nr < /td>
null < /td>
eq_ref < /td>
первичный, uid < /td>
первичный < /td>
4 < /td>
/> 1 < /td>
100.00> null < /td>
< /tr>

1 < /td>
< /td>
u < /td>
< /td>
u < /td>
< /td>
u < /td> /> eq_ref < /td>
первичный < /td>
первичный < /td>
4 < /td>
db_id.nr.uid
1 < /td>
/> Использование, где < /td>
< /tr>
< /tbody>
< /table> < /div>
mysql 9.3.0
11.4.5-mariadb
8.0.mysql_aurora.3.09.0>

Подробнее здесь: https://stackoverflow.com/questions/796 ... in-mysql-8