When storing a large blob containing textual data,
consider compressing it first. Do not use this technique
when the entire table is compressed by
For a table with several columns, to reduce memory requirements for queries that do not use the BLOB column, consider splitting the BLOB column into a separate table and referencing it with a join query when needed.
Since the performance requirements to retrieve and display a BLOB value might be very different from other data types, you could put the BLOB-specific table on a different storage device or even a separate database instance. For example, to retrieve a BLOB might require a large sequential disk read that is better suited to a traditional hard drive than to an SSD device.
See Section 22.214.171.124, “Optimizing for Character and String Types” for reasons why a
VARCHAR column is sometimes
preferable to an equivalent BLOB column.
Rather than testing for equality against a very long text
string, you can store a hash of the column value in a
separate column, index that column, and test the hashed
value in queries. (Use the
CRC32() function to produce the hash
value.) Since hash functions can produce duplicate results
for different inputs, you still include a clause
the query to guard against false matches; the performance
benefit comes from the smaller, easily scanned index for
the hashed values.