MySQL большой Шестнадцатиричные Индексы

Question

[решено]

в первый раз я наткнулся на базу данных со значительным ростом (125,000 вставки/день).

Эта база данных используется для отслеживания оборудования сети.

У меня есть много данных, относящихся к этим устройствам, и я буду обновлять их day2day (проверяя, были ли они обновлены/понижены/изменены позиции/остались неустановленными и тысячи вещей). SO означает, что мне нужно постоянно обновлять их и Только фиксированная вещь будет их серийными номерами.

Теперь моя головная боль начинается ...

У меня есть бесполезное ID [INT (11) PK), это бесполезно, потому что я делаю основан на SerialNumbers [VARCHAR (22) UQ].

Оглядываясь дальше, я видел, что серийные номера всегда HEX из (от 7 до 24) мест, первая вещь в моем сознании была: TADA решена, просто поместите эти серийные числа как целые и работайте каждый раз, когда конверсии hex2dec ничего не представляют ... Тогда я выяснил, что неподписанных биноклей недостаточно для чисел, больших HEX (16).

И, наконец, вопрос:

Кто-нибудь есть какие-либо идеи о том, который является самым быстрым индексируемым способом хранения моего SERIALNUMBER поля?

Я не возражаю, если вы не пробовали решение, которое вы собираетесь сказать, любая идея будет приветствоваться и Upvoted :)

На рисунке ниже показан счетчик serialnumbers для каждого SerialNumber длина у меня есть в базе данных.

Answer 1

Прежде всего, отметьте время. Индексирование на такой короткий символ не намного медленнее, чем индексирование 64-битных int. Поместите свой сериал как ПК. Для других решений вы можете использовать 64-битный хеш или серийный (beware collisions!) Или разделять длинные сериальные файлы на 2 части и создавать составные PK на двух столбцах, которые, я думаю, будут медленнее, чем простой индекс в Serial.

Answer 2

Может быть, это не самый лучший способ, но, по крайней мере, достаточно для этого случая:

Использование SERIALNUMBER в VARCHAR (25) ПК (414 секунд для 10.000.000.000 селекцию) Использование SERIALNUMBER в CHAR (25) PK с LPAD (401 секунд для 10.000.000.000 выбирает)

после просто с помощью ANALYZE TABLE и OPTIMIZE TABLE после каждой фиксации, я пошел к победителю: используя SerialNumber, как VARCHAR (25) PK (268.759 секунд для 10.000.000.000)

BTV, также обнаружили, что с помощью небольших обновлений в моем столе был быстрее, чем при использовании только один, из-за этого: Currently one SQL statement runs from start to end in the same physical thread.