In MySQL the BINARY keyword serves three related purposes: 1) Data type definition - BINARY(n) creates a fixed-length byte string column that always stores exactly n bytes, padding with 0x00 if the inserted value is shorter. 2) Type cast - the unary operator BINARY expr converts a value to the BINARY string type, making subsequent comparisons byte-wise and case-sensitive according to the binary collation of the connection. 3) Comparison modifier - using BINARY before literals or in predicates (e.g. LIKE BINARY) overrides the column's collation so the comparison is evaluated with a binary (case-sensitive) collation. Unlike VARBINARY, BINARY is fixed length; unlike CHAR, its content is not interpreted as text, so character set and collation are always 'binary'. For large unbounded binary data use BLOB. In SQL Server and the SQL standard BINARY exists only as a data type, not as a cast operator. PostgreSQL and SQLite represent raw bytes with other types (bytea, BLOB) and ignore the BINARY keyword.
n
(integer) - Mandatory for the data type. Specifies the fixed length (0-255 in MySQL) of the binary string. Must be a positive, non-zero integer.VARBINARY, BLOB, CAST, COLLATE, CHAR, LIKE
MySQL 4.1
BINARY(n) always stores exactly n bytes, padding with 0x00. VARBINARY(n) stores only the bytes you insert plus a small length prefix. Use BINARY for fixed-size data like hashes, VARBINARY for variable-length data.
Yes. When you cast a value with BINARY or write LIKE BINARY, MySQL uses a binary collation, so 'Galaxy' and 'galaxy' are different.
Up to 255 bytes in MySQL. For larger data consider TINYBLOB, BLOB, MEDIUMBLOB, or LONGBLOB.
No. PostgreSQL uses the bytea type and SQLite treats all blobs as BLOB; the BINARY keyword is ignored or unsupported.