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

87

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

Хуанхо Конти
источник

Ответы:

114

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

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

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

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

  1. Плохо написанный запрос
  2. Не использовать первичный ключ, если он вообще существует в таблице
  3. Плохо спроектированная модель данных (структура таблицы)
  4. Отсутствие индексов
OMG Пони
источник
4
5. Устаревшие спецификации сервера <В крайнем случае.
Sneakyness
19
@Brimstedt: Я также всегда думал, что существительное должно быть «Указатели», но я не думаю, что когда-либо видел, чтобы кто-нибудь использовал его для баз данных: от Википедии: en.wikipedia.org/w/… до Mr. Coding Horror: codinghorror. ru / blog / archives / 000638.html . По этой теме есть интересное сообщение SO: stackoverflow.com/questions/1001366 .
Даниэль Вассалло
7
6. Недостаточно памяти, выделенной для различных кешей innodb
Джейсон
для лучшей производительности должен ли я использовать PrimaryKey? А как насчет использования других ключей, таких как Index, Unique? Могу я использовать это? спасибо
user1844933 02
Возможно, компьютер перегружен памятью, как сказал Джейсон, и отключается на середине процесса
ytpillai
67

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

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

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

амир бейги
источник
10
Будет ли добавление «первичного ключа» к столбцу (путем выбора автоматического увеличения) индексированием?
Натан
8
@Nathan, на самом деле, когда вы назначаете столбец первичным ключом, он автоматически становится индексированным, но каждая таблица может иметь только один первичный ключ, если вам нужно добавить индекс для некоторого столбца, для оптимизации запросов используйте этот stackoverflow.com/ a / 3002635/932473
dav
У меня есть таблица с одним триллионом, но выбор данных в формате IN LIFO выполняется медленно?
Саураб Чандра Патель,
Определите отсутствие проблем. Сколько времени занимает самый сложный запрос? У нас есть таблица со 100 миллионами строк, и клиент ожидает, что запросы будут выполнены максимум за 5 секунд, независимо от того, какие критерии группировки или упорядочения они используют. Наши индексы можно улучшить, но прежде чем мы заблокируем все, пытаемся добавить индекс
Джо Яхчучи
20% производственных таблиц (согласно старому исследованию) имеют более 1 миллиона строк. Я видел несколько с несколькими миллиардами строк.
Рик Джеймс
19

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

Программист-подмастерье
источник
6
Хотя это хорошая идея, сам по себе такой ответ не годится для новичка. Вывод EXPLAIN не очень интуитивно понятен ...
nickf 03
17
Нет другого инструмента, который помог бы вам изучить запросы, так что лучше начните учиться EXPLAIN- новички или нет.
nos
30
было бы неплохо, если бы кто-то мог ОБЪЯСНИТЬ EXPLAIN ;)
Джо Э.
7
@Deadpool Mysql Explain Explained
Sithsu
15

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

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

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

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

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

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

  • Ваше собственное умение писать запросы / иметь хорошие индексы.
  • Сколько боли вы можете терпеть, ожидая выполнения операторов ALTER TABLE.
Морган Токер
источник
2
Изменить: совет по созданию временных таблиц с помощью ALTER TABLE немного устарел. MySQL 5.5 имеет быстрое создание индекса, а 5.6 теперь имеет онлайн-DDL.
Морган Токер
3

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

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

GrayWizardx
источник
3

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

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

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

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

Феб
источник
Я имею в виду что-то вроде «ВЫБРАТЬ * ИЗ таблицы ORDER BY id DESC LIMIT 0»
Хуанджо Конти
4
Может тебе нужен SELECT LAST_INSERT_ID()вместо этого запрос.
True Soft
3

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

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

Jé Queue
источник
2

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

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

Томас Бонини
источник
2
Технически размер таблицы также может быть ограничен максимальным размером файла в файловой системе, которую вы используете.
tster
0

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

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

Jvilalta
источник
0

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

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

Луи
источник