Почему разный план выполнения запроса при одинаковых таблицах и конфигах?

Question

danforth @danforth

Почему разный план выполнения запроса при одинаковых таблицах и конфигах?

Есть два сервера:

сервер на Vultr, 2GB, 1x core
виртуалка Vagrant, 2GB, 1x core

Одинаковые OC: Ubuntu Xenial x64
Одинаковые версии MariaDB: 10.2.14-MariaDB-10.2.14+maria~xenial-log
Одинаковая версия движка InnoDB: 5.7.21
Одинаковый конфиг MariaDB (дефолтный): https://pastebin.com/4PT1vtUF
Одинаковые таблицы и количество строк в них (CREATE TABLE)

Есть запрос:

SELECT br.id, br.slug, br.name, br.location, br.postal_code, br.phone, br.branch_deposit, br.established,
br.working_hours, br.is_published, br.created_at, br.updated_at, c.id, c.name, c.slug, s.id, s.name, s.slug,
s.ansi_code 
FROM branch AS br 
JOIN city AS c ON c.id = br.city_id 
JOIN state AS s ON s.id = c.state_id 
WHERE br.bank_id = ? ORDER BY br.branch_deposit DESC LIMIT 10

Время выполнения на серверах разное:
На локальном сервере: 0.0001s
На VPS Vultr: 0.44s

На это влияет разный QUERY EXECUTION PLAN:
Локальный сервер: https://pastebin.com/51ayGWpX
Боевой сервер: https://pastebin.com/JTqME9Bk

Вопрос: почему это возникает, при практически идентичном конфиге железа (SSD диски, одинаковое количество памяти)? Ну и самое важное: как это исправить?

Что пробовал:

OPTIMIZE/ANALYZE TABLE

P.S.: время выполнения указано без использования query_cache.

upd:
Коллега подсказал создать составной индекс по (bank_id, branch_deposit), и переписать запрос таким образом:

SELECT STRAIGHT_JOIN br.id, br.slug, br.name, br.location, br.postal_code, br.phone, br.branch_deposit, br.established,	br.working_hours, br.is_published, br.created_at, br.updated_at, c.id, c.name, c.slug, s.id, s.name, s.slug, s.ansi_code 
FROM branch AS br FORCE INDEX(bank_id_branch_deposit) 
JOIN city AS c FORCE INDEX(PRIMARY) ON c.id = br.city_id 
JOIN state AS s ON s.id = c.state_id 
WHERE br.bank_id = ?
ORDER BY br.branch_deposit DESC 
LIMIT 10

...И запрос ускорился, значительно! Но, отвалился ещё один запрос, опять оптимизатор начал использовать не те индексы, что пугает.

upd2:
перезалил дамп базы с локального сервера, на боевой - и оптимизатор пришел в себя. Что это было, так и не понял, судя по всему накопленная статистика давала оптимизатору принимать не правильные решения.