The next temptation is to have the index on that date or (date, rank) and use that for displaying the list of messages. This is bad.
For the list of threads (messages without a parent) you want to know which to show… but there are a lot of calculations that would make this inefficient. Is it a root message? Is it deleted? Is it marked by spam or other content filters? Is it approved?
You can start to see how this gets messy. How do you show messages that are approved for one group of readers and not for others? And what is their order? So separate the concerns… in the db. SQL is your friend if the db has the right data packaged and indexed the right way.
It’s a different problem and has a different solution. Now mind you, I cut my teeth on this in the late 1990s and early 2000s when we grew quickly into the Alexa 1000 and farther up. China blocked us as one of the original dozen sites on the great firewall (via dns resolved IPs, not the domain itself… hahaha, oh the chaos they empowered!). Databases were more expensive than engineering time back then, so efficiency mattered. People do dumb things now and use giant clusters when a single machine would do, but I digress…