A resposta de Jason está correta. Além disso, eu tentaria usar a sintaxe de junção ANSI mais moderna para tirar a carga da cláusula WHERE para aliviar a confusão:
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
Isso interromperá a junção cruzada inadvertida causando uma explosão combinatória; Eu esperaria que ele operasse em um tempo razoável, a menos que o banco de dados fosse realmente enorme.
Se não, você pode postar os resultados de um EXPLAIN SELECT do acima? Presumivelmente, um ou ambos os índices de texto completo não estão sendo usados. Eu certamente poderia imaginar o otimizador de consulta falhando em usar o segundo índice de texto completo, fazendo algo como tentar 'preencher' as linhas que não correspondiam à primeira consulta de texto completo em vez de ir direto para o índice ou algo assim.
Normalmente, quando você deseja indexar o texto completo em duas colunas em combinação, você cria um índice em ambas as colunas. De qualquer forma, isso seria muito mais rápido. No entanto, isso significaria que você teria que colocar títulos e descrições na mesma tabela. Isso pode não ser tão difícil:como o texto completo só funciona em tabelas MyISAM (e você normalmente não deseja seus dados canônicos em tabelas MyISAM), você pode manter a cópia definitiva de seus dados em tabelas InnoDB devidamente normalizadas, com uma tabela MyISAM adicional contendo apenas isca de busca despojada e com haste.
Se nada disso for bom... bem, acho que voltaria ao UNIONing que você mencionou, juntamente com um filtro de nível de aplicativo para remover IDs duplicados.
