MySQL — issuing low priority updates

I think your problem is not so much with tmp_table_size as it is with getting your "ugly" query (resultset) cached via query_cache. If your query is type SELECT, use SQL_NO_CACHE. When cached, it serves fast, but it can overload the cache and mysql had known issues with reorganizing cache internally. Also, check your query with EXPLAIN and use force indexes on joins if necessary.

This would be more appropriate as comment but my current rep is too low.

Databases (well, 99% of them) cache everything they can. Cache is good. It makes stuff go faster. You want your database server to eat up all the memory it can, and never release it unless it have to.

It won't cache stuff unless you ask it to (like in a query). Maybe there are tools to make MySQL pre-cache data, but I have no idea. Newer database products is beginning to get lots of in-memory features, where you can select certain data to always be present in memory.

CPU usage does not correlate to RAM usage. Your queries could be extremely lightweight, like only fine-grained SELECTS which hits a index every single time. In other words, the database will serve you cached data which resides in RAM, so there would be very little CPU work to be done (like scheduling I/O to retrieve and process data from disk).

To me, this looks like a very healthy and fast performing database. There really is no problems at all. If you have free memory then it just means that the database doesn't need to cache more data, as it's never being requested.

EDIT: You've limited the InnoDB pool to 24GB, which is excellent since your database is 20GB. If the database increases then take care to increase the buffer pool size. You also mention that you are worried by the decrease of available memory - this should only be a concern if other processes than the database is consuming it. The database server will not grow beyond what you've limited it to.