Каков оптимальный объем данных для таблицы?

Question

Сколько данных должно быть в таблице, чтобы чтение было оптимальным? Предполагая, что у меня есть 3 поля varchar (25). Это в MySQL.

Answer 1

Я бы посоветовал вам учесть следующее при оптимизации вашей базы данных:

1. Подумайте, чего вы хотите достичь с помощью базы данных. Будете ли вы выполнять много вставок в одну таблицу с очень высокой скоростью? Или вы будете выполнять отчетные и аналитические функции с данными?
2. После того как вы определили назначение базы данных, определите, какие данные необходимо хранить для выполнения любых необходимых функций.
3. Нормализуй до боли. Если вы выполняете обработку транзакций (наиболее распространенная функция для базы данных), вам понадобится сильно нормализованная структура базы данных. Если вы выполняете аналитические функции, вам понадобится более денормализованная структура, которая не должна полагаться на объединения для создания результатов отчета.
4. Как правило, если вы действительно нормализовали структуру до тех пор, пока она не причинит боль, тогда вам нужно вернуться к шагу или двум нормализации, чтобы получить структуру данных, которая будет как нормализованной, так и функциональной.
5. Нормализованная база данных в большинстве случаев бессмысленна, если вы не используете ключи. Убедитесь, что в каждой таблице определен первичный ключ. Не используйте суррогатные ключи просто потому, что вы всегда видите это. Рассмотрим, какие естественные ключи могут существовать в любой данной таблице. Как только вы убедитесь, что у вас есть правильный первичный ключ для каждой таблицы, вам нужно определить ссылки на внешние ключи. Установление явных отношений с внешним ключом вместо того, чтобы полагаться на неявное определение, даст вам повышение производительности, обеспечит целостность ваших данных и самодокументирует структуру базы данных.
6. Найдите другие индексы, которые существуют в ваших таблицах. У вас есть столбец или набор столбцов, по которым вы будете часто искать, например, поле имени пользователя и пароля? Индексы могут находиться в одном или нескольких столбцах, поэтому подумайте, как вы будете запрашивать данные, и создавайте индексы, необходимые для значений, к которым вы будете запрашивать.

Answer 2

Согласитесь, что вы должны убедиться, что ваши данные правильно проиндексированы.

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

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

Answer 3

Количество строк не должно иметь значения. Убедитесь, что поля, по которым вы ищете, правильно проиндексированы. Если у вас есть только 3 поля varchar (25), то вам, вероятно, нужно добавить первичный ключ, который не является varchar.

Answer 4

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

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

Answer 5

Я должен не согласиться с Круханом по поводу "строк 50k - 100k .... примерно соответствуют (в) точке, в которой rdbms, вероятно, будет ограничен в памяти". Это общее утверждение просто вводит в заблуждение без двух дополнительных данных: прибл. Размер строки и доступной памяти. В настоящее время я разрабатываю базу данных, чтобы найти самую длинную общую подпоследовательность (а-ля биоинформатику) строк в файлах исходного кода, и достигла миллионов строк в одной таблице, даже с полем VARCHAR, близким к 1000, прежде чем он стал памятью ограничены. Таким образом, при правильном индексировании и достаточном объеме оперативной памяти (один или два гигабайта), что касается исходного вопроса, со строками не более 75 байтов, нет никаких причин, по которым предлагаемая таблица не может содержать десятки миллионов записей.

Answer 6

Это очень свободный вопрос, поэтому очень свободный ответ: -)

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

Однако, как только вы пройдете 50–100 тыс. Строк, что примерно соответствует точке, в которой rdbms, вероятно, будет ограничен в памяти - тогда, если у вас не настроены правильные пути доступа (то есть индексы), производительность начнет падать катастрофически Это в математическом смысле - в таком сценарии нередко наблюдается снижение производительности на порядок или два при удвоении размера таблицы.

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

Answer 7

Выражено как таковое, я не знаю, как ответить на этот вопрос. Идентифицированная таблица из 100 000 записей быстрее, чем неиндексированная таблица из 1000.

Каковы ваши требования? Сколько данных у вас есть? Узнав ответ на эти вопросы, вы можете принять решение об индексации и / или разбиении.

Answer 8

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