Десятичный интервал VS в MySQL?
Есть ли любое различие в производительности между decimal(10,0) unsigned введите и int(10) unsigned ввести?
3 ответа
Это может зависеть от версии MySQL, которую вы используете. См. здесь .
До MySQL 5.0.3 тип DECIMAL хранился в виде строки и обычно работал медленнее. Однако, начиная с MySQL 5.0.3, тип DECIMAL хранится в двоичном формате, поэтому размер ваш DECIMAL выше, может не быть большой разницы в производительности.
Основной проблемой производительности было бы количество места, занимаемого различными типами (при этом DECIMAL работает медленнее). В MySQL 5.0.3+ это не представляет большой проблемы, однако, если вы будете выполнять числовые вычисления над значениями как часть запроса, может возникнуть некоторая разница в производительности. Возможно, это стоит проверить, поскольку в документации, которую я вижу, нет никаких указаний.
Редактировать:
Что касается int (10) unsigned , я принял это за чистую монету как просто 4-байтовое int. Однако это максимальное значение 4294967295, что строго не обеспечивает тот же диапазон чисел, что и DECIMAL (10,0) без знака .
Как указал @Unreason, вам нужно будет использовать bigint , чтобы охватить весь диапазон 10-значных чисел, увеличивая размер до 8 байтов.
Распространенной ошибкой является то, что при указании типов числовых столбцов в MySQL люди часто думают, что число в скобках влияет на размер числа, которое они могут хранить. Это не так. Диапазон номеров зависит исключительно от типа столбца и от того, подписан он или нет.Число в скобках используется для отображения результатов и не влияет на значения, хранящиеся в столбце. Это также не повлияет на отображение результатов, если вы также не укажете параметр ZEROFILL в столбце.
Согласно данным mysql storage для десятичной дроби потребуется
DECIMAL (10,0): 4 байта для 9 цифр и 1 байт для оставшейся 10-й цифры, итого пять байтов (при условии мое прочтение документации правильно).
INT (10): потребуется BIGINT, равный 8 байтам.
Различия в том, что десятичная дробь упакована, и некоторые операции с такими типами данных могут быть медленнее, чем с обычными типами INT, которые отображаются непосредственно на машинно представленные числа.
Тем не менее, я хотел бы провести ваши собственные тесты, чтобы подтвердить вышеприведенные рассуждения.
РЕДАКТИРОВАТЬ: Я заметил, что не уточнил очевидный момент - предполагая, что приведенная выше логика верна, требуемая разница в размере составляет на 60% больше места, необходимого для варианта BIGINT.
Однако это не приводит напрямую к штрафам из-за того, что данные обычно не записываются побайтно. В случае выбора / обновления многих строк вы должны увидеть потерю / прирост производительности, но в случае выбора / обновления небольшого количества строк файловая система будет извлекать блоки с диска (ов), которые обычно в любом случае будут получать / записывать несколько столбцов .
На размер (и скорость) индексов может повлиять более непосредственное влияние.
Однако вопрос о том, как упаковка влияет на различные операции, все еще остается открытым.
Я сомневаюсь, что такая разница вообще может быть связана с производительностью.
Большинство проблем с производительностью связано с правильным проектированием базы данных и планом индексации, а также с настройкой сервера / оборудования на следующем уровне.