MySQL: рекомендуемое количество строк

Question

Рассмотрим индексированную таблицу MySQL с 7 столбцами, которая постоянно запрашивается и записывается. Какое количество строк рекомендуется содержать в этой таблице, прежде чем производительность будет улучшена путем разделения данных на другие таблицы?

Answer 1

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

Answer 2

Магического числа нет, но есть несколько вещей, которые влияют на производительность, в частности:

• Индекс кардинальности: не потрудитесь индексировать строку с 2 или 3 значениями (например, ENUM). В большой таблице оптимизатор запросов будет игнорировать их.
• Есть компромисс между записью и индексами. Чем больше у вас индексов, тем больше времени занимает запись. Не просто индексировать каждый столбец. Проанализируйте ваши запросы и посмотрите, какие столбцы нужно проиндексировать для вашего приложения.
• Дисковый ввод-вывод и память играют важную роль. Если вы можете поместить всю таблицу в память, вы берете дисковый ввод-вывод из уравнения (в любом случае, когда таблица кэшируется). Я предполагаю, что вы увидите значительное изменение производительности, когда ваша таблица слишком велика для буферизации в памяти.
• Рассмотрите возможность разделения ваших серверов в зависимости от использования. Если ваша транзакционная система читает / записывает отдельные строки, вы, вероятно, можете выиграть себе время, реплицировав данные на сервер только для чтения для сводных отчетов.

Как вы, наверное, знаете, производительность таблицы изменяется в зависимости от размера данных. Следите за таблицей / запросами. Вы узнаете, когда придет время для перемен.

Answer 3

В MySQL 5 встроено разбиение , и это очень хорошо. Что приятно, вы можете определить, как ваш стол должен быть разделен. Например, если вы запрашиваете в основном на основе идентификатора пользователя, вы можете разбить таблицы на основе идентификатора пользователя, или если вы запрашиваете по датам, делайте это по дате. Что хорошо в этом, так это то, что MySQL будет точно знать, в какой таблице разделов искать, чтобы найти ваши значения. Недостатком является то, что при поиске в поле, которое не определяет ваш раздел, оно будет сканировать каждую таблицу, что может снизить производительность.

Answer 4

Вы используете MyISAM? Вы планируете хранить более пары гигабайт? Не упустите MAX_ROWS и AVG_ROW_LENGTH.

У Джереми Заводни есть отличная статья о том, как решить эту проблему.

Answer 5

На самом деле это хороший вопрос для производительности. Вы читали Джей Пайпс ? Не существует определенного числа строк, но есть определенный размер страницы для чтения, и могут быть веские причины для вертикального разбиения.

Посмотрите его презентацию по кунг-фу и просмотрите его посты. Я уверен, вы обнаружите, что он написал несколько полезных советов по этому поводу.

Answer 6

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

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

Размер файла MyISAM данных 2G является только значением по умолчанию и может быть изменен во время создания таблицы (или позже с помощью ALTER, но для этого необходимо перестроить таблицу). Это не относится к другим двигателям (например, InnoDB).

Answer 7

Используя движок MyISAM, вы столкнетесь с жестким ограничением размера таблицы в 2 ГБ, если не измените значение по умолчанию.

Answer 8

Хотя по факту вы можете указать размер таблицы, при которой производительность стала проблемой, я не думаю, что вы можете предсказать это, и уж точно не из информации, представленной на таком веб-сайте, как этот!

Некоторые вопросы, которые вы могли бы с пользой задать себе:

• Является ли производительность в настоящее время приемлемой?
• Как измеряется производительность? есть метрика?
• Как мы узнаем недопустимая производительность?
• Мы измерять производительность любым способом, который может позволить нам прогнозировать проблема
• Все наши запросы используют эффективный индекс?
• Имитировали ли мы экстремальные нагрузки и объемы в системе?