I don't know what the best way necessarily is to store it -- but there's at least a better option than using a varchar(39) (or varchar(40) if you needed it signed) ; instead use a decimal(39,0). From the mysql docs:
Fixed-Point (Exact-Value) Types
The DECIMAL and NUMERIC types store
exact numeric data values. These types
are used when it is important to
preserve exact precision, for example
with monetary data. In MySQL, NUMERIC
is implemented as DECIMAL, so the
following remarks about DECIMAL apply
equally to NUMERIC.
MySQL 5.1 stores DECIMAL values in
binary format. Before MySQL 5.0.3,
they were stored as strings. See
Section 11.18, “Precision Math”.
In a DECIMAL column declaration, the
precision and scale can be (and
usually is) specified; for example:
salary DECIMAL(5,2)
In this example, 5 is the precision
and 2 is the scale. The precision
represents the number of significant
digits that are stored for values, and
the scale represents the number of
digits that can be stored following
the decimal point.
Standard SQL requires that
DECIMAL(5,2) be able to store any
value with five digits and two
decimals, so values that can be stored
in the salary column range from
-999.99 to 999.99.
In standard SQL, the syntax DECIMAL(M)
is equivalent to DECIMAL(M,0).
Similarly, the syntax DECIMAL is
equivalent to DECIMAL(M,0), where the
implementation is permitted to decide
the value of M. MySQL supports both of
these variant forms of DECIMAL syntax.
The default value of M is 10.
If the scale is 0, DECIMAL values
contain no decimal point or fractional
part.
The maximum number of digits for
DECIMAL is 65, but the actual range
for a given DECIMAL column can be
constrained by the precision or scale
for a given column. When such a column
is assigned a value with more digits
following the decimal point than are
permitted by the specified scale, the
value is converted to that scale. (The
precise behavior is operating
system-specific, but generally the
effect is truncation to the
permissible number of digits.)
Best Answer
If you are starting with hex, use
UNHEX()when storing andHEX()when fetching. UseBINARY(32)for the datatype. This occupies a constant 32 bytes.If you are starting with binary, then be careful when escaping to store/load. Probably best to do a double convert each way.
Be sure to have lots of RAM. Once the index becomes bigger than the buffer_pool, the system will slow down because of the randomness of sha256 (or any other hash or uuid).
If you go with Base64, then use
CHAR(43) COLLATE ascii_bin, which will be a constant 43 bytes, and will be case-sensitive.256 is gross overkill. If you have about 2^85 entries, there is only one chance in 2^85 of having any hash collisions. For a mere MD5, those numbers are 9 trillion.