Двоичный файл MySQL против недвоичного файла для идентификаторов хеша
Если вы явно setPreferredSize(new Dimension(X, Y));, то лучше использовать:
setLocation(dim.width/2-this.getPreferredSize().width/2, dim.height/2-this.getPreferredSize().height/2);
2 ответа
Да. Часто обзор хеша хранится как представление ASCII шестнадцатеричных цифр, например, MD5 слова 'хеш':
0800fc577294c34e0b28ad2839435945
Это - строка ASCII с 32 символами.
, Но MD5 действительно производит 128-разрядное двоичное значение хэш-функции. Это должно требовать, чтобы только 16 байтов были сохранены как двоичные значения вместо шестнадцатеричных цифр. Таким образом, можно получить некоторую эффективность пространства при помощи двоичных строк.
CREATE TABLE test.foobar (
id BINARY(16) NOT NULL PRIMARY KEY
);
INSERT INTO test.foobar (id) VALUES (UNHEX(MD5('hash')));
Ре. Ваши комментарии, что Вы более обеспокоены производительностью, чем эффективность пространства:
я не знаю ни о какой причине, что Двоичный тип данных был бы более быстрым, чем CHAR.
Являющийся вдвое менее большим может быть преимущество для производительности, если Вы используете кэш-буферы эффективно. Таким образом, данная сумма кэш-памяти может сохранить вдвое больше ценности строк ДВОИЧНЫХ ДАННЫХ, если строка является половиной размера CHAR, должен был сохранить то же значение в шестнадцатеричном числе. Аналогично кэш-память для индекса на том столбце может сохранить вдвое больше.
результатом является более эффективный кэш, потому что случайный запрос имеет больший шанс удара кэшированных данных или индекса, вместо того, чтобы требовать доступа к диску. Эффективность кэша важна для большинства приложений базы данных, потому что обычно узкое место является диском ввод-вывод. Если можно использовать кэш-память для сокращения частоты диска ввод-вывод, это - намного больший удар для маркера, чем выбор между одним типом данных или другим.
Что касается различия между строкой хеша, сохраненной в ДВОИЧНОМ ФАЙЛЕ по сравнению с BIGINT, я выбрал бы BIGINT. Эффективность кэша будет еще больше, и также на 64-разрядной целочисленной арифметике процессоров, и сравнения должны быть очень быстрыми.
у меня нет измерений для поддержки требований выше. Чистая прибыль предпочитания одного типа данных по другому во многом зависит от шаблонов данных и типов запросов в Вашей базе данных и приложении. Для получения самого точного ответа необходимо попробовать оба решения и измерить различие.
<час>Ре. Ваша гипотеза, что сравнение двоичной строки более быстро, чем нечувствительное к регистру сравнение строк по умолчанию, я попробовал следующий тест:
mysql> SELECT BENCHMARK(100000000, 'foo' = 'FOO');
1 row in set (5.13 sec)
mysql> SELECT BENCHMARK(100000000, 'foo' = BINARY 'FOO');
1 row in set (4.23 sec)
, Таким образом, сравнение двоичной строки на 17,5% быстрее, чем нечувствительное к регистру сравнение строк. Но заметьте, что после оценки этого выражения 100 миллион раз, общим различием является все еще меньше чем 1 секунда. В то время как мы можем измерить относительную разницу в скорости, абсолютная разность в скорости действительно незначительна.
, Таким образом, я повторю:
- Мера, не угадывайте или предполагайте. Ваши образованные предположения будут неправильными много времени. Мера прежде и после каждого изменения, которое Вы вносите, таким образом, Вы знаете, какому количеству это помогло.
- Инвестируют Ваше время и внимание, где Вы получаете самый большой удар для маркера.
- не потеют маленький материал. Конечно, крошечное различие складывает с достаточными повторениями, но, учитывая те повторения, повышение производительности с большим абсолютным преимуществом все еще предпочтительно.
От руководство :
The BINARY and VARBINARY types are similar to CHAR and VARCHAR, except
that they contain binary strings rather than non-binary strings. That is,
they contain byte strings rather than character strings. This means that
they have no character set, and sorting and comparison are based on the
numeric values of the bytes in the values.
Начиная с CHAR (32) ДВОИЧНЫЙ ФАЙЛ заставляет столбец BINARY (32) быть созданным под капотом, преимущество - то, что потребуется меньше времени к виду тем столбцом, и вероятно меньше времени для нахождения соответствующих строк, если столбец будет индексирован.