Essayez de ne pas laisser la base de données effectuer trop d'opérations

La base de données est principalement utilisée pour le stockage. Nous devons éviter de laisser la base de données effectuer des opérations telles que l'écriture de tâches de minutage, de procédures stockées, etc. Les calculs complexes doivent être implémentés dans le code du programme. Nous devrions utiliser la base de données aussi simple que possible.

Contrôlez la quantité de données

Le volume de données d'une seule table par an ne contient généralement pas plus de 500W caractères, et nous avons besoin d'une table fractionnée raisonnable. Le tableau recommandé pour une seule bibliothèque est compris entre 300 et 400.

Nombre de champs dans une seule table

Les champs d'une seule table doivent être peu nombreux et raffinés, alors combien est approprié? Généralement, il y a 20 à 50 champs de table unique en ligne.

En développement, il faut faire attention à éviter d'utiliser de gros SQL, de grosses transactions.

Évitez d'utiliser des champs NULL

J'ai trouvé que de nombreuses chaussures pour enfants aiment que le champ par défaut soit NULL lors de la création de tables. Il est difficile d'optimiser la requête à l'aide de NULL. Si nous ajoutons un index à une colonne NULL, un espace supplémentaire est nécessaire et l'index contenant NULL n'est pas valide.

`a` char(32) DEFAULT NULL
`b` int(10) NOT NULL

Tels que ci-dessus.

Utilisez le TEXTE avec parcimonie

Nous pouvons utiliser VARCHAR au lieu de TEXT, car les performances de traitement de type TEXT sont inférieures à VARCHAR, TEXT forcera la génération de tables temporaires, perdant ainsi plus d'espace. Sous UTF-8, VARCHAR (65535) occupe environ 64 Ko d'espace.

Si vous devez l'utiliser, divisez-le dans un tableau séparé.

CREATE TABLE t1 (
    id INT NOT NULL AUTO_INCREMENT,
    data text NOT NULL,
    PRIMARY KEY (id)
) ENGINE=InnoDB;

À propos de l'index

Nombre d'index recommandé

Bien que l'index puisse améliorer la requête, si la colonne d'index est mise à jour fréquemment, la maintenance de l'index deviendra une charge. Si nous n'ajoutons pas d'index, essayez de ne pas l'ajouter, et il vaut mieux ne pas dépasser 20% du nombre de champs.

À propos des opérations de fonction

N'effectuez pas d'opérations mathématiques ou d'opérations de fonction sur la colonne d'index, car cela invaliderait l'index.

-- 不要这样用
select * from table WHERE to_days(current_date) – to_days(date_col) <= 10

-- 推荐使用
select * from table WHERE date_col >= DATE_SUB('2011-10-22',INTERVAL 10 DAY);

Colonne auto-incrémentée comme clé primaire

Les colonnes auto-incrémentées sont utilisées comme clé primaire, ce qui est propice à la maintenance de l'index, et la clé primaire ne doit pas être modifiée de manière triviale. N'utilisez pas de chaînes comme clés primaires, par exemple, n'utilisez pas d'UUID comme clés primaires.

Il est recommandé d'utiliser une colonne AUTO_INCREMENT indépendante de l'entreprise ou un générateur d'ID global comme clé primaire de substitution.

Nous savons que dans InnoDB, l'index de clé primaire est créé par défaut par la colonne de clé primaire, donc le problème vient.

"
Si aucune clé primaire n'est spécifiée, un index de clé primaire sera-t-il créé?
"

Minimiser l'utilisation de clés étrangères

Si des clés étrangères sont utilisées, un blocage est susceptible de se produire en cas de forte concurrence. Nous devons garantir les contraintes par le programme.

L'instruction SQL doit être simple

J'ai vu des centaines de lignes de SQL. Je pense que ce n'est pas bon. En général, un SQL ne peut être utilisé que sur un processeur, et un SQL volumineux peut planter la base de données.

Nous devrions diviser le gros SQL en plusieurs petits SQL simples. Le SQL simple augmentera le taux de succès du cache.

À propos des affaires

Nous devons faire de notre mieux pour placer les opérations qui n'ont rien à voir avec la transaction en dehors de la transaction, ce qui peut réduire l'occupation des ressources de verrouillage.

Utilisation simple

Nous utilisons le moins possible les procédures stockées et les déclencheurs, et utilisons les fonctions MySQL pour traiter le moins possible les résultats. Le calcul des données doit être laissé au programme.

À propos de l'efficacité SQL

Réécrire OR en IN ()

Dans le même champ, réécrire ou comme dans ()

OU efficacité: O (n)
IN efficacité: O (Log n)
Lorsque n est grand, OR sera beaucoup plus lent

Select * from table WHERE phone='12347856' or phone='42242233';

-- 推荐使用in
Select * from table WHERE phone in ('12347856' , '42242233')

Différents domaines, changement ou union

Select * from table WHERE phone='010-88886666' or cellPhone='13800138000';

-- 推荐使用 union
Select * from table WHERE phone='010-88886666'
union
Select * from table WHERE cellPhone='13800138000';

Utilisez UNION ALL au lieu de UNION

Il y aura une surcharge de déduplication lors de l'utilisation d'UNION.

À propos de JOIN

De nombreuses chaussures pour enfants aiment utiliser JOIN pour interroger les tables.Dans le manuel de développement d'Alibaba, il est recommandé de ne pas dépasser trois tables de JOIN.

Il est recommandé de diviser la table.

Select * from tag JOIN tag_post on tag_post.tag_id=tag.id JOIN post on  tag_post.post_id=post.id WHERE tag.tag='二手玩具';

Il est recommandé de faire ceci:

Select * from tag WHERE tag='二手玩具';
Select * from tag_post WHERE tag_id=1321;
Select * from post WHERE post.id in (123,456,314,141)

À propos des statistiques de comptage

Statistiques en temps réel: utilisez Memcache, mise à jour bidirectionnelle, benchmark exécuté tôt le matin
Statistiques non-temps réel: essayez d'utiliser un tableau de statistiques séparé et recalculez régulièrement

À propos de la pagination de limite

Nous pouvons généralement avoir écrit un tel SQL:

Select * from table limit 10000,10;

Mais ce sera très lent, plus le décalage est grand, plus le temps est lent.

Nous recommandons cette façon

select * from table WHERE id>=23434 limit 11;

Quelqu'un sur Internet a fait un test:

Ne pas afficher les verrous sur la base de données dans le terminal

"

Les verrous externes ne peuvent pas être contrôlés par la base de données

Catastrophe en cas de forte concurrence

Extrêmement difficile à déboguer et à dépanner

Recommandé dans le passé

Scannez le code QR pour devenir plus excitant. Ou recherchez Lvshen_9 sur WeChat , vous pouvez répondre pour obtenir des informations

1.回复"java" 获取java电子书；

2.回复"python"获取python电子书；

3.回复"算法"获取算法电子书；

4.回复"大数据"获取大数据电子书；

5.回复"spring"获取SpringBoot的学习视频。

6.回复"面试"获取一线大厂面试资料

7.回复"进阶之路"获取Java进阶之路的思维导图

8.回复"手册"获取阿里巴巴Java开发手册(嵩山终极版)

9.回复"总结"获取Java后端面试经验总结PDF版

10.回复"Redis"获取Redis命令手册，和Redis专项面试习题（PDF）

11.回复"并发导图"获取Java并发编程思维导图（xmind终极版）

Autre: cliquez sur [ Mes avantages ] pour avoir plus de surprises.

Une certaine expérience du DBA de l'entreprise sur le développement MySQL