A razão é baseada no desempenho, sim. Diminuir o limite padrão aumentará o espaço necessário para armazenar os índices, e o aumento do tamanho do índice levará mais tempo para pesquisar. O impacto dependerá do uso (o tipo de consultas realizadas) e do tamanho do conjunto de dados atual. O mínimo padrão é 4, você pode diminuir assim:
[mysqld]
ft_min_word_len=3
Quando você reconstruir seus índices (como deve), certifique-se de não reparar, mas descarte e reconstrua os índices. Isso é consideravelmente mais rápido do que repará-los.
mysql> ALTER TABLE tbl_name DROP INDEX ft_index;
Query OK, 9999 rows affected (0.00 sec)
Records: 9999 Duplicates: 0 Warnings: 0
mysql> ALTER TABLE tbl_name CREATE INDEX ft_index( searchable_text );
Query OK, 9999 rows affected (0.00 sec)
Records: 9999 Duplicates: 0 Warnings: 0
Provavelmente, sua melhor solução é monitorar o tamanho dos índices em um servidor dev antes e depois da alteração do comprimento do índice.
A melhor opção (que adiei) é ignorar a correspondência de texto completo do MySQL (que tem sérias limitações, incluindo somente o MyISAM, incapacidade de combinar curingas prefixados, uma lista proibitiva de palavras de parada padrão) e implementar uma solução de terceiros. As melhores opções disponíveis são:
- Lucene - um projeto apache baseado em Java, baixo footprint, rápido, muito bem adotado
- Esfinge - baseado em SQL (conectores disponíveis para MySQL, PostgreSQL ou XML), não exatamente 1.0 (atualmente 0.9.10), bem adotado-ish
Eu pessoalmente optaria pelo Lucene, embora ele exija uma instância de java local. Se isso não for possível, o Sphinx é muito fácil de configurar para o PHP ( passo a passo aqui ) e muitas outras línguas.
Aqui estão alguns bons valores de referência e < href="http://pagetracer.com/2008/02/15/sphinx-and-lucene-search-engines-first-impressions/"> as primeiras impressões de mais alguém sobre o assunto.