У меня есть таблица MySQL InnoDB с 1000000 записей. Это слишком много? Или базы данных могут справиться с этим и многим другим? Я спрашиваю, потому что заметил, что некоторые запросы (например, получение последней строки из таблицы) медленнее (в секундах) в таблице с 1 миллионом строк, чем в таблице со 100.
Ответы:
У меня есть таблица MySQL InnoDB с 1000000 регистрами. Это слишком много?
Нет, 1000000 строк (записей AKA) - это не слишком много для базы данных.
Я спрашиваю, потому что заметил, что некоторые запросы (например, получение последнего регистра таблицы) выполняются медленнее (в секундах) в таблице с 1 миллионом регистров, чем в таблице с 100.
В этом заявлении есть что учесть. Обычные подозреваемые:
У меня есть база данных с более чем 97000000 записей ( файл данных 30 ГБ ), и у меня нет проблем.
Просто не забудьте определить и улучшить индекс таблицы .
Так что очевидно, что 1 000 000 - это НЕ МНОГО! (Но если вы не индексируете; да, МНОГО)
Используйте «объяснение», чтобы изучить свой запрос и увидеть, есть ли что-нибудь не так с планом запроса.
EXPLAIN- новички или нет.
EXPLAIN ;)
Я думаю, что это распространенное заблуждение: размер - это только одна часть уравнения, когда речь идет о масштабируемости базы данных. Есть и другие сложные (или более сложные) проблемы:
Насколько велик рабочий набор (т. Е. Сколько данных необходимо загрузить в память и над которыми активно работать). Если вы просто вставляете данные и ничего с ними не делаете, это на самом деле легко решить.
Какой уровень параллелизма требуется? Вставляет / читает только один пользователь или у нас одновременно работают несколько тысяч клиентов?
Какие требуются уровни обещания / надежности и постоянства исполнения? Должны ли мы быть уверены, что сможем выполнить каждую фиксацию? Нормально, если средняя транзакция быстрая, или мы хотим убедиться, что все транзакции надежно быстрые (контроль качества шести сигм, например - http://www.mysqlperformanceblog.com/2010/06/07/performance-optimization- и-шесть-сигма / ).
Вам нужно решить какие-либо операционные проблемы, например, ИЗМЕНИТЬ схему таблицы? В InnoDB это возможно, но невероятно медленно, так как часто приходится создавать временную таблицу на переднем плане (блокируя все соединения).
Итак, я собираюсь указать на две ограничивающие проблемы:
Если вы имеете в виду 1 миллион строк, то это зависит от того, как выполняется индексация, и от конфигурации вашего оборудования. Миллион строк - это небольшой объем для корпоративной базы данных или даже для базы данных разработчиков на приличном оборудовании.
если вы имеете в виду 1 миллион столбцов (не уверен, что это возможно даже в MySQL), тогда да, это кажется немного большим и, вероятно, вызовет проблемы.
Регистр? Вы имеете в виду запись?
В наши дни миллион записей - не такая уж большая проблема для базы данных. Если вы столкнетесь с какой-либо проблемой, скорее всего, это не сама система базы данных, а скорее оборудование, на котором вы ее используете. Скорее всего, вы не столкнетесь с проблемой с БД, прежде чем у вас закончится оборудование.
Очевидно, что некоторые запросы выполняются медленнее других, но если два очень похожих запроса выполняются в совершенно разное время, вам необходимо выяснить, каков план выполнения базы данных, и оптимизировать его, т.е. использовать правильные индексы, правильную нормализацию и т. Д.
Между прочим, не существует такой вещи, как «последняя» запись в таблице, с логической точки зрения они не имеют внутреннего порядка.
SELECT LAST_INSERT_ID()вместо этого запрос.
Я видел несекционированные таблицы с несколькими миллиардами (проиндексированных) записей, которые самосоединялись для аналитической работы. В конце концов мы разделили вещь, но, честно говоря, особой разницы не увидели.
Тем не менее, это было в Oracle, и я не тестировал такой объем данных в MySQL. Индексы - ваш друг :)
Предполагая, что вы имеете в виду «записи» под «регистрами», нет, это не слишком много, MySQL очень хорошо масштабируется и может содержать столько записей, сколько у вас есть на жестком диске.
Очевидно, хотя поисковые запросы будут медленнее. На самом деле нет другого пути, кроме как убедиться, что поля правильно проиндексированы.
Чем больше становится таблица (чем больше в ней строк), тем медленнее запросы обычно выполняются, если нет индексов. Как только вы добавите правильные индексы, производительность вашего запроса должна улучшиться или, по крайней мере, не ухудшиться так, как растет таблица. Однако, если сам запрос возвращает больше строк по мере увеличения таблицы, вы снова начнете видеть деградацию.
Хотя 1M строк не так много, это также зависит от того, сколько памяти у вас на сервере БД. Если таблица слишком велика для кэширования в памяти сервером, запросы будут выполняться медленнее.
Использование предоставленного запроса будет исключительно медленным из-за использования метода слияния сортировки для сортировки данных.
Я бы порекомендовал переосмыслить дизайн, чтобы вы использовали индексы для его извлечения или убедитесь, что он уже упорядочен таким образом, поэтому сортировка не требуется.