Hi LostInTheWoods;
It really comes down to your workload. Would storing all data plus indexes in memory at all times be great? Yes. Is it necessary? Probably not (but sometimes it is). If your application is currently running fine, then chances are you are set. That may change as your data size and/or usage grows/changes however, so on-going trending and tuning is key.
The real goal is to at least get your most commonly accessed data and indexes into memory. That could mean only 10% of your data, or 90% of your data (or somewhere in between). A good way to track how you are doing is by monitoring the “evicted without access” value:
mysql> pager grep “evicted without access”
PAGER set to ‘grep “evicted without access”’
mysql> show engine innodb status \G
Pages read ahead 0.00/s, evicted without access 0.00/s, Random read ahead 0.00/s
1 row in set (0.00 sec)
Ideally the “evicted without access” value should always be zero. If this value is not zero, then it means data is getting read into the buffer pool and then pushed out again before it is accessed (a.k.a. buffer pool churn). If you track this value over time, and you start to see the value go up (even only temporarily), then it may be time to increase your buffer pool size. Note that no matter how large your buffer pool is, bad queries can (and will) destroy it. So always keep an eye towards query optimization and tuning when looking into this area, because even one bad query that gets run often can destroy performance for every other query (i.e. imagine a query that scans all your largest tables into memory each time it is ran, pushing out everything else).
-Scott