Jasons svar är perfekt. Dessutom skulle jag försöka använda den mer moderna ANSI join-syntaxen för att ta bort belastningen från WHERE-satsen så avlasta förvirringen där:
SELECT o.id
FROM programs o
JOIN titles_programs t ON t.object_id=o.id
JOIN descriptions_programs d ON d.object_id=o.id
WHERE MATCH (d.text) AGAINST ('+china' IN BOOLEAN MODE) AND d.current=1
OR MATCH (t.text) AGAINST ('+china' IN BOOLEAN MODE) AND t.current=1
Detta kommer att stoppa den oavsiktliga korskopplingen och orsaka en kombinatorisk explosion; Jag förväntar mig att den skulle fungera inom rimlig tid om inte databasen var riktigt stor.
Om inte, kan du lägga upp resultatet av ett EXPLAIN SELECT av ovanstående? Förmodligen används inte ett eller båda av fulltextindexen. Jag skulle verkligen kunna föreställa mig att frågeoptimeraren misslyckas med att använda det andra fulltextindexet, genom att göra något som att försöka "fylla i" de rader som inte matchade den första fulltextfrågan istället för att gå direkt till indexet, eller något.
Normalt när du vill indexera fulltext över två kolumner i kombination, skapar du ett index över båda kolumnerna. Detta skulle i alla fall gå mycket snabbare. Men det skulle innebära att du måste lägga titlar och beskrivningar i samma tabell. Detta kanske inte är så svårt:eftersom fulltext bara fungerar på MyISAM-tabeller (och du vanligtvis inte vill ha dina kanoniska data i MyISAM-tabeller) kan du behålla den definitiva kopian av dina data i korrekt normaliserade InnoDB-tabeller, med en extra MyISAM-tabell som endast innehåller avskalat och skaftad sökbete.
Om inget av det är bra... ja, jag antar att jag skulle gå tillbaka till den UNIONing du nämnde, tillsammans med ett filter på programnivå för att ta bort dubbletter av ID:n.