This is a question that we don't always ask, but it is important when we have a large environment and lots of users accessing Zabbix's frontend.

Most of the time, we worry only about performance so that we can meet all the VPS that Zabbix needs (tuning for writing), but we must not forget that we will have users accessing the frontend to read the data that was collected (tuning for reading).

The main point here is that we should understand our environment so that we can think about the tuning we need to perform in MySQL.

The more users we have in Zabbix, the more read operations that the database will run. For example, to access a screen that contains graphics and a map with 50 hosts participating in five groups, Zabbix needs to do the following:

Now, let's imagine that we have dozens of screens, maps, and users in Zabbix. Also consider that we have the screens of the NOC (short for network operation center), with a screen refresh every 2 or 3 minutes. Take into consideration that the housekeeping will select the data to be deleted from the database. We also have the internal functions working (select and insert) to aggregate data into trends tables.

Another important fact is that the Zabbix GUI does not work with any cache or buffer, and it needs to access the database directly.

In a typical Zabbix implementation, we will have more reading (select) than writing (insert, update, and delete) operations.

Another detail, often forgotten or overlooked, is the fact that Zabbix performs many small queries. Therefore, the MySQL query cache can be disabled because the cost of managing such cache is sometimes larger than running these queries without cache. We must also consider that many queries executed by Zabbix consider the date and time (minutes and seconds), which does not favor the use of a cache for queries. So, it is possible (but not fully recommended) to disable the query cache by adjusting the following parameters: