Какой префикс использовать при индексации строкового столбца SecureRandom

Question

У меня есть столбец БД (тип varchar(255)), в котором хранится URL-безопасная строка base 64, созданная SecureRandom.urlsafe_base64.Вызов метода использует значения по умолчанию, поэтому результат должен составлять 16 байтов или 22 символа длиной .

Значение base64 используется для поиска записей, когдапользователь заходит на сайт, чтобы замаскировать идентификаторы БД.Мне нужен индекс для этого столбца из-за этого поиска, однако я не хочу индексировать весь столбец, потому что может быть неэффективным с точки зрения хранения.

Каков наилучший подход к определениюоптимальный префикс индекса для использования в этом случае?Сейчас я думаю, что-то вроде этого:

1. Создать пример данных с около 100 тыс. Записей для имитации производственных данных
2. Добавить индекс для столбца base 64 с префиксом (скажем, 8 символов)
3. Запустите EXPLAIN при поиске в столбце base 64, чтобы увидеть, сколько записей нужно проверить
4. Настройте индекс вверх или вниз и повторите шаг 3.
5. Выберите размер префикса, который уравновешивает (а) требования к хранилищу и (б) количество записей, возвращаемых с совпадающими попаданиями.

Проблема здесь в том, что я знаю, SecureRandom производит уникальныестроки base 64, но я не уверен насколько они уникальны .Например, из 100 тыс. Записей, если я использую префикс из 8 символов, будет ли этот префикс разделен на 10 записей или 100?

Некоторые более конкретные вопросы о моем подходе:

1. Достаточно ли 100 тыс. Записей выборки для выбора хорошего размера префикса?
2. Если я применил индекс без с использованием префикса, есть ли у меня подозрение, что это неправильно с точки зрения хранилища?
3. Какое разумное количество записей может потребоваться для непосредственного запроса к таблице и при этом все равно получить выгоду от индекса?

Примечания :

• Моя база данных - MySQL (на самом деле Percona)
• SecureRandom взята из Ruby
• Я предполагаю, что функция безопасного URL-адреса SecureRandom не меняет уникальностьХарактеристики базы 64 вывода.

Answer 1

Это просто случайное число, верно?Не шифрование.

Do not использовать префикс;хотя это несколько сократит размер индекса, во многих случаях это приведет к аннулированию использования индекса.Правда, 22 байта длиннее, чем строка из 8 символов или 4 байта INT.Но обратная сторона отказа от использования индекса хуже.

Значение по умолчанию 16 (22) достаточно, чтобы случайная строка была достаточно уникальной, чтобы избежать случайных столкновений.

Не говорите VARCHAR(255), если максимальное значение равно 22. Скажите CHAR(22), если фиксированная длина, или VARCHAR(22), если вы разрешаете пользователю выбирать длину до 16.

Скажите CHARACTER SET ascii COLLATE ascii_bin для столбца.Это позволит избежать (1) накладных расходов на utf8 и (2) ошибки сворачивания регистра.

Если у вас будет индекс для миллиарда этих элементов, тогда будут существенные проблемы с производительностью, как обсуждалось здесь (хотя и в другом контексте).Миллион строк, вероятно, не проблема - это зависит от того, когда индекс становится больше, чем может быть кэширован в ОЗУ в buffer_pool.

(Если я правильно помню формулу, для 8 символов, как вы описали,был бы один шанс в 300K, что индекс с записями в 300K будет содержать дубликат. Но это не проблема.)