8.4.2.3. Оптимизация для Типов BLOB

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

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

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

См. Раздел 8.4.2.2, "Оптимизируя для Типов Символа и Строки" по причинам почему двоичный файл VARCHAR столбец иногда предпочтителен для эквивалентного столбца BLOB.

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