What's your use-case? Lots of reading or lots of writing or both? And by lots, what do you consider big?
Running 20k active users can be achieved easily on a single DB server. Note that you can easily increase the connection limit to 500 or a 1000 and if you have enough RAM, even 10k which means your DB is handling 10k concurrent transactions (assuming your OS can handle that many threads, 500-1000 is more typical).
In heavy read situations, just adding caching allows you to stay on a single DB server and then simply clustering the caching servers allows almost infinite read scaling. Having a master slave setup allows you to scale reads out to slaves as well.
If you're doing row-locking updates and a lot of users are updating the same data, your scalability will be bottlenecked by users waiting for each others' updates, so no amount of tricks will make it scale unless you prevent users having to wait for each others' updates.
Unless you're guaranteed a million concurrent users from day 1, MySQL scales well enough that you can worry about scaling later.
If you're flexible with DBs, also have a look at MariaDB, it's a drop-in replacement for MySQL that performs much better (at least it did, haven't been following it for a while).
Also have a look at the book High Performance MySQL, sharding is literally the last option on the table given (no pun intended), not the first thing you should be worried about.