Moderate use of Query Cache
First of all , we need to judge which tables are suitable for Query and which tables are not suitable according to the Query Cache invalidation mechanism . Since the failure of QueryCache is mainly because the data of the Table on which Query depends has changed , the Result Set of Query may have changed and all related Query Caches have been invalidated, so we should avoid Querying in Tables with frequent query changes. It should be used on the Query of Tables whose query frequency changes less frequently . There are two dedicated SQL Hints (hints) for Query Cache in MySQL : SQL_NO_CACHE and SQL_CACHE , which represent forcibly not using Query Cache and forcing the use of Query Cache , respectively.. We can use these two SQL Hints to let MySQL know which SQL we want to use Query Cache and which SQL we don't want to use. This can not only waste Query Cache memory for queries with frequently changed Tables , but also reduce the amount of Query Cache detection.
Secondly , for the data that changes very little and is mostly static, we can add the SQL Hint of SQL_CACHE to force MySQL to use Query Cache , thereby improving the query performance of the table.
Finally , some SQL Result Sets are very large. If Query Cache is used, it is easy to cause insufficient Cache memory, or flush out some old Caches . For this type of Query , we have two ways to solve it. One is to use the SQL_NO_CACHE parameter to force him not to use the Query Cache and to search directly from the actual data every time. The other way is to set the " query_cache_limit " parameter value. To control the maximum Result Set cached in the Query Cache , the system defaults to 1M ( 1048576 ). When the Result Set of a Query is greater than the value set by " query_cache_limit ", QueryCache will not cache thisQuery . _