Why is there a different query execution plan for the same tables and configs?

Question

MySQL

There are two servers:

• server on Vultr, 2GB, 1x core
  
• virtual machine Vagrant, 2GB, 1x core
  

Same OC: Ubuntu Xenial x64
Same MariaDB versions: 10.2.14-MariaDB-10.2.14+maria~xenial-log
Same version of InnoDB engine: 5.7.21
Same MariaDB config (default): https://pastebin.com/4PT1vtUF
Same tables and the number of rows in them ( CREATE TABLE )
There is a query:

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

Execution time varies on servers:
On local server: 0.0001s
On VPS Vultr: 0.44s
This is affected by different QUERY EXECUTION PLAN:
Local server: https://pastebin.com/51ayGWpX
Battle server: https://pastebin.com/JTqME9Bk
Question : why does this occur, with an almost identical hardware configuration (SSD drives, the same amount of memory)? And most importantly: how to fix it ?
What I tried:

1. OPTIMIZE/ANALYZE TABLE
   

PS: The execution time is specified without using query_cache.
upd :
A colleague suggested creating a composite index on (bank_id, branch_deposit), and rewriting the query like this:

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

...And the request sped up, significantly! But, another request fell off, again the optimizer started using the wrong indexes, which is scary.
upd2 : re-uploaded
the database dump from the local server to the combat one - and the optimizer came to its senses. I didn’t understand what it was, apparently, the accumulated statistics allowed the optimizer to make the wrong decisions.

Answer 1

Use EXPLAIN/MySQL Profiler to see the order in which a query is executed. Index values ​​can be different.