There is no one size fits all answer to this question, but this seems to be going about things the wrong way. "Premature optimization is the root of all evil." How exactly do you know that query caching is the bottleneck of your application, as opposed to not using a queue for processing requests?
Redis is best used as an application caching system and not a database caching system. When you think about it, you'll understand why.
If you want to cache queries, you need to know when they were last updated. Otherwise, you're not implementing anything other than a guessing system. "I guess I should delete this particular query cache every 24 hours." Well, what if your customer logs in immediately the first time, then changes their information in Userdetails? They have to wait 24 hours to see it updated. They'd assume your system or application is broken.
How else could you go about it? Well, you could do something like have a timestamp on Userdetails for something like "Last Modified". You'll see this in most Laravel and Rails apps that each data table has a last modified property.
Perform the query, check the last modified against the value you have for it in Redis, and then either execute the query or use Redis to serve up a cached version. Did you catch the problem there? You're still performing the query. Without running a new query or checking the query cache, you don't know whether or not you're serving stale data. The performance boost is going to be minimal. You can even introduce new bugs into the system like this:
en.wikipedia.org/wiki/Cache_stampede
You can implement a less naive caching system by caching things that are always going to be the same, e.g. cache a query like "SELECT * FROM comments where id = 1", since the id is unique. Still, same problem occurs if the comment is updated, you're serving stale data.
Instead, for parts of your system that require less latency replace MySQL with Redis, MongoDB, or another NoSQL system. This is a lot less headache to implement effectively. You should also look at questions like whether or not you should set up a replication server to perform most of your reads, using a queue effectively like Resque (which is Redis backed), and so forth.