Les types BINARY et VARBINARY sont similaires à CHAR et VARCHAR, hormis le fait qu'ils contiennent des chaînes binaires, plutôt que des chaînes de texte. C'est à dire, qu'ils contiennent des chaînes d'octets, plutôt que des chaînes de caractères. Cela signifie qu'ils n'ont pas de jeu de caractères associé, et les tris et comparaisons sont basées sur la valeur numérique de l'octet.

La taille maximale pour les types BINARY et VARBINARY, est la même que celles de CHAR and VARCHAR, hormis le fait que la taille de BINARY et VARBINARY est une taille en octets, et non pas en caractères.

La gestion des espaces finaux est la même pour BINARY et VARBINARY que pour CHAR et VARCHAR. Lorsqu'une valeur BINARY est stockée, elle est complétée à droite avec des espaces. Lorsque les valeurs BINARY sont lues, les espaces finaux sont supprimés. Pour VARBINARY, les espaces finaux sont supprimés lorsque la valeur est stockée. Depuis MySQL 5.0.3, les espaces finaux sont conservés. Gardez ces caractéristiques en tête si vous envisagez d'utiliser ces types de données, et que les valeurs risques de se terminer par des espaces.

Avant MySQL 4.1.2, BINARY(M) et VARBINARY(M) étaient traités comme des CHAR(M) BINARY et VARCHAR(M) BINARY. Depuis MySQL 4.1.2, BINARY et VARBINARY sont disponbiles en tant que types de données distincts, et pour CHAR(M) BINARY et VARCHAR(M) BINARY, l'attribut BINARY n'active pas le traitement binaire des colonnes. A la place, la collation binaire de la colonne sera utilisée, mais la colonne elle-même contiendra des caractères, plutôt que des octets. Par exemple, en version 4.1 et plus récent, CHAR(5) BINARY est traité comme CHAR(5) CHARACTER SET latin1 COLLATE latin1_bin, en supposant que le jeu de caractères par défaut est latin1.