Производительность MySQL по одному и тому же типу целых, но разным числам

Question

Скажем, INT

Есть ли разница в производительности при поиске по номерам от 1 до 100М и по номерам между 3,9В-4В, или же задействовано одинаковое количество байтов без учета ихзначения?

Как мы знаем, при сравнении, например, abcdef и abcXYZ, они сканируются слева направо, и разница не обнаруживается до 4-го символа.Возможно, с другими типами данных случай тот же.

Допустим, поле типа INT имеет, например, байты 00 00 00 0F по сравнению с 00 00 AA 99.Тогда, может быть, разница должна быть найдена на 3-м байте.Что предполагает, что более высокие значения лучше для производительности.

.,,Или, может быть, вся работа выполняется с помощью одной 32-битной машинной инструкции?Если так, то что происходит, например, с BIGINT?

И как подвопрос: Есть ли разница при индексировании или неиндексировании?

Answer 1

Короткие ответы: Нет и Нет.

Длинные ответы:

INT (или INT UNSIGNED) is always 4 bytes. Comparing two INTs`, вероятно, выполняется с помощью одной 32-битной машинной инструкции. Отсюда "1"и" 4 миллиарда "имеют одинаковый размер и могут работать одинаково быстро.

VARCHAR(...) (и VARBINARY) - это другая ситуация. При сравнении 'abcdef' и 'abcXYZ' онисканируются слева направо. Разница не обнаруживается до 4-го символа. То есть сравнение двух строк занимает переменное количество времени. НО ... Эта разница относительно незначительна по сравнению со всеми другими поисками строк, BTree-обход, синтаксический анализ строк и т. д., и т. д., которые должны произойти.

Пространство, занятое для VARCHAR, является, как следует из названия, переменной. За ним следует длина одного или двух байтовна количество байтов, достаточное для обработки заданных символов.

FLOAT, DOUBLE, BIGINT, TINYINT и т. д. аналогичны INT в вышеуказанных свойствах. Фиксированный размер (4, 8,8, 1 байт) и фиксированное время сравнения.

DECIMAL и CHAR занимает фиксированноеколичество места, но переменное количество времени, чтобы сделать сравнение.

• Не беспокойтесь о INT против VARCHAR.

• Не беспокойтесь о количестве элементов всего ключа .Под этим я подразумеваю, что INDEX(city, state) не лучше, чем INDEX(state, city) при тестировании для city и state с =.

Но ваш вопрос был по поводу индексациипо сравнению с неиндексированным.В таблице есть две структуры: «Данные» и, если имеется, «Индекс».Они отдельные.Фактические биты в данных для столбцов не изменяются, если вы добавляете или удаляете индекс.Индекс (ы) имеют копию (копии) набора столбцов.

Индекс с миллионами строк будет иметь BTree глубиной около 3 уровней.Триллион рядов - около 6 уровней.То есть глубина BTree растет очень медленно по сравнению с количеством рядов.Итак, опять же, вы обычно можете игнорировать размер BTree.

Что касается различных размеров INT ... У меня нет фактического ответа (без чтения кода), но вот некоторыемысли ...

• SIGNED может потребоваться отдельный тест для знакового бита.
• До того, как 64-битные машины были повсеместными, я уверен, что BIGINT был смоделированчерез два 32-битных значения.Это почти наверняка потребовало двухэтапного теста, который мог быть закорочен.Между тем сложение делало два шага, а умножение тоже несколько.Возможно, MySQL был реализован на нескольких 16-битных машинах, поэтому даже INT пришлось разделить.
• Я действительно сомневаюсь, что INT делается байт за раз;было бы более разумно извлечь 4 байта в общем коде, а затем выполнить сравнение на уровне машины со знаком или без знака.
• Обратите внимание, что DECIMAL нельзя сделать так же, как INT из-за его переменной-длина природы.
• Станут ли вещи в будущем более «атомными»?Возможно.Давайте вернемся назад к старым реализациям с плавающей запятой.Последний этап большинства операций - сдвиг влево результата, чтобы «нормализовать» представление.Первоначально это включало цикл до «сдвига влево на 1 (или 2, или 3 (восьмеричное), или 4 (шестнадцатеричное)) бита до тех пор, пока первый не перестанет быть нулевым».Довольно быстро они изобрели «переключатели стволов» и т. Д., Которые позволили выполнить эту задачу за один машинный цикл (или, по крайней мере, фиксированное количество циклов).Деление остается медленной операцией из-за необходимости «петли».Может быть, когда-нибудь переменную длину DECIMAL можно будет сделать без зацикливания?

Answer 2

Я думаю, что на достаточно низком уровне целочисленное сравнение должно будет потенциально проверять каждый бит в каждом числе.Итак, я не уверен, что существует проблема производительности с целочисленным размером сама по себе.Что касается индекса (B-дерево), самой большой проблемой для производительности является количество элементов в столбце.Если столбец имеет только несколько значений и много строк, то индекс не поможет.По мере роста индекса и добавления новых значений в B-дерево, я полагаю, что это может занять больше и больше времени, чтобы пройти по дереву.Но это также не обязательно имеет отношение к тому, насколько большие числа, а скорее к тому, сколько значений являются частью индекса.