Comment puis-je diviser une table mysql en plusieurs tables et interroger l'arrea correct?

Question

Ci-dessous est ma table d'amis,
J'ai inclus 2 entrées pour montrer comment cela fonctionne, Quand un utilisateur ajoute une personne comme un ami, il insère 2 entrées dans la base de données avec ce code;

<?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'); 
?> 

Ce que je voulais faire est divisé la table friend_friend vers le haut dans plusieurs tables en fonction du nombre d'ID utilisateur
Comme tous les ID utilisateur de entre 1-20,000 aller à une table, tous les noms d'utilisateurs 20,001-40,000, 40,001- 60 000 vont tous à une autre table

Je ne sais pas comment faire mieux, je aurais besoin de détecter quelle table un utilisateur doit interroger lors de l'ajout d'un nouvel ami et ainsi que lors de la récupération liste d'amis des utilisateurs
je suppose dans mon code en haut, les 2 entrées pour ajouter un utilisateur devraient être divisées en 2 requêtes et mettre à jour des tables différentes probablement?

Answer 1

En supposant que vous utilisez MySQL 5.1 ou supérieur, vous pouvez utiliser le partitionnement pour faire ce que vous voulez. Voir les liens suivants:

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

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

Answer 2

Le terme d'art est "sharding" (pour vous aider dans les recherches de la littérature, recherches sur le Web, etc.) - ou tout au moins, un terme populaire l'art (le vocabulaire n'est malheureusement pas complètement réglé dans ce domaine). Une fois que vous faites des recherches, vous apprendrez que le problème concomitant est d'avoir à interroger tous les fragments (et à les ALLER, typiquement - ou parfois les agréger de différentes manières) quand vous ne savez pas où (tout ou partie) la réponse (s) peut être. Donc, sharding (en particulier "sharding horizontal", ce que vous faites ici) devrait être fait de manière spécifique à l'application, pour essayer de grouper les entrées qui sont "ensemble" afin que le plus souvent possible vérifier un seul fragment suffira. Il est plus facile de concevoir un sharding vertical (placer des colonnes différentes plutôt que des rangées dans des tables différentes), car il suffit d'examiner les requêtes les plus fréquentes pour s'assurer que chacune d'entre elles est parfaitement satisfaite. Oh, et, bien sûr, cette énorme quantité de travail avancé et délicat ne vaut vraiment pas la peine d'être faite jusqu'à ce que l'on prouve que c'est nécessaire - et ensuite, il faudra s'assurer que le travail du backend de la base de données est réparti serveurs, car un seul serveur ne peut plus le couper. Vous semblez juste essayer d'apprendre les principes fondamentaux de sharding (mes excuses si je lis mal ceci -) et une partie du problème - comme pour d'autres parties difficiles et importantes de l'architecture du système - est qu'il n'y a pas de réel motivation jusqu'à ce que la taille du système passe bien au-dessus de ce qui est raisonnable de présenter dans une "application jouet" ...! -)