SQL_NO_CACHE
Lägg bara till SQL_NO_CACHE efter SELECT-delen av SELECT-satsen och före fältlistan. Den första frågan nedan kommer att använda frågecachen om den är aktiverad och frågan är cachad:
SELECT * FROM table WHERE search= 'keyword'; //lets take 1ms
Den andra frågan nedan kommer inte att använda frågecachen:
SELECT SQL_NO_CACHE * FROM table WHERE search= 'keyword'; //lets take ~0.2ms at 2nd time
Detta är särskilt användbart vid benchmarking av en fråga; om frågecachen är aktiverad även om den första frågan kan ta lite tid är den andra och efterföljande frågor nästan omedelbara. Med användning av SQL_NO_CACHE kan du vara säker på att frågecachen inte används och kan säkert jämföra resultattider. SQL_NO_CACHE-tipset stänger av MySQL:s inbyggda frågecachemekanism för en viss fråga. Du kan hjälpa MySQL att göra frågecachen effektivare genom att använda denna ledtråd på frågor som är mycket dynamiska (som en nyckelordssökning eller en rapport som bara körs varje natt). Se till att frågecache är aktiverat annars finns det inget behov av detta kommando.
vilka SQL_CACHE och SQL_NO_CACHE?
Alternativen SQL_CACHE och SQL_NO_CACHE påverkar cachelagring av frågeresultat i frågecachen. SQL_CACHE säger åt MySQL att lagra resultatet i frågecachen om det är cachebart och värdet på systemvariabeln query_cache_type är 2 eller DEMAND. Med SQL_NO_CACHE använder inte servern frågecachen. Den kontrollerar varken frågecachen för att se om resultatet redan är cachelagrat, och den cachelagrar inte frågeresultatet. (På grund av en begränsning i parsern måste ett mellanslagstecken föregå och följa nyckelordet SQL_NO_CACHE; ett icke-mellanslag som en nyrad får servern att kontrollera frågecachen för att se om resultatet redan är cachelagrat.)
NO_CACHE enligt min åsikt kan användas om 'CACHE' är aktiverat och data i db uppdateras dynamiskt, dvs. db-datacache kan inte litas på, t.ex. möjlighet till ändring av data
Uppdateringar av användbara scenarier
1) tvinga att inte använda cache för att testa sökhastigheten