Transparent Caching

• Query cache is completely transparent to the application. This will cause problems in some circumstances. When query cache is enabled, you can always get query results even when the related tables are locked and are being updated. Locking tables usually means the tables are inaccessible but query results from query cache will still come to users.
  
  

Caching Limitation

• The query cache doesn't work for sub-selects, inline views, or UNION. The queries must be exactly the same in order to utilize the result from query cache, which means if you put dynamic comments in the query with more spaces or different case, you get a different result from query cache. Another limitation is only SELECT queries are cached. Avoid comments or spaces in the start of the query as query cache only checks the first letter of the query and only if it is "S" does it continue to proceed caching query results.
  
  

Table Level Granularity in Invalidation

• If tables are altered or updated, all queries derived from the tables are invalidated instantly. Most of the queries are not changed but MySQL can't identify changed ones, thus it deletes all of them. This is the major reason which constrains query cache efficiency. Especially with high write application such as forums, query cache efficiency is very low because of this limitation.
  
  

Fragmentation Over Time

• With time, query cache becomes fragmented and less efficient. The "FLUSH QUERY CACHE" command can be utilized for query cache defragmentation but it may block query cache for the sake of a large query cache, which is improper for online applications.