Как я могу разбить таблицу MySQL на несколько таблиц и запросить правильный массив?

Question

Ниже таблица моего друга,
Я включил 2 записи, чтобы показать, как это работает. Когда пользователь добавляет человека в друзья, он добавляет 2 записи в БД с этим кодом;

<?PHP

 //status 0=approved 1=declined approval 3=pending approval
$sql = "insert into friend_friend (userid,friendid,status,submit_date) 
    values
    ('$_SESSION[auto_id]','$friendid','0',now()), 
    ('$friendid','$_SESSION[auto_id]','3',now())"; //Line above is my user ID, the other users ID, status 0 for approved on my side, date
                                                    //next entry is the receiving users entry, there ID, my ID, 3 for not approved yet, date
executeQuery($sql);

//So that code above is my php that adds a friend

//Below is my table scheme for the friends table
CREATE TABLE IF NOT EXISTS `friend_friend` (
  `autoid` int(11) NOT NULL AUTO_INCREMENT,
  `userid` int(10) DEFAULT NULL,
  `friendid` int(10) DEFAULT NULL,
  `status` enum('1','0','3') NOT NULL DEFAULT '0',
  `submit_date` datetime NOT NULL DEFAULT '0000-00-00 00:00:00',
  `alert_message` enum('yes','no') NOT NULL DEFAULT 'yes',
  PRIMARY KEY (`autoid`),
  KEY `userid` (`userid`),
  KEY `friendid` (`friendid`)
) ENGINE=InnoDB  DEFAULT CHARSET=utf8 AUTO_INCREMENT=1756421 ;

--
-- Dumping data for table `friend_friend`
--
INSERT INTO `friend_friend` (`autoid`, `userid`, `friendid`, `status`, `submit_date`, `alert_message`) VALUES
(637229, 2, 1, '1', '2007-10-18 01:02:00', 'no');
INSERT INTO `friend_friend` (`autoid`, `userid`, `friendid`, `status`, `submit_date`, `alert_message`) VALUES
(637230, 1, 2, '1', '2007-10-18 01:02:00', 'no');

INSERT INTO `friend_friend` (`autoid`, `userid`, `friendid`, `status`, `submit_date`, `alert_message`) VALUES
(637231, 22901, 1, '1', '2007-10-18 02:24:05', 'no');
INSERT INTO `friend_friend` (`autoid`, `userid`, `friendid`, `status`, `submit_date`, `alert_message`) VALUES
(637232, 1, 22901, '1', '2007-10-18 02:24:05', 'no');
?>  

Я хочу разделить таблицу friend_friend на несколько таблиц на основе идентификационного номера пользователя
Как и все идентификаторы пользователей от 1 до 20 000, переходят в одну таблицу, все идентификаторы пользователей: 20 001–40 000, 40 001–60 000 - в другую таблицу

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

Answer 1

Предполагая, что вы используете MySQL 5.1 или выше, вы можете использовать разбиение, чтобы делать то, что вы хотите. Смотрите следующие ссылки:

http://dev.mysql.com/doc/refman/5.1/en/partitioning.html

http://dev.mysql.com/tech-resources/articles/performance-partitioning.html

Answer 2

Термин искусство - «осколок» (чтобы помочь вам в поисках литературы, веб-поисках и т. Д.) - или, по крайней мере, один из популярных терминов искусства (словарь, к сожалению, не полностью исчерпан в этой области).Проведя исследование, вы поймете, что сопутствующая проблема заключается в необходимости запрашивать все фрагменты (и, как правило, объединять их ВСЕ - или иногда объединять их обратно различными способами), когда вы не знаете, где (частично или полностью)Ответ (ы) может быть.

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

О, и, конечно, этот огромный объем деликатной, продвинутой работы НЕ действительно стоит делать, пока она не будет доказана, что она необходима, а затем она будет обеспечивать распределение работы бэкэнда базы данных между многимисерверы, потому что один сервер просто не может сократить его больше.Похоже, вы просто пытаетесь изучить самые основы шардинга (мои извинения, если я читаю это неправильно!), И часть проблемы - как и для других сложных и важных частей архитектуры системы - в том, что нет реальногомотивация, пока размер системы не станет ХОРОШО выше, чем разумно представить в «игрушечном приложении» ...! -)