Как разделить данные по таблицам MySQL - PullRequest
Новая
       16

Как разделить данные по таблицам MySQL

2 голосов
/ 27 ноября 2008

У меня есть веб-сайт с участниками, которые сообщают друг другу. Есть несколько участников, и им нравится отправлять сообщения - я уверен, что вы можете видеть, куда это идет.

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

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

Кто-нибудь уже сделал? уже?

Ответы [ 3 ]

3 голосов
/ 27 ноября 2008

Я бы определенно разделил таблицу 'messages' на несколько. Например:

MessageStatus Сообщение MessageText

Таким образом, если вы отображаете список элементов в чьем-то почтовом ящике, вам нужно только отсканировать таблицу «Сообщение», которая меньше и имеет столбцы фиксированной длины для максимальной скорости поиска. Когда кто-то хочет открыть и просмотреть текст сообщения, вы попадаете в таблицу «MessageText». «Состояние сообщения» - это просто справочная таблица, которую можно соединить с FK'd tinyint с таблицей «Сообщение».

Вы будете иметь намного большую производительность по сравнению с 1 таблицей, возможно, со средним текстовым столбцом.

0 голосов
/ 27 ноября 2008

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

Если вы обеспокоены производительностью этой таблицы, сначала мудро выбирайте механизм хранения в зависимости от ваших потребностей: мой совет будет использовать InnoDB, поскольку он будет интенсивно писать. Затем посмотрите на индексы, чтобы ускорить чтение.

Что вы можете сделать, если таблица действительно становится слишком большой и медленной, это создать 2 таблицы:

  • таблица messages_archive с хранилищем MyISAM (используется только для быстрого поиска и поиска «заархивированных» сообщений).

  • таблица messages_inbox с хранилищем InnoDB: это таблица, в которую часто вставляются новые сообщения.

Дополнительно:

  • a messages_drafts, сохраняющий автоматически сохраненные сообщения. Причина: нет необходимости замедлять таблицу входящих с черновиками сообщений.

Кстати, это не «стандартное решение», как вы сказали, а просто идея. :)

РЕДАКТИРОВАТЬ:

Из вашего комментария я понимаю, что на самом деле вы ищете " Partitioning ".

Различные типы разделов MySQL позволяют физически разделять данные по диапазону, списку, ключу или хешу.

0 голосов
/ 27 ноября 2008

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

При правильной индексации и точной настройке вам потребуется несколько сообщений, требующих перемещения их по нескольким таблицам, если только это не связано с пробелом.

...