Det borde vara tämligen uppenbart att resultatet är vad det är. Men för att vidare illustrera det så la jag in 400 000 poster med random data - lite knappt vad WN har.

Resultatet:

Hämta senaste tråden enligt createddate (detta är synonymt ur prestandasynpunkt med ett extra fält såsom Westman klokt föreslog):
11,4ms exekveringstid

Köra din groteska UNION subquery:
1560ms exekveringstid (eller 4000+ ms med kall bufferpool, från ssd)

Fyller du en sajt med sådana queries för att sedan få lite bra reklam i något populärt medie ... då går din sajt ner när den skulle ha nått sin höjdpunkt. Och du kommer inte hinna åtgärda det innan din peak är borta och all din framgång för denna gång förlorad. Bad luck or bad choices?

En mycket bra tråd ur lärosynpunkt.
Generellt kring databasfrågor och normalisering,
man bör även skilja på prestanda och skalbarhet.

Bara för att en funktion X går långsammare än funktion Y på liten datamängd , säg några tusen rader, så är inte Y bättre.
Ett exempel att man kan dela upp en sql i flera olika frågor och t.ex göra sorteringar och sammanslagningar i php istället för sql. Det kan ofta ta lite längre tid när man mäter prestanda, men är mer skalbart och snabbare när datamängd ökar.
Ett sådant angreppsätt kan belasta php/webbserver mer än db server men det är ju betydligt enklare att skala upp webbservern(a).
Dessutom brukar det vara enklare att underhålla och förstå sådan kod, åtminstone för webbutvecklare som inte har DBA kompetens