There is a saying, premature optimization is the root of all evil. My recommendation is to keep an eye on emerging problems but not worry about the long-term implications. Focus on keeping your database as good as it can be and let the future attend to itself.
As far as storing images in the database, there are significant pros and cons here. I haven't done much of this with MySQL, but on PostgreSQL there are both some very nice aspects (atomic backups ftw!) of this and some really annoying pitfalls (argh, memory usage turning base 64-representations of bytea's into binary again!) so be careful, pay attention to tradeoffs, and be willing to reconsider both ways.
The next point is that in a few years, your application will probably be somewhat different than it is today. Usage patterns will likely be different too. Trying to solve problems today that you think you may see someday is a good way to add complexity that will make it harder to solve the actual problems you encounter tomorrow.
Once you start beginning to struggle it is a good idea to have a good idea of what your choices are. These include:
Vertical scaling, focusing on more RAM, faster hard drives, more powerful servers, etc.
Horizontal scaling and sharding, replication, connection pooling, and the like.
Database abstraction through some sort of intermediary which can cache frequently used data (such as a NoSQL db, or memcached).
These are your main options. Every one though adds significant complexity and it is impossible to know now which ones will have the best tradeoff for your use case.
If you are worried about scaling in the short to mid term, the single most important thing you can do is learn about options and tools, and play around with those you can in a safe and sane environment.
