1. Partagez une petite astuce :
Lors de la définition du type de données, s'il est déterminé qu'il s'agit d'un entier, utilisez INT ; s'il s'agit d'un nombre décimal, utilisez le type à virgule fixe DECIMAL ; s'il s'agit d'une chaîne, tant qu'il ne s'agit pas d'une clé primaire, utilisez TEXT ; s'il s'agit d'une date et d'une heure, utilisez DATETIME
2. Après avoir exécuté cette instruction, une table vide demo.importheadhist avec la même structure de table que demo.importhead est créée.
CREATE TABLE demo.importheadhist
LIKE demo.importhead;
3.
CREATE TABLE
(
字段名 字段类型 PRIMARY KEY
);
CREATE TABLE
(
字段名 字段类型 NOT NULL
);
CREATE TABLE
(
字段名 字段类型 UNIQUE
);
CREATE TABLE
(
字段名 字段类型 DEFAULT 值
);
-- 这里要注意自增类型的条件,字段类型必须是整数类型。
CREATE TABLE
(
字段名 字段类型 AUTO_INCREMENT
);
-- 在一个已经存在的表基础上,创建一个新表
CREATE TABLE demo.importheadhist LIKE demo.importhead;
-- 修改表的相关语句
ALTER TABLE 表名 CHANGE 旧字段名 新字段名 数据类型;
ALTER TABLE 表名 ADD COLUMN 字段名 字段类型 FIRST|AFTER 字段名;
ALTER TABLE 表名 MODIFY 字段名 字段类型 FIRST|AFTER 字段名;
4. Spécifiez le moteur de stockage
ALTER TABLE 表名 ENGINE=INNODB;
5. Veuillez écrire une instruction SQL pour modifier le champ "salesprice" dans la table demo.goodsmaster afin qu'il soit non répétable et non vide.
ALTER TABLE demo.goodsmaster
CHANGE COLUMN salesprice salesprice DECIMAL(10,2) NOT NULL UNIQUE;
6. La structure syntaxique de l'instruction de requête :
SELECT *|字段列表
FROM 数据源
WHERE 条件
GROUP BY 字段
HAVING 条件
ORDER BY 字段
LIMIT 起始点,行数
7.
INSERT INTO 表名 [(字段名 [,字段名] ...)] VALUES (值的列表);
INSERT INTO 表名 (字段名)
SELECT 字段名或值
FROM 表名
WHERE 条件
DELETE FROM 表名
WHERE 条件
UPDATE 表名
SET 字段名=值
WHERE 条件
SELECT *|字段列表
FROM 数据源
WHERE 条件
GROUP BY 字段
HAVING 条件
ORDER BY 字段
LIMIT 起始点,行数
8. Supposons que l'utilisateur dispose de 2 magasins indépendants, chacun avec son propre système. Il est maintenant nécessaire d'introduire un modèle d'exploitation en chaîne pour gérer les deux magasins dans un seul système. Ensuite, le premier problème rencontré est le besoin d'intégration des données. Prenons l'exemple de la table d'informations sur les produits pour illustrer comment intégrer les données d'informations sur les produits de deux magasins en utilisant le mot-clé "ON DUPLICATE".
En supposant que la table d'informations sur les produits du magasin A est "demo.goodsmaster", le code est le suivant :
mysql> SELECT *
-> FROM demo.goodsmaster;
+------------+---------+-----------+---------------+------+------------+
| itemnumber | barcode | goodsname | specification | unit | salesprice |
+------------+---------+-----------+---------------+------+------------+
| 1 | 0001 | 书 | 16开 | 本 | 89.00 |
| 2 | 0002 | 笔 | 10支装 | 包 | 5.00 |
| 3 | 0003 | 橡皮 | NULL | 个 | 3.00 |
+------------+---------+-----------+---------------+------+------------+
3 rows in set (0.00 sec)
La table d'informations sur les produits du magasin B est "demo.goodsmaster1":
mysql> SELECT *
-> FROM demo.goodsmaster1;
+------------+---------+-----------+---------------+------+------------+
| itemnumber | barcode | goodsname | specification | unit | salesprice |
+------------+---------+-----------+---------------+------+------------+
| 1 | 0001 | 教科书 | NULL | NULL | 89.00 |
| 4 | 0004 | 馒头 | | | 1.50 |
+------------+---------+-----------+---------------+------+------------+
2 rows in set (0.00 sec)
Supposons que nous voulions insérer les données produit du magasin B dans la table des produits du magasin A. S'il y a des numéros de produits en double, remplacez le code-barres du magasin A par le code-barres du magasin B et remplacez le magasin A par le nom du produit du magasin B S'il n'y a pas de numéro répété, insérez directement les données produit du magasin B dans la table des produits du magasin A. Cette opération peut être réalisée avec l'instruction SQL suivante :
INSERT INTO demo.goodsmaster
SELECT *
FROM demo.goodsmaster1 as a
ON DUPLICATE KEY UPDATE barcode = a.barcode,goodsname=a.goodsname;
-- 运行结果如下
mysql> SELECT *
-> FROM demo.goodsmaster;
+------------+---------+-----------+---------------+------+------------+
| itemnumber | barcode | goodsname | specification | unit | salesprice |
+------------+---------+-----------+---------------+------+------------+
| 1 | 0001 | 教科书 | 16开 | 本 | 89.00 |
| 2 | 0002 | 笔 | 10支装 | 包 | 5.00 |
| 3 | 0003 | 橡皮 | NULL | 个 | 3.00 |
| 4 | 0004 | 馒头 | | | 1.50 |
+------------+---------+-----------+---------------+------+------------+
4 rows in set (0.00 sec)
9. J'aimerais vous demander de réfléchir à une question : dans la table des marchandises demo.goodsmaster, le champ "numéro d'article" est la clé primaire, et il satisfait la contrainte d'auto-incrémentation. Si je supprime un enregistrement et que j'insère les données encore une fois, le champ « numéro d'article » apparaîtra. La valeur n'est pas continue. Pensez-y, comment insérer des données pour éviter que cela ne se produise ?
Réponse : Lorsque vous ajoutez des enregistrements dans la table des marchandises, vous pouvez juger. Si vous constatez que le numéro d'article n'est pas continu, vous pouvez insérer les données en spécifiant explicitement la valeur du numéro d'article, au lieu d'omettre le numéro d'article et de le laisser s'incrémenter automatiquement.
ALTER TABLE demo.goodsmaster AUTO_INCREMENT=Valeur du point d'arrêt
10. Si je souhaite modifier le prix de tous les produits dont l'unité est "package" dans le débitmètre de vente demo.trans à 80% du prix d'origine, comment puis-je faire ?
UPDATE demo.trans AS a, demo.goodsmaster AS b SET price = price * 0.8 WHERE a.itemnumber = b.itemnumber AND b.unit = '包'
11. Contraintes de clé étrangère et requêtes d'association
-- 定义外键约束:
CREATE TABLE 从表名
(
字段 字段类型
....
CONSTRAINT 外键约束名称
FOREIGN KEY (字段名) REFERENCES 主表名 (字段名称)
);
ALTER TABLE 从表名 ADD CONSTRAINT 约束名 FOREIGN KEY 字段名 REFERENCES 主表名 (字段名);
-- 连接查询
SELECT 字段名
FROM 表名 AS a
JOIN 表名 AS b
ON (a.字段名称=b.字段名称);
SELECT 字段名
FROM 表名 AS a
LEFT JOIN 表名 AS b
ON (a.字段名称=b.字段名称);
SELECT 字段名
FROM 表名 AS a
RIGHT JOIN 表名 AS b
ON (a.字段名称=b.字段名称);
12. Si votre scénario d'entreprise ne peut pas utiliser de contraintes de clé étrangère en raison d'une concurrence élevée et d'autres raisons, dans ce cas, comment assurez-vous la cohérence des données au niveau de l'application ?
Si les contraintes de clé étrangère ne peuvent pas être utilisées, vous pouvez ajouter un module fonctionnel à la couche application pour assurer l'intégrité des données. Par exemple, lors de la suppression d'un enregistrement dans la table principale, ajoutez une fonction pour vérifier si l'enregistrement est appliqué dans la table esclave. S'il est appliqué, il n'est pas permis de supprimer .
13. Étant donné que HAVING ne peut pas être utilisé seul, il doit être utilisé avec GROUP BY. GROUP BY est compris comme un regroupement de données, ce qui nous permet d'effectuer des calculs statistiques sur les données du groupe.
14.La différence entre avoir et où :
La première différence est que si vous avez besoin d'obtenir les données requises à partir de la table associée via une jointure, WHERE consiste à filtrer d'abord, puis à joindre, et HAVING à se connecter d'abord, puis à filtrer. Ce point détermine que WHERE est plus efficace que HAVING dans les requêtes relationnelles. Étant donné que WHERE peut être filtré en premier et connecté à un petit ensemble de données filtrées et à la table associée , il utilise moins de ressources et l'efficacité d'exécution est relativement élevée . HAVING doit d'abord préparer le jeu de résultats, c'est-à-dire utiliser le jeu de données non filtré à associer, puis filtrer ce grand jeu de données, qui consomme plus de ressources et réduit l'efficacité de l'exécution.
La deuxième différence est que WHERE peut utiliser directement les champs de la table comme conditions de filtre, mais ne peut pas utiliser les fonctions de calcul dans le regroupement comme conditions de filtre ; HAVING doit être utilisé conjointement avec GROUP BY, qui peut utiliser les fonctions de calcul de regroupement et les champs de regroupement comme conditions de filtrage. état. Lorsque les données doivent être regroupées pour les statistiques, HAVING peut effectuer des tâches que WHERE ne peut pas.
15. Il y a un tel dicton : la condition après HAVING doit être la condition qui contient la fonction de calcul dans le groupement, pensez-vous que c'est juste ? Pourquoi?
La condition après HAVING doit être la condition qui contient la fonction de calcul dans le groupe. Cette déclaration est logique, compte tenu principalement de l'efficacité de la requête. Parce que si ce n'est pas la condition de la fonction de calcul dans le regroupement, alors cette condition devrait pouvoir utiliser WHERE au lieu de HAVING, et l'efficacité de la requête n'est pas élevée.
16. Les transactions ont 4 caractéristiques principales, à savoir l'atomicité, la cohérence, la durabilité et l'isolement.
Atomicité : cela signifie que les opérations de la transaction sont soit toutes exécutées, soit pas toutes exécutées, comme un tout, et ne peuvent pas être interrompues par le milieu.
Cohérence : Indique que l'intégrité des données ne sera pas détruite par l'exécution de la transaction.
Isolation : Cela signifie que lorsque plusieurs transactions sont exécutées en même temps, elles n'interfèrent pas les unes avec les autres. Différents niveaux d'isolement ont différents degrés d'indépendance les uns par rapport aux autres.
Persistance : Cela signifie que la modification des données par la transaction est permanente et effective, et n'échouera pas en raison d'une défaillance du système.
Grâce à l'utilisation de verrous, les transactions peuvent être isolées les unes des autres. Les serrures sont utilisées différemment et ont différents degrés d'isolement.
17.MySQL prend en charge 4 niveaux d'isolation des transactions.
READ UNCOMMITTED : vous pouvez lire les données modifiées qui n'ont pas été validées dans la transaction.
READ COMMITTED : seules les données modifiées qui ont été validées dans la transaction peuvent être lues.
REPEATABLE READ : Indique que dans une transaction, la valeur d'une donnée lue est toujours la même que la valeur lue pour la première fois et n'est pas affectée par les opérations de données dans d'autres transactions. C'est également l'option par défaut pour MySQL.
SERIALIZABLE : Indique que toute transaction, une fois qu'une opération est effectuée sur certaines données, MySQL verrouillera les données jusqu'à la fin de la transaction, interdisant aux autres transactions d'effectuer des opérations sur les données.
Une transaction peut garantir qu'une série d'opérations dans la transaction sont toutes exécutées sans être interrompues ; ou toutes ne sont pas exécutées, attendant d'être exécutées à nouveau. Les opérations dans une transaction sont caractérisées par l'atomicité, la cohérence, la persistance et l'isolement. Mais cela ne signifie pas qu'une série d'opérations de données DML enveloppées dans des transactions réussiront toutes ou échoueront toutes. Vous devez juger si l'opération a réussi ou non, et notifier à MySQL de terminer l'opération de validation ou d'annulation de la transaction pour différentes situations, afin de garantir enfin que toutes les opérations de la transaction réussissent ou échouent. MySQL prend en charge 4 niveaux d'isolation de transaction différents. Plus le niveau est élevé, plus les ressources système sont consommées. Vous devez le définir en fonction de la situation réelle. Dans MySQL, toutes les opérations ne peuvent pas être annulées. Comme la création d'une base de données, la création d'une table de données, la suppression d'une base de données, la suppression d'une table de données, etc., ces opérations ne peuvent pas être annulées, vous devez donc être très prudent lors de l'utilisation, en particulier lors de la suppression d'une base de données ou d'une table de données, il est préférable de le faire d'abord Sauvegarder pour éviter les abus.
18. Une transaction consiste à s'assurer que les opérations de données dans la transaction sont exécutées correctement ou échouent toutes. Pensez-vous que cette phrase est correcte ? Pourquoi?
Cette instruction est erronée. Les transactions garantiront que toutes les opérations du traitement des transactions sont exécutées ou non. Si une erreur survient lors de l'exécution, la poursuite ou l'annulation doit être gérée par le programmeur.
19. Une vue est une table virtuelle. Nous pouvons stocker une instruction de requête en tant que vue dans la base de données. Si nécessaire, nous pouvons traiter la vue comme une table et interroger les données qu'elle contient.
20.
Que doit contenir un document de conception de base de données complet ?
Réponse de l'auteur : D'une manière générale, cela devrait inclure l'analyse des exigences, la modélisation (ER), la conception logique (telle que la création de bases de données et la création de tables), la conception physique (telle que l'indexation), la mise en œuvre, l'exploitation et la maintenance (reprise après sinistre et sauvegarde), etc. Selon les besoins réels, peut être encore affiné
21. Lorsque nous développons des applications, nous rencontrons souvent un besoin de regrouper les données horizontalement et verticalement selon les différents utilisateurs. Le groupement dit horizontal fait référence à la gamme de données auxquelles l'utilisateur peut accéder, comme les données des tableaux qui peuvent être vues ; le groupement dit vertical fait référence à la mesure dans laquelle l'utilisateur peut accéder aux données, comme la capacité pour afficher et modifier les données. , ou même supprimer.
22. Le rôle est une nouvelle fonctionnalité introduite dans MySQL 8.0, qui équivaut à une collection d'autorisations
23. Il existe deux types de sauvegarde de données MySQL, l'une est la sauvegarde physique, qui réalise l'objectif de sauvegarde en copiant les fichiers de données, l'autre est la sauvegarde logique, qui réalise la sauvegarde en sauvegardant les informations décrivant la structure et le contenu de la base de données. . Cette méthode de sauvegarde logique est gratuite et largement utilisée.
Tout d'abord, apprenons l'outil mysqldump pour la sauvegarde des données. Il dispose de trois modes au total : sauvegarde des tables dans la base de données ; sauvegarde de l'intégralité de la base de données ; sauvegarde de l'intégralité du serveur de base de données.
24. Requis par la première forme normale : tous les champs sont des champs de données de base et ne peuvent pas être divisés davantage.
La deuxième forme normale exige que, sur la base de la satisfaction de la première forme normale, chaque enregistrement de données dans la table de données soit identifiable de manière unique. Et tous les champs doivent entièrement dépendre de la clé primaire, pas seulement une partie de la clé primaire.
Nous avons divisé le tableau de données d'origine en trois tableaux de données conformément aux exigences de la deuxième forme normale.
La troisième forme normale exige que la table de données ne contienne pas de champs qui peuvent être dérivés de champs de clé non primaire sur la base de la satisfaction de la deuxième forme normale, ou, en d'autres termes, il ne peut pas y avoir de champs qui dépendent de clé non primaire des champs.
25. Alors, comment faire la distinction entre entités et attributs ? Je vous propose un principe : il faut le regarder du point de vue du système dans son ensemble : ce qui peut exister indépendamment est une entité, et ce qui est inséparable est un attribut. Autrement dit, les attributs ne nécessitent pas de description supplémentaire et ne peuvent pas contenir d'autres attributs.
26. Comment convertir le diagramme du modèle ER en tableau de données ? En dessinant le modèle ER, nous avons clarifié la logique métier.Maintenant, nous allons franchir une étape très importante : convertir le modèle ER dessiné en une table de données spécifique. Permettez-moi d'introduire le principe de la conversion. Une entité est généralement convertie en une table de données ; une relation plusieurs à plusieurs est généralement convertie en une table de données ; une relation 1 à 1 ou 1 à plusieurs est souvent exprimée via la clé étrangère de la table, plutôt que de concevoir une nouvelle table de données, les attributs sont convertis en champs de table. Eh bien, laissez-moi vous expliquer comment utiliser ces principes de conversion en combinaison avec le tableau précédent pour convertir le modèle ER en un tableau de données spécifique, afin d'implémenter le modèle de données abstrait dans la conception de base de données spécifique.
27. J'ai introduit plusieurs méthodes pour améliorer les performances des requêtes du point de vue de la conception : modifier les types de données pour économiser de l'espace de stockage ; ajouter des champs redondants lorsque les avantages l'emportent sur les inconvénients ; modifier les champs et les fréquences de requête qui sont fréquemment interrogés dans les grandes tables. champs bas dans des tables séparées ; essayez d'utiliser des contraintes non nulles. Tous ces éléments peuvent vous aider à améliorer encore l'efficacité des requêtes du système et à rendre les applications que vous développez plus concises et efficaces.
28. MySQL sait ce que vous voulez faire via l'analyseur et comment le faire via l'optimiseur, il entre donc dans la phase d'exécuteur
et commence à exécuter l'instruction.