How does MySQL’s BIT(M) type differ from BOOLEAN, TINYINT(1), and binary string types (BINARY, VARBINARY) in terms of storage, representation, and retrieval?

BOOLEAN is just an alias for TINYINT(1).

Stored internally as a 1-byte integer (0 or 1).

Retrieval returns numeric values (0,1) — not binary representation.

Behaves like an integer in comparisons and sorting.

Supports NULL unlike typical boolean types in other DBs.

A numeric type storing 1 byte (range: -128 to 127 SIGNED, 0 to 255 UNSIGNED).

MySQL treats TINYINT(1) as boolean in some contexts but does NOT enforce boolean values.

You may store any numeric value within the allowed range.

Indexes behave like integer indexes — fast and numeric-based.

Store fixed-length (BINARY) or variable-length (VARBINARY) binary strings.

Not bit-level — store bytes, not individual bits.

Used for opaque data such as hashes, tokens, binary identifiers.

Retrieval returns raw bytes, not integers or boolean values.

Comparison is byte-by-byte with binary collation rules.

BIT(M) stores tightly packed bits → most compact for bit flags.

BOOLEAN/TINYINT(1) store numeric values → simplest to query and index.

BINARY/VARBINARY store binary strings → best for binary data, not bitwise logic.

BIT(M) retrieval produces binary output (\x01), while TINYINT/BOOLEAN return integers.

BIT columns show escaped binary sequences unless converted.

TINYINT(1)/BOOLEAN display numeric values.

BINARY/VARBINARY show hex-like binary output depending on client settings.

BIT values require functions like BIN(), HEX(), or CAST() for readability.

Use BIT(M) for bit flags and compact boolean arrays.

Use BOOLEAN/TINYINT(1) for logical true/false values needed in queries.

Use BINARY/VARBINARY for opaque binary data such as hashes and keys.

Avoid BIT(M) when readability is important — BIT requires conversions to interpret.