Question

A thought experiment:

You have a CMS that allows users to upload an image, and each page is stored as a row in the database. When a user
uploads an image, it is converted into a base64 encoded string. The
upload script then alters an ENUM column in a table and adds the base64 encoded
string as an allowed enumerable value.

In the front-end of the CMS, a SELECT statement be run on the page and the value of the ENUM column would be used to render out the image using a data
url.

Would writing a select statement in which the WHERE clause was matching against an enum value have any performance advantage over a query in which the WHERE clause was matching against a varchar column?

…And for the record, I know this is an absolutely terrible design for a CMS. I’m more interested in learning how MySQL would suffer (or thrive) with this setup.

Answer 1

enum storage is actually just the index of the value you’re storing the field. so you wouldn’t be storing the base64 data, just its associated index in whatever parallel table mysql stores the enum values in.

however, consider that the actual SQL query strings will have to contain the full base64 data, so you’re needlessly increasing the size of the query string. Consider that a single pixel jpeg is still (around) 119bytes, and in base64 form takes up 160 characters. That’s probably 150+ characters of wasted space. For even moderately sized images, your query strings would be even larger and could quite easily exceed mysql’s max_allowed_packet setting.