MySQL SELECT против столбца varbinary

Это результат предыдущего выпуска, который я опубликовал here.MySQL SELECT против столбца varbinary

Я создал тестовую таблицу:

CREATE TABLE `my_test_table` (
    `record_id` INT(11) UNSIGNED NOT NULL AUTO_INCREMENT, 
    `col1` BINARY(20) NULL DEFAULT NULL, 
    `col2` CHAR(40) NULL DEFAULT NULL, 
    PRIMARY KEY (`record_id`) 
)

Тогда выбежала заявление:

INSERT INTO my_test_table (col1, col2) VALUES(sha1('test'), sha1('test'));

Данные выглядит ...

1 0x6139346138666535636362313962613631633463 a94a8fe5ccb19ba61c4c0873d391e987982fbbd3

Я не знаю, как я могу выбрать против VARBINARY. Я могу выбрать против CHAR как:

SELECT * FROM my_test_table WHERE col2 = sha1('test');

Я попытался

SELECT * FROM my_test_table WHERE col1 = hex(sha1('test'));

и другие варианты, но не могу найти решение (если есть один). Мне нужно проверить, есть ли значение в базе данных, прежде чем я разрешу новую вставку. Я смотрел VARBINARY и BINARY на основе предыдущих предложений. Благодарю.

источник

2012-05-15 Don

Почему столбец типа двоичный? –

Я не читал ваш предыдущий вопрос, но на основе исходного кода в этом вопросе вы сохраняете только первые 20 символов хэша sha1 в col1, поэтому, если вы хотите его выбрать, вам нужно просто найти первые 20 символов хэша sha1.

Например:

SELECT * 
FROM my_test_table 
WHERE col1 = left(sha1('test'),20);

источник

2012-05-15 18:35:48

Это сработало. Я был в замешательстве относительно того, почему это видно в моем редакторе MySQL как «0x6139346138666535636362313962613631633463». Есть ли какая-то причина, по которой я должен опасаться, что первые 20 будут менее случайными, чем строка 40 CHAR? – Don

Вероятно, вероятность столкновения существенно выше, используя 20 символов по сравнению с 40. Вы должны провести некоторое исследование хеш-коллизий и решить, какая хэш-функция подходит именно вам. –

Спасибо. Я был просто смущен, так как другие рекомендации заключались в том, чтобы сохранить хеш-значение как двоичное, но если это ограничивает его уникальность при сравнении, я думаю, что CHAR может быть лучше. Цените помощь во всем. – Don

Data truncation: Data too long for column 'col1' at row 1: INSERT INTO my_test_table (col1, col2) VALUES(sha1('test'), sha1('test'))

Возможно, это причина, по которой вы не можете правильно выбрать данные?

источник

2012-05-15 18:32:50

Может быть ошибка в исходном файле, который я скопировал. Мне удалось вставить ok и увидеть результаты в моей таблице после SELECT * – Don

Ну, я пытался помочь в том, что вы мне дали. Не моя обязанность пытаться угадать, что вы имели в виду, когда она явно не работает. В следующий раз попробуйте лучше всего опубликовать рабочий код :) –

Извините. Не хотел быть коротким в моем ответе. Я ценю вашу попытку помочь и согласиться с тем, что это мусор в мусор. Первого ответа было достаточно, чтобы привести меня в правильном направлении, поэтому я работал с этим. Цените помощь. – Don

BTW sha1('test') возвращает строку шестнадцатеричных символов ...

Вы должны использовать unhex(sha1('test')) когда inputing данные в виде шестнадцатеричной строки, иначе оно не будет введено как ACSII значения, которые обычно не будут работать с совпадением

SELECT * FROM my_test_table WHERE col1 = unhex(sha1('test')); также должен соответствовать запросу.

источник

2012-07-15 11:38:50 MoMo

MySQL SELECT против столбца varbinary

ответ

Смежные вопросы