Сколько строк в базе данных слишком много?

Question

У меня есть таблица MySQL InnoDB с 1 000 000 записей. Это слишком много? Или базы данных могут обрабатывать это и многое другое? Я спрашиваю, потому что заметил, что некоторые запросы (например, получение последней строки из таблицы) медленнее (секунд) в таблице с 1 миллионом строк, чем в одном с 100.

Answer 1

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

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

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

В этом утверждении есть что учитывать. Обычные подозреваемые:

1. Плохо написанный запрос
2. Не используется первичный ключ, при условии, что он существует в таблице
3. Плохо спроектированная модель данных (структура таблицы)
4. Отсутствие индексов

Answer 2

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

Только не забудьте определить и улучшить свою таблицу index .

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

Answer 3

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

Answer 4

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

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

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

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

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

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

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

Answer 5

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

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

Answer 6

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

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

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

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

Answer 7

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

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

Answer 8

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

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

Answer 9

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

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

Answer 10

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

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