char vs varchar для производительности в базе данных акций

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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