Lumixзначит ли это что любой индекс ниже 24 байт просто нахфиг теряет свою эффективность и смысл???? тупо потому что у нас все различия начинаются не раньше 25ого чара...Насколько я в курсе - да, именно так.

Вообще, строковые поля в индексах могут быть скомпрессированы, но, насколько я понимаю, обрезка префикса происходит до компрессии.

Lumixсоздавать дополнительное поле, которое будет содержать нормализированные данные, специально заточенные для эффективной работы индексовВ приличных СУБД существуют FBI и реверсные индексы. В сумме или по отдельности они весьма помогают в проблеме длинных одинаковых префиксов.
Дополнительным полем в MySQL можно имитировать такие функции.
Lumixдля поиск по статьям с помощью лайков индексы вообще нафиг не нужны, потому что статьи обычно начинаются от 1-1,5 тыс знаков, а бывают и по 10-20 тыс. знаков...Конечно, не нужны. Но не по причине ограниченности длины префиксов, а потому что обычно поиск по тексту происходит по маске '%подстрока%', а для нее обычные индексы бесполезны независимо от длины префикса.
Lumixполучается, что для того, чтобы индекс имел хоть какое-то значение, придется на клиенте каждую статью пилить на киворды, затем строить таблицу (keyId, txtKey (index 64), pageId) и только после этого индекс будет иметь хоть какое-то значение...Обычно это решается полнотекстовыми индексами или сфинксом.
Lumixсегодня с этой мыслью пересплю и если никаких идей не появится, то завтра дам распоряжение выкинуть нафиг все индексы из таблиц по текстовым полям, все равно по ним толку никакого нету....Вы это, осторожнее :)
Индексы еще бывают, например, покрывающие. В случае с текстами, конечно, оно вряд ли, но мало ли...