Dans les premiers travaux, la conception n'était pas suffisante. À l'heure actuelle, les données de la table d'enregistrements sont de 2 000 W et il n'y a pas d'index efficace.
Dans l'activité actuelle, il y aura plus d'opérations d'écriture que d'opérations de lecture, et de temps en temps, nous rencontrerons trop de connexions de données occupées par un SQL lent, ce qui empêchera les opérations d'écriture de se dérouler normalement. Comme la table d'enregistrement contient des données évidentes à chaud et à froid, envisagez d'utiliser la table de partition de données pour résoudre le problème des opérations de lecture lente
Voici un enregistrement de la résolution des problèmes:
1 Données chaudes séparées
Partitionnez la table d'enregistrement pour restreindre la portée du filtrage des données.
Ici, je choisis le champ de temps create_time [TIMESTAMP]
ALTER TABLE record PARTITION by RANGE(UNIX_TIMESTAMP(create_time))
(
PARTITION p1 VALUES LESS THAN ( UNIX_TIMESTAMP('2020-01-01 00:00:00') ),
PARTITION p2 VALUES LESS THAN ( UNIX_TIMESTAMP('2020-02-01 00:00:00') ),
PARTITION p3 VALUES LESS THAN ( UNIX_TIMESTAMP('2020-03-01 00:00:00') ),
PARTITION p4 VALUES LESS THAN ( UNIX_TIMESTAMP('2020-04-01 00:00:00') ),
PARTITION p5 VALUES LESS THAN ( UNIX_TIMESTAMP('2020-05-01 00:00:00') ),
PARTITION p6 VALUES LESS THAN ( UNIX_TIMESTAMP('2020-06-01 00:00:00') ),
PARTITION p7 VALUES LESS THAN ( UNIX_TIMESTAMP('2020-07-01 00:00:00') ),
PARTITION p8 VALUES LESS THAN ( UNIX_TIMESTAMP('2020-08-01 00:00:00') ),
PARTITION p9 VALUES LESS THAN ( UNIX_TIMESTAMP('2020-09-01 00:00:00') ),
PARTITION p10 VALUES LESS THAN (UNIX_TIMESTAMP('2020-10-01 00:00:00') )
)
Voici quelques erreurs courantes
- Une CLÉ PRIMAIRE doit inclure toutes les colonnes dans la fonction de partitionnement de la table
- Un INDEX UNIQUE doit inclure toutes les colonnes dans la fonction de partitionnement de la table
Cela signifie que chaque index unique sur la table doit être sur l'expression de la table de partition. Si je choisis create_time comme champ de partition, ce champ doit être un index unique. [CLÉ PRIMAIRE ou INDEX UNIQUE]
Supprimez donc la CLÉ PRIMAIRE d'origine [identifiant de clé primaire] pour établir une clé primaire commune
ALTER TABLE record DROP PRIMARY KEY, ADD PRIMARY KEY(id,create_time);
Utilisez la commande suivante pour afficher le nombre d'enregistrements dans chaque partition
SELECT PARTITION_NAME,TABLE_ROWS FROM INFORMATION_SCHEMA.PARTITIONS WHERE TABLE_NAME = 'record';
Analysez SQL pour déterminer si la requête distingue les partitions
EXPLAIN PARTITIONS SELECT id,create_time FROM table_name WHERE create_time> '2020-03-01 00:00:00' AND create_time< NOW()
La requête peut distinguer les partitions, et non plus la requête de table complète, et l'objectif initial d'optimisation est atteint.
2 Optimiser l'efficacité des requêtes
Les affaires impliquent des opérations de pagination, la syntaxe de pagination la plus courante inclut 2 SQL
- Obtenez le nombre total d'enregistrements
SELECT COUNT(*) - Paginer les enregistrements
SELECT * FROM table_name WHERE xxxxxxx LIMIT n , m
Après avoir utilisé la table de partition, il ne fait que réduire la plage de filtrage des données [la table de données de 2000 W utilise uniquement la partition des 2 derniers mois, le volume de données est réduit à 300 W] et l'efficacité de la requête est augmentée de 70% [45 s -> 15 s] La requête prend 10 s Ce qui précède ne résout pas complètement le problème
2.1 Choisissez le bon moteur de stockage
Sous le moteur de stockage InnoDB, COUNT (*) et LIMIT deviennent extrêmement chronophages à mesure que les données de la table augmentent.
Le moteur MYISAM est très rapide, mais le moteur ne prend pas en charge les verrous au niveau des lignes. L'opération de lecture est un verrou partagé, l'opération d'écriture est un verrou exclusif et prend en charge les insertions simultanées. En cas de pression d'écriture excessive, vous pouvez rencontrer une situation de verrouillage de table. .
Utiliser InnoDB dans le cadre d'une étude approfondie
2.2 Ajustement SQL et métier
J'ai fait des compromis dans les affaires, supprimé la dernière page de la pagination et entré un numéro de page personnalisé, ne laissant que la page de haut en bas et les dernières pages à sauter. [Reportez-vous à la page 58 Même ville]
Ceci est quelque peu similaire à la requête de curseur [défilement] dans ES. Les extrémités avant et arrière sont terminées. La requête page par page doit savoir que le curseur actuel est l'ID de clé primaire, la page précédente et la taille de page suivante.
SELECT * FROM table_name WHERE id > scroll and id < scroll + pageSize
J'ai également vu une autre solution d'optimisation SQL, qui ne doit être complétée que par le back-end, et l'efficacité est relativement faible. Il y a un problème de limite trop grande
SELECT * FROM table_name where id >= (SELECT id FROM table_name LIMIT (pageNo-1) * pageSize, 1) LIMIT pageSize
2.3 Ajustement de l'indice
Chaque partition de la table partitionnée est indexée et stockée indépendamment. La table d'enregistrement se rapporte à la requête et le champ de requête est indexé.
Ajouter un index de nom d'enregistrement: CREATE INDEX nom_index ON nom_table (champ_table)
requête finale SQL: SELECT id, nom, create_time FROM nom_table WHERE table_field comme 'xxxx%' AND create_time> '2020-03-01 00:00:00' AND create_time <NOW ()
analyse SQL: en utilisant Explain, il a été constaté que la requête d'index d'index et le temps de pagination passé entre 0,01-0,04, répondent essentiellement aux exigences.
Ce qui précède est l'optimisation de grandes tables de base de données à l'aide de tables partitionnées. Il existe également des compromis et des limitations commerciales. Par exemple, pour atteindre l'index comme une requête, la requête doit être mise en correspondance d'avant en arrière et la pagination ne peut pas accéder à la page spécifiée.
Si vous ne voulez pas faire de compromis sur les affaires, vous pouvez utiliser ES pour la pagination, la base de données pour les requêtes de base ou utiliser Sphinx pour la recherche en texte intégral.
La complexité du développement commercial, l'exactitude des données et la rapidité des trois ne sont généralement que deux. Dans différentes situations commerciales, faites des choix différents, le bienveillant voit le bienveillant voit la sagesse.