Why is database sharding based on timestamp or monotonically increasing number not recommended? I am referring to the anti pattern mentioned at: https://cloud.google.com/spanner/docs/whitepapers/optimizing-schema-design#anti-pattern_timestamp_ordering
Notice that your link called it an "anti-pattern". I have similar thoughts...
That seems like an odd way to shard. It implies that writes will be pounding on one server for a while (a day, or whatever the shard range is). This makes the "recent" data hard to SELECT from because of all the writes going on. Meanwhile, the "old" data is sitting idle??
Usually, Sharding is based on "user_id" or "company_id". This spreads the load--both read and write--across the shards. After all, sharding is to spread the load.
But, sharding should not be done until you have so much activity that the traffic cannot be handled in a single machine. Sharding is complex because of having to redirect traffic to the appropriate machine, and because of the really messy code needed if a single action needs to look in multiple shards.
If you do have a lot of traffic, I will be happy to advise further. But I would start by seeing if the traffic can be made efficient enough to live on a single server.
Another thing to note: There is essentially no parallelism in MySQL.