4 ms·
In a former job I had an application that made excellent use of the Query Cache. A number of computers (in clusters across a large campus) that all needed to ch
by larkost 9y ago
In a former job I had an application that made excellent use of the Query Cache. A number of computers (in clusters across a large campus) that all needed to check on the same computed value that was derived from a query that spanned 5 tables. The computers each checked in up to every 5 minutes, and really only needed to know when the computer value changed, but without setting up some sort of push system (which would have been engineering expensive), we just fell back on the Query Cache. Worked beautifully, especially since we would only see an extra recompute a few times a day.
Yes, you could architect a separate system to do this (e.g. a separate table, possibly with a stored procedure firing for changes on any of the tables), but that would necessarily involve more complexity.
- pizza234 9y agoThis is a quite lucky edge case; in order for this to work, you need to have the underlying tables (5 in this case) change infrequently. This is actually, directly and indirectly, the core issue of query caches. The one mentioned is the direct problem; the indirect one is that for each record change in any table [present in the query cache], the entire query cache must scanned and invalidated, which causes locking.