Comment diviser des tables dans MySQL

Lorsqu'une donnée atteint des millions, le temps nécessaire à une requête augmente. S'il y a une requête conjointe, je pense qu'elle peut mourir là. Le but du partitionnement des tables est de réduire la charge sur la base de données et de raccourcir le temps de requête.

Sous-table

1, faites le cluster mysql. Par exemple : utiliser un cluster mysql, un proxy mysql, une réplication mysql, drdb, etc.

Certaines personnes peuvent se demander si le cluster mysql a quelque chose à voir avec les sous-tables ? Bien qu'il ne s'agisse pas d'un sous-tableau au sens propre du terme, il joue le rôle d'un sous-tableau. Que signifie être un cluster ? Pour parler franchement, réduire la charge sur une base de données signifie réduire le nombre de SQL dans la file d’attente SQL.

Par exemple : Il y a 10 requêtes sql. Si elles sont placées dans la file d'attente d'un serveur de base de données, elles devront attendre longtemps si ces 10 requêtes sql sont allouées aux files d'attente de 5 bases de données. serveurs Dans la file d'attente, il n'y a que 2 files d'attente dans un serveur de base de données. Le temps d'attente sera-t-il considérablement réduit ? C'est déjà une évidence.

Avantages : Bonne scalabilité, pas d'opérations complexes (code php) après plusieurs sous-tables

Inconvénients : La quantité de données dans une seule table n'a pas changé, et le temps passé sur une opération est toujours le même. Beaucoup, la surcharge matérielle est importante.

2. On estime à l'avance qu'il y aura des tableaux avec de grandes quantités de données et fréquemment consultés. Divisez-les en plusieurs tableaux

Ce genre d'estimation est joli. c'est la même chose, forum Le tableau dans lequel les messages sont publiés deviendra certainement très volumineux avec le temps, peut-être des centaines de milliers, voire des millions. Dans le tableau d'informations du salon de discussion, des dizaines de personnes ont discuté ensemble pendant une nuit entière. Après une longue période, les données de ce tableau doivent être très volumineuses. Il existe de nombreuses situations comme celle-ci. Par conséquent, pour ce type d'échelle de big data qui peut être estimée, nous la divisons à l'avance en N tableaux. Le nombre de N dépend de la situation réelle.

Avantages : Éviter des millions de données dans une table, raccourcir le temps d'exécution d'un SQL

Inconvénients : Lorsqu'une règle est déterminée, il sera très difficile de la briser. Problème , l'algorithme de hachage que j'ai utilisé dans l'exemple ci-dessus est crc32. Si je ne souhaite pas utiliser cet algorithme maintenant, le passage à md5 entraînera le stockage des messages du même utilisateur dans différentes tables, donc les données seront gâchées. L'évolutivité est médiocre.

3. Utilisez le moteur de stockage de fusion pour implémenter des sous-tables

Je pense que cette méthode est plus adaptée à celles qui sont déjà apparues sans considération préalable, les données. la requête est une situation lente. À l'heure actuelle, il est plus pénible de séparer les échelles Big Data existantes. Le plus pénible est de modifier le code, car les instructions SQL du programme ont déjà été écrites. Désormais, une table doit être divisée en dizaines de tables, voire en centaines de tables. Cela signifie-t-il que l'instruction SQL doit être réécrite ? Par exemple, j'aime utiliser

mysql>show moteurs et vous constaterez que mrg_myisam est en fait une fusion.

mysql> CREATE TABLE IF NOT EXISTS `user1` (  
->   `id` int(11) NOT NULL AUTO_INCREMENT,  
->   `name` varchar(50) DEFAULT NULL,  
->   `sex` int(1) NOT NULL DEFAULT '0',  
->   PRIMARY KEY (`id`)  
-> ) ENGINE=MyISAM  DEFAULT CHARSET=utf8 AUTO_INCREMENT=1 ;  
Query OK, 0 rows affected (0.05 sec)  
 
mysql> CREATE TABLE IF NOT EXISTS `user2` (  
->   `id` int(11) NOT NULL AUTO_INCREMENT,  
->   `name` varchar(50) DEFAULT NULL,  
->   `sex` int(1) NOT NULL DEFAULT '0',  
->   PRIMARY KEY (`id`)  
-> ) ENGINE=MyISAM  DEFAULT CHARSET=utf8 AUTO_INCREMENT=1 ;  
Query OK, 0 rows affected (0.01 sec)  
 
mysql> INSERT INTO `user1` (`name`, `sex`) VALUES('张映', 0);  
Query OK, 1 row affected (0.00 sec)  
 
mysql> INSERT INTO `user2` (`name`, `sex`) VALUES('tank', 1);  
Query OK, 1 row affected (0.00 sec)  
 
mysql> CREATE TABLE IF NOT EXISTS `alluser` (  
->   `id` int(11) NOT NULL AUTO_INCREMENT,  
->   `name` varchar(50) DEFAULT NULL,  
->   `sex` int(1) NOT NULL DEFAULT '0',  
->   INDEX(id)  
-> ) TYPE=MERGE UNION=(user1,user2) INSERT_METHOD=LAST AUTO_INCREMENT=1 ;  
Query OK, 0 rows affected, 1 warning (0.00 sec)  
 
mysql> select id,name,sex from alluser;  
+----+--------+-----+  
| id | name   | sex |  
+----+--------+-----+  
|  1 | 张映 |   0 |  
|  1 | tank   |   1 |  
+----+--------+-----+  
2 rows in set (0.00 sec)  
 
mysql> INSERT INTO `alluser` (`name`, `sex`) VALUES('tank2', 0);  
Query OK, 1 row affected (0.00 sec)  
 
mysql> select id,name,sex from user2  
-> ;  
+----+-------+-----+  
| id | name  | sex |  
+----+-------+-----+  
|  1 | tank  |   1 |  
|  2 | tank2 |   0 |  
+----+-------+-----+  
2 rows in set (0.00 sec)

Avantages : Bonne évolutivité et le code du programme ne change pas beaucoup

Inconvénients : L'effet de cette méthode est légèrement pire que la seconde

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!