При хранении большого BLOB, содержащего текстовые данные, рассмотрите возможность предварительного сжатия. Не используйте этот метод, если вся таблица сжата с помощью InnoDB или MyISAM.

Для таблицы с несколькими столбцами, чтобы уменьшить требования к памяти для запросов, не использующих столбец BLOB, рассмотрите возможность разделения столбца BLOB на отдельную таблицу и ссылки на него с помощью запроса JOIN при необходимости.

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

См. Раздел 10.4.2.2, «Оптимизация для типов Character и String», чтобы понять, почему бинарный VARCHAR столбец иногда предпочтительнее эквивалентного столбца BLOB.

Вместо проверки на равенство с очень длинной текстовой строкой, можно сохранить хеш значения столбца в отдельном столбце, проиндексировать этот столбец и проверять хешированное значение в запросах. (Используйте функцию MD5() или CRC32() для вычисления хеша.) Поскольку функции хеширования могут давать одинаковые результаты для разных входных данных, вы по-прежнему включаете в запрос условие AND blob_column = long_string_value, чтобы избежать ложных совпадений. Преимущество в производительности заключается в меньшем, легко сканируемом индексе для хешированных значений.