Сколько строк в базе данных СЛИШКОМ МНОГО?

Ответ 1

У меня есть таблица MySQL InnoDB с 1000000 регистрами. Это слишком много?

Нет, 1 000 000 строк (записи AKA) не слишком много для базы данных.

Я спрашиваю, потому что заметил, что некоторые запросы (например, получение последнего регистра таблицы) медленнее (в секундах) в таблице с 1 миллионом регистров, чем в одном с 100.

В этом выражении многое предстоит объяснить. Обычными подозреваемыми являются:

• Плохо написанный запрос
• Не использовать первичный ключ, если он существует даже в таблице
• Плохо спроектированная модель данных (структура таблицы)
• Недостаток индексов

Ответ 2

У меня есть база данных с более чем 97 000 000 записей (файл данных 30 ГБ) и без проблем.

Не забудьте определить и улучшить таблицу index.

Итак, очевидно, что 1,000,000 не МНОГО! (Но если вы не индексируете, да, это МНОЖЕ)

Ответ 3

Используйте 'explain', чтобы проверить ваш запрос и посмотреть, нет ли чего-то неправильного в плане запроса.

Ответ 4

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

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

• Какой уровень concurrency требуется? Есть ли только один пользователь, вставляющий/читающий, или у нас есть сразу несколько тысяч клиентов?

• Какие уровни обещания, долговечности и согласованности производительности требуются? Должны ли мы удостовериться, что мы можем соблюдать каждое совершение. Это нормально, если средняя транзакция выполняется быстро или мы хотим, чтобы все транзакции были надежно быстрыми (шесть сигма контроля качества, например - http://www.mysqlperformanceblog.com/2010/06/07/performance-optimization-and-six-sigma/).

• Вам нужны какие-либо операционные проблемы, такие как ALTER для схемы таблиц? В InnoDB это возможно, но невероятно медленно, так как часто приходится создавать временную таблицу на переднем плане (блокирование всех подключений).

Итак, я собираюсь сформулировать две предельные проблемы:

• Ваше собственное умение писать запросы/иметь хорошие индексы.
• Сколько боли вы можете терпеть в ожидании в выражениях ALTER TABLE.

Ответ 5

Я видел несегментированные таблицы с несколькими миллиардными (индексированными) записями, которые были объединены для аналитической работы. В конце концов мы разделили это дело, но, честно говоря, мы не видели такой большой разницы.

Тем не менее, это было в Oracle, и я не тестировал этот объем данных в MySQL. Индексы - ваш друг:)

Ответ 6

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

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

Ответ 7

Регистрация? Вы имеете в виду запись?

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

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

Кстати, в таблице нет такой вещи, как "последняя" запись, с логической точки зрения у них нет неотъемлемого порядка.

Ответ 8

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

Очевидно, что поисковые запросы будут медленнее. На самом деле нет никакого способа обойти это, за исключением того, что поля правильно проиндексированы.

Ответ 9

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

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

Ответ 10

Использование предоставленного запроса будет исключительно медленным из-за использования метода сортировки сортировки для сортировки данных.

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