There have been many tickets recently for performance improvements in both the C code and for the frontend. I am finding more often that for large deployments the mysql query optimizer ends up making bad decisions. For example, in the Host availability widget a query like the following is run:

SELECT COUNT(*) AS rowscount,i.interfaceid FROM items i WHERE i.type<>9 AND i.flags IN (0,4) AND i.interfaceid IN (100,101,102...) AND i.type IN (0,12,16,20) AND i.status=0 GROUP BY i.interfaceid;

Last week, this query finished in 0.02 seconds. Today, it takes 40 seconds. The mysql explain shows that query preferencing the index for the status column. But we know the most optimal path in the items table is to use the interfaceid column for the query above as the index for narrowing down to the fewest rows, then have it scan for the type, flags, status, etc...

I think the most frequently used parts of the Zabbix UI, as it becomes more advanced with dashboarding features, need the queries to be optimized to force using the best indexes. We should not be at the mercy of the database to make bad decisions when the developers/engineers who wrote the Zabbix software know the best query path for each query