According to this question and the docs, the storage requirements for a BIT (M) field in MySQL are "approximately (M+7)/8 bytes". This seems awfully vague, and the answers given there don't specify whether this is rounding up or down on the remainder. Which is it?
Specifically, (BIT(7)+7)/8 = 1.75. Is this one or two bytes? -- And is the bit used to determine NULL count towards an extra bit as in the case of SIGNED integers, making BIT (8) (one byte) effectively BIT (9) (two bytes)?
Or is every NULL bit stored in a separate byte at the head of the record, as suggested elsewhere?
Is it true that BIT (M) limits the value of the field, padding it physically with zeros only, but INT (N) doesn't? That seems inconsistent. Isn't the (N) dangerous if, even on the command line, it just tells it to calculate the same but hide the missing digits? -> Is the same true for BIT (M), e.g. can BIT (3) store up to 8 bits = minimum byte length?
Finally, why does the MySQL documentation say on the exact same page that:
M) column takes
Mbits of storage space. Although an individual
BITcolumn is not 4-byte aligned,
NDBreserves 4 bytes (32 bits) per row for the first 1-32 bits needed for
BITcolumns, then another 4 bytes for bits 33-64, and so on.
How does this jibe with the above, or are the storage requirements different because it is for NDB databases?
Note: I'm aware that MySQL no longer treats BIT as an alias for TINYINT (converting each bit into a byte)...
To clarify -- This is a programming question: I am trying to determine how many bits I should set aside in the limit for a bunch of NOT NULL bitmask fields in my SQL. (to allow for additional flags; I only use four or five flags.) What is the recommended per-byte limit? The additional flags will probably never be used, and I'd prefer to limit the number of possible values in the bitmask.