Как я могу вычислить разницу между двумя хэшами в запросе MySQL?

Question

Я пытаюсь вычислить расстояние Хемминга между входным и сохраненным в базе данных хэшами.Это перцептивные хеши, поэтому для меня важно расстояние между ними по Хэммингу и расскажите, насколько похожи два разных изображения (см. http://en.wikipedia.org/wiki/Perceptual_hashing, http://jenssegers.com/61/perceptual-image-hashes, http://stackoverflow.com/questions/21037578/). Хеши имеют длину 16 шестнадцатеричных символови выглядят так:

b1d0c44a4eb5b5a9
1f69f25228ed4a31
751a0b19f0c2783f

Моя база данных выглядит так:

CREATE TABLE `hashes` (
  `id` int(11) NOT NULL,
  `hash` binary(8) NOT NULL
) ENGINE=InnoDB AUTO_INCREMENT=4 DEFAULT CHARSET=latin1;

INSERT INTO `hashes` (`id`, `hash`) VALUES
    (1, 0xb1d0c44a4eb5b5a9),
    (2, 0x1f69f25228ed4a31),
    (3, 0x751a0b19f0c2783f);

Сейчас,Я знаю, что могу запросить расстояние Хэмминга, например, так:

SELECT BIT_COUNT(0xb1d0c44a4eb5b5a9 ^ 0x751a0b19f0c2783f)

, который выдаст 38, как и ожидалось. Однако я не могу сослаться на имя столбца для этого сравнения. Следующее не работаеткак и ожидалось.

SELECT BIT_COUNT(hash ^ 0x751a0b19f0c2783f) FROM hashes

Кто-нибудь знает, как я могу вычислить расстояние Хэмминга, как в моем первом SELECT запросе выше, используя столбцы в моей базе данных? Я пробовал множество сценариев с использованием hex(), unhex(), conv() и cast() по-разному. Это в MySQL.

Обновление Мой запрос выше работает должным образом при запуске в MySQL v8 (спасибона @LukStorms для точкиэто).Вы можете использовать мою скрипку ниже и изменить версию в левом верхнем углу.Теперь у меня вопрос: как я могу убедиться, что поведение работает во всех версиях MySQL?

Fiddle: https://www.db -fiddle.com / f / mpqsUpZ1sv2kmvRwJrK5xL / 0

Answer 1

Проблема, похоже, связана с вашим выбором типа данных, который является строковым типом.Использование числового типа данных работает в MySQL 5.7, а также в 8.0:

CREATE TABLE `hashes` (
  `id` int(11) NOT NULL,
  `hash` bigint unsigned NOT NULL
) ENGINE=InnoDB AUTO_INCREMENT=4 DEFAULT CHARSET=latin1;

INSERT INTO `hashes` (`id`, `hash`) VALUES
    (1, 0xb1d0c44a4eb5b5a9),
    (2, 0x1f69f25228ed4a31),
    (3, 0x751a0b19f0c2783f);

SELECT id, HEX(hash), BIT_COUNT(hash ^ 0x751a0b19f0c2783f)
FROM hashes;

Вывод:

id  HEX(hash)           BIT_COUNT(hash ^ 0x751a0b19f0c2783f)
1   B1D0C44A4EB5B5A9    38
2   1F69F25228ED4A31    34
3   751A0B19F0C2783F    0

Демонстрация на dbfiddle

Разницав обработке между MySQL 5.7 и 8.0 использования строкового типа можно увидеть с помощью этого запроса:

SELECT id, hash, HEX(hash), HEX(hash ^ 0x751a0b19f0c2783f)
FROM hashes;

MySQL 5.7:

id  hash                                                        HEX(hash)           HEX(hash ^ 0x751a0b19f0c2783f)
1   {"type":"Buffer","data":[177,208,196,74,78,181,181,169]}    B1D0C44A4EB5B5A9    751A0B19F0C2783F
2   {"type":"Buffer","data":[31,105,242,82,40,237,74,49]}       1F69F25228ED4A31    751A0B19F0C2783F
3   {"type":"Buffer","data":[117,26,11,25,240,194,120,63]}      751A0B19F0C2783F    751A0B19F0C2783F

MySQL 8.0

id  hash                                                        HEX(hash)           HEX(hash ^ 0x751a0b19f0c2783f)
1   {"type":"Buffer","data":[177,208,196,74,78,181,181,169]}    B1D0C44A4EB5B5A9    C4CACF53BE77CD96
2   {"type":"Buffer","data":[31,105,242,82,40,237,74,49]}       1F69F25228ED4A31    6A73F94BD82F320E
3   {"type":"Buffer","data":[117,26,11,25,240,194,120,63]}      751A0B19F0C2783F    0000000000000000

MySQL 8.0 правильно выполняет XOR, возвращая переменную, а MySQL 5.7 возвращает значение XOR, указывающее на то, что строка BINARY обрабатывается как 0 в числовом контексте.

Answer 2

Попробуйте это:

SELECT id, HEX(hash), CAST(CONV(HEX(hash),16,10) AS UNSIGNED), BIT_COUNT(CAST(CONV(HEX(hash),16,10) AS UNSIGNED) ^ 0x751a0b19f0c2783f) FROM hashes;

Answer 3

Это не число, поэтому его нельзя использовать для математических расчетов:

`hash` binary(8) NOT NULL

Использовать вместо него bigint:

`hash` bigint unsigned NOT NULL