MySQL中BIT（64）列的奇怪行为

Question

Can anyone help me understand the following problem with a BIT(64) column in MySQL (5.7.19).

This simple example works fine and returns the record from the temporary table:

CREATE TEMPORARY TABLE test (v bit(64));
INSERT INTO test values (b'111');
SELECT * FROM test WHERE v = b'111';
-- Returns the record as expected

When using all the 64 bits of the column it no longer works:

CREATE TEMPORARY TABLE test (v bit(64));
INSERT INTO test values (b'1111111111111111111111111111111111111111111111111111111111111111');
SELECT * FROM test WHERE v = b'1111111111111111111111111111111111111111111111111111111111111111';
-- Does NOT return the record

This only happens when using a value with 64 bits. But I would expect that to be possible.

Can anyone explain this to me?

Please do not respond by advising me not to use BIT columns. I am working on a database tool that should be able to handle all the data types of MySQL.

Answer 1

Bits are returned as binary, so to display them, either add 0, or use a function such as HEX, OCT or BIN to convert them https://mariadb.com/kb/en/library/bit/ or Bit values in result sets are returned as binary values, which may not display well. To convert a bit value to printable form, use it in numeric context or use a conversion function such as BIN() or HEX(). High-order 0 digits are not displayed in the converted value. https://dev.mysql.com/doc/refman/8.0/en/bit-value-literals.html

Answer 2

The problem seems to be, that the value b'11..11' in the WHERE clause is considered to be a SIGNED BIGINT which is -1 and is compared to the value in your table which is considered to be an UNSIGNED BIGINT which is 18446744073709551615 . This is always an issue when the first of 64 bits is 1 . IMHO this is a bug or a design flaw, because I expect an expression in the WHERE clause to match a row if the same expression has been used in the INSERT satement (at least in this case).

One workaround would be to cast the value to UNSIGNED :

SELECT * 
FROM test
WHERE v = CAST(b'1111111111111111111111111111111111111111111111111111111111111111' as UNSIGNED);

Or (if your application language supports it) convert it to something like long uint or decimal :

SELECT * FROM test WHERE v = 18446744073709551615;