Poor usage of timestamp index
The EXPLAIN is about as good as it will get.  "Range" is good for the WHERE.  The ORDER BY, though not mentioned, should be handled as well.  And it should stop at 50 (again, no clue in EXPLAIN).

10.00 percent of the table is an estimate based on virtually no information; ignore it.

"5.7 clustered" is a contradiction.  Do you mean "NDB Cluster"?  Or a Galera-based cluster?

Indexing a flag (status) is usually useless.

More on indexing .

Back to the question of 15 seconds.  I agree that the time is unreasonably large.  Here are some partial explanations...


Something else was busy in the system.
The bulky TEXT column was store off-record, necessitating an extra disk hit.  Granted, 50 disk hits should take less than a second.
The Posts may be scattered around; that is, not stored consecutively.  Again, maybe 50 disk hits and another fraction of a second.


I am surprised that it took more than one second, even after allowing for uncached blocks.

Run the query a second time (to counteract the caching); how long does it take?

Another thing to check -- how big is innodb_buffer_pool_size and how big is RAM?  A tiny VM could be part of the problem.  The buffer_pool being so big that swapping occurs could actually explain 15 seconds.