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