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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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