Char vs var char для производительности в базе данных запаса

Ответ 1

В MyISAM есть некоторые преимущества для записи фиксированной ширины. VARCHAR - это переменная ширина. CHAR - фиксированная ширина. Если ваши строки имеют только типы данных фиксированной ширины, то вся строка имеет фиксированную ширину, а MySQL получает некоторое преимущество, вычисляя требования к пространству и смещение строк в этой таблице. Тем не менее, преимущество может быть небольшим, и вряд ли это может стоить возможного крошечного выигрыша, который перевешивается из-за других затрат (например, эффективности кеша) из колонок с фиксированной шириной и толщиной CHAR, где VARCHAR будет хранить более компактно.

Точка останова, где она становится более эффективной, зависит от вашего приложения, и это не то, на что можно ответить, за исключением того, что вы тестируете оба решения и используете тот, который лучше всего подходит для ваших данных при использовании вашего приложения.

Что касается INT (7) по сравнению с INT (11), это не имеет отношения к хранению или производительности. Это распространенное недоразумение в том, что аргумент MySQL для типа INT имеет какое-либо отношение к размеру данных - это не так. Тип данных MySQL INT всегда 32 бит. Аргумент в круглых скобках относится к тому, сколько цифр для пэда, если вы показываете значение с помощью ZEROFILL. Например. INT (7) отобразит 0001234, где INT (11) отобразит 00000001234. Но это заполнение происходит только при отображении значения, а не во время вычисления памяти или математики.

Ответ 2

Если фактические данные в поле могут сильно различаться по размеру, varchar лучше, потому что он ведет к меньшим записям, а меньшие записи означают более быструю БД (больше записей могут вписываться в кеш, меньшие индексы и т.д.). По той же причине лучше использовать меньшие ints, если вам нужна максимальная скорость.

OTOH, если дисперсия мала, например. поле имеет максимум 20 символов, а большинство записей на самом деле составляют почти 20 символов, тогда char лучше, потому что он позволяет некоторым дополнительным оптимизации с помощью БД. Однако это действительно имеет значение, если это верно для ВСЕХ полей в таблице, потому что тогда у вас есть записи фиксированного размера. Если ваша основная проблема связана с скоростью, возможно, даже стоит переместить любые поля нефиксированного размера в отдельную таблицу, если у вас есть запросы, которые используют только поля фиксированного размера (или если у вас есть только запросы с дробовиками).

В конце концов, это сложно обобщить, потому что многое зависит от шаблонов доступа вашего фактического приложения.

Ответ 3

Учитывая ваши системные ограничения, я бы предложил varchar, поскольку все, что вы делаете с данными, должно будет учитывать любые дополнения, которые вы используете, чтобы использовать фиксированную ширину char. Это означает, что где-то больше кода, что больше для отладки и больше возможностей для ошибок. Это сказано:

Основным узким местом в вашем приложении является сокращение и повторное создание базы данных каждые пять минут. Вы не получите большую выгоду от использования микрофонностей, например, выбрав char над varchar. Я считаю, что у вас есть еще более серьезные архитектурные проблемы. - Принцесса

Я согласен с вышеуказанным комментарием. У вас есть большая рыба, чтобы жарить в вашей архитектуре, прежде чем вы можете позволить себе беспокоиться о различии между char и varchar. Во-первых, если у вас есть веб-пользователь, пытающийся запустить специальный запрос, и база данных находится в процессе воссоздания, вы будете получать ошибки (например, "база данных не существует" или просто "время ожидания" )).

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

Ответ 4

Я бы определенно не воссоздавал базу данных каждый раз. Вместо этого я бы сделал следующее:

• прочитайте в файле update/snapshot и создайте некоторый объект на основе каждой строки.
• для каждой строки присваивается имя символа/опции (уникальное) и устанавливается в базе данных

Если бы это был я, у меня также был бы кеш в памяти всех символов и текущих данных о ценах.

Данные о ценах никогда не бывают int - вы можете использовать символы.

Название компании, вероятно, не уникально, так как существует множество вариантов для конкретной компании. Это должен быть индекс, и вы можете сэкономить место, просто используя идентификатор компании.

Как заметил и другой человек, вашим веб-клиентам не нужно ударять по фактической базе данных и делать запрос - возможно, вы можете просто нажать на свой кеш. (хотя это действительно зависит от того, какие таблицы и данные вы предоставляете своим клиентам и какие данные они хотят)

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

Ответ 5

Также помните, что создание баз данных зависит от используемой вами фактической реализации базы данных. Если вы когда-либо порт от MySQL до, скажем, Postgresql, вы обнаружите очень неприятный факт, что создание баз данных в postgresql является сравнительно очень медленной операцией. Это на порядок медленнее, чем чтение и запись строк таблицы, например.

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