As we know Magento makes heavy use of caching to boost performance. There are a number of different types of caches, each having their own purpose. Many just low-level code performance boosts we rarely, if ever, have to think or worry about.
In practice, during normal day-to-day operations, there is usually rarely a need to manually "Refresh" any of the caches, even when the message shows up in the Admin (and yes it can be there quite often) and/or any of the rows turn yellow and say "Invalidated". Those labels would be more accurate if they said "FYI, this may or may not need a Refresh".
In general, there are lots of actions an Admin user can take in the Admin that will make the Yellow Notice "One or more of the Cache Types are invalidated: ..." show up (again this is not an "error" message, just a notice). Including, but not limited to editing products, categories, CMS pages, CMS blocks, shopping cart rules, system configuration.
When doing most of these things, Magento does a pretty good job of refreshing the requisite cache automatically on its own and you should see the changes on the front-end nearly right way (it could take a minute or two). However, there are also things that Admins might do that Magento does not know exactly if the thing that was changed even requires a cache refresh for your specific site, so instead of just flushing all the cache every time anything changes, Magento just shows the message/notice and flips a flag saying some of the caches might/may need refreshed.
While refreshing or flushing any of the caches should not cause any issues, doing it frequently kind of nullifies or dulls its useful effect as each time it is flushed/refreshed it needs to start building it up again, which happens as users browse the site and hit pages. For most sites, this is really not a huge deal on any average day, but for some it could have a more noticeable effect on user experience. This is particular true of Full Page Cache.
So, for the general day to day:
When Refreshing cache laid out in the grid, you should not need to check the box for anything other than:
You should never need to "Select All" and Refresh.
The Layout and Block cache rows will be the ones that are seemingly always in an Invalidated state and that is because they get flipped in response to a lot of Admin actions, like saving products and categories, even though almost none of those average changes require a refresh. That said, these are also the safest to Refresh, so if you don't like seeing that Notice at the top of the page, it is okay to Refresh these. But if people are still in the Admin doing things, it will kind of be like whack-a-mole.
Full Page Cache is the most useful and at times troublesome cache, but is also the cache that has to most direct impact on perceived page speed and overall responsiveness of the site. It also is at its best when lots of pages have been allowed to "build" up in FPC over a period of time, even a couple hours. The more pages in FPC, the better. So it is advantageous to clear FPC as little as possible (of course merchandising and changes need to be made, so it is just a matter of finding good balance). Refreshing FPC from the Admin panel, clears all pages, for all stores. Sometimes, this is unavoidable, even if you just need one page to be updated on one store, but a lot of times it is not needed as much as it would seem to be.
It is important to note that FPC only affects CMS/content pages (including the homepage), Product and Category pages. It does not affect login, create account, cart, or checkout. When you are editing Products, Categories and CMS pages, the Save itself should clear that page out of FPC automatically and your changes should be seen nearly right-away on the front-end (could be up to a minute while cron runs to do), so it does not automatically mean FPC should be refreshed, even if is says "Invalidated".
A good way to check/debug a page that does not seem to be showing your latest changes or seems to be showing incorrectly is by appending a unique query string to the URL. i.e
or any other random combination. This is because every URL, including query string, is cached by itself so by appending a weired query string we can "bypass" FPC for 1 request and see what the latest version of the page from the server looks like. If going many times in a row, need to keep making them random because once viewed, the page with the query string will also be cached until cleared.
If the page at the regular URL and the page with the query string are different, then we can reasonably assume it is just a FPC issue and can, if needed, refresh the Page Cache in the Admin. If you do not see your changes or fix with or without the parameter, then it is likely a different issue.
There are some strategies that can be used when dealing with just one page or just a couple pages. And that is first trying to Save or Re-Save the Product, Category, CMS page again. Do not even have to make any changes, just go to it in the Admin and hit Save. Hopefully this will trigger the clear. Whenever someone says my changes are not showing up on a page, that is usually my first move and often resolves the issue without needing to clear all of FPC.
One specific scenario where this is a better approach is on the homepage. If the homepage is made of 1 or more CMS static blocks, for example if a slider is being managed separately in a CMS Static Block or other module, then just updating the slider CMS Block there will not automatically Flush/Refresh FPC so your change will not show up. But before we just clear all of FPC, we can just open up the homepage CMS page and click Save, no changes needed, just click Save. Hopefully, this will refresh just the homepage from FPC and our Slider/CMS Static blocks changes show up.
All that said, if you have tried these and tried refreshing FPC, and you can see with a query string that a page looks "stuck" in cache, then it might require clicking the "Flush Cache Storage" link in the top bar. This should not be used frequently, but it is sort of the sledgehammer approach, but in cases where none of the above seem to be getting the "normal" URL to show the changes you're seeing with they query strings, this can be a last resort. Again, if you are not seeing the changes with a unique query string, then flushing cache will not likely help, as it might be a different issue.