1st setup was a DB slave that was used by customers. That was sufficiently fast. 2nd setup (now) is replication of a DB slave that is just used by me. The current setup is slower on query execution (even though I don't have to share CPU and memory) and the theory is that this is because the DBMS is not "warm" by use but f.x. has to reload the index every time I use it. This leads to weaker performance. The conclusion would be to run scheduled queries that keep the DB "warm".
I would like to know three things which are directly connected:
What is the primary reason for this effect? Is it because after every small write access to the slave which gets replicated onto my server, indexes are loaded into the memory first before a query is executed? My guts tell me there something more complex going on.
How would a query have to look like that optimally uses the DB (scheduled) to keep it warm and ready? I am aware of this post: MySQL warm procedure - but I am not so much interested in a generic query but in understanding the logic behind it.
What determines how frequently such a keep-warm-query (or set of) should be run?
SHOW VARIABLES LIKE "%version%"; innodb_version 5.6.13-rel61.0 protocol_version 10 slave_type_conversions - version 5.6.13-rc61.0 version_comment Percona Server (GPL), Release 61.0 version_compile_machine x86_64 version_compile_os Linux