You typically have to weight the cost of doing so vs. the benefits ... but benefit in risk management is difficult to quantify.
Basically, it comes down to what the cost of an exploit would be, and what the likihood of it happening are.
So, having to restore from backup because someone managed to drop a table which creates a denial of service, and being down for a day has a cost to the company in terms of what profit they'd have made in that given time, but there's also an issue of reputation loss (ie, customers/users who stop doing business with you, or potential users who are less likely to do busines in the future) ... but we have to balance this by the likehood of someone successfully attacking the site and causing this.
If you're not storing credit cards, and you're not a big target (the type of site people would brag about taking out), you're less likely to be hacked ... although, if you're running commonly distributed software, you still risk attacks by script kiddies who are just looking for people running software with a known exploit.
...
What our security folks don't seem to understand is that it's a balancing act -- some changes for security will create a burden on your users. And sometimes, the security itself will cause outages (eg, one of our external partners moves IP ranges ... but the new holes in the firewall weren't made, and due to a "network hold" we can't get any changes made for over a week) or just performance degredation.
Sometimes it's just that it takes longer to code, or more headaches to maintain, etc.
But it's something you have to answer for yourself -- is the cost worth the benefit of having made the change? (and sometimes, if the cost is just in man-power, was there an opportunity cost; ie, could you have been doing something else that would derive even more benefit with your time?)
As DTest pointed out, provide more information about your problem.
Regarding caching, you could possibly increase your innodb buffer pool size to allow more data and indexes to be cached in memory. If you have frequent updates, you may not benefit from the query cache and might be better off using that RAM for innodb buffer pool.
If you want to put all your data and indexes in RAM, then MySQL Cluster might be your answer.
EDIT
It looks like your SELECT statements are using proper indexes. Could you provide an explain plan for your update statement? You will have to rewrite it as a SELECT statement to do that. Do a SELECT * FROM same table and with same where clause as your UPDATE statement.
Best Answer
So let's think forward a little. The application goes live, the tables are created and everything's lovely. Then, you have a new requirement and the tables must change. How do you code that? There's the CREATEs for environments where the code's never run, plus a bunch of ALTERs for existing environments. Now another requirement comes along. This time you have to migrate data for some reason or other. Now there are the CREATEs (for new environments), the ALTERs (for existing environments) and a whole bunch of DDL and migration logic. But wait - there's more. For really good business reasons you want the column holding the migrated data to have the same name as an existing column. How do you now tell if the database has been migrated or not? No longer do you have a metadata-only lookup. No, now you need a flag or version table to show what DDL has to run at each and every execution.
Yeah! You're a great success. Zillions of people want to use your service. Venture capitalists wheeling barrows of money to your door. Third-party organisations are begging to partner with you. The dev team's doubled (nay, trebled!) in size to handle the business opportunities and customisations. Oops. These all have to be coded in the API start-up code. Each. And. Every. One. You no longer have an API. You have the mother of all migration scripts with a fragment of business code tacked on. :sad-face: