Mit der Weiterentwicklung der Technologie stellen Interviewer immer höhere Anforderungen an die Interviewpartner. Solange es sich nun um eine Back-End-Entwicklungsposition handelt, wird das Interview definitiv Fragen Sie nach relevantem Datenbankwissen, und MySQL ist derzeit die beliebteste kostenlose relationale Datenbankverwaltungstechnologie. Es ist nicht überraschend, dass in Interviews Fragen dazu gestellt werden. Deshalb haben wir nun einige Interviewfragen und Antworten für Sie zusammengestellt. Werfen wir einen Blick darauf.
Empfohlenes Tutorial: MySQL-Einführungsvideo
1. Primärschlüssel-Superschlüssel-Kandidatenschlüssel-Fremdschlüssel
Primärschlüssel:
Paare gespeichert in Datenbanktabellen Eine Kombination aus Datenspalten oder Attributen, die ein Datenobjekt eindeutig und vollständig identifiziert. Eine Datenspalte kann nur einen Primärschlüssel haben und der Wert des Primärschlüssels darf nicht fehlen, d. h. er darf nicht null sein.
Superschlüssel:
Der Satz von Attributen, der ein Tupel in einer Beziehung eindeutig identifizieren kann, wird Super genannt Schlüssel des relationalen Musterschlüssels. Ein Attribut kann als Superschlüssel verwendet werden, und auch die Kombination mehrerer Attribute kann als Superschlüssel verwendet werden. Der Superschlüssel enthält den Kandidatenschlüssel und den Primärschlüssel.
Kandidatenschlüssel:
ist der minimale Superschlüssel, also ein Superschlüssel ohne redundante Elemente.
Fremdschlüssel:
Der Primärschlüssel einer anderen Tabelle, der in einer Tabelle vorhanden ist, wird als Fremdschlüssel von bezeichnet dieser Tisch.
Vier Merkmale und Bedeutungen von Datenbanktransaktionen
Vier Grundelemente für die korrekte Ausführung von Datenbanktransaktionen . SÄURE, Atomarität, Korrespondenz, Isolation, Haltbarkeit.
Atomizität: Alle Vorgänge in der gesamten Transaktion sind entweder abgeschlossen oder nicht abgeschlossen, und es ist unmöglich, in einer Zwischenverbindung zu stagnieren. Wenn während der Ausführung der Transaktion ein Fehler auftritt, wird sie auf den Zustand vor Beginn der Transaktion zurückgesetzt, als ob die Transaktion nie ausgeführt worden wäre.
Konsistenz: Die Integritätsbeschränkungen der Datenbank werden vor Beginn der Transaktion und nach Ende der Transaktion nicht verletzt.
Isolation: Der Isolationszustand führt Transaktionen so aus, dass sie scheinbar die einzigen Vorgänge sind, die das System zu einem bestimmten Zeitpunkt ausführt. Wenn zwei Transaktionen gleichzeitig ausgeführt werden und dieselbe Funktion ausführen, stellt die Transaktionsisolation sicher, dass jede Transaktion im System denkt, dass nur diese Transaktion das System verwendet. Diese Eigenschaft wird manchmal als Serialisierung bezeichnet. Um Verwechslungen zwischen Transaktionsvorgängen zu vermeiden, müssen Anforderungen serialisiert oder deserialisiert werden, sodass jeweils nur eine Anforderung für dieselben Daten vorliegt.
Persistenz: Nach Abschluss der Transaktion werden die durch die Transaktion an der Datenbank vorgenommenen Änderungen dauerhaft in der Datenbank gespeichert und nicht gespeichert zurückgerollt werden.
3. Die Rolle der Ansicht kann geändert werden.
Eine Ansicht ist eine virtuelle Tabelle, die Daten enthält. Eine Ansicht enthält nur Abfragen, die bei Verwendung dynamisch Daten abrufen. Durch die Verwendung von Ansichten können komplexe SQL-Vorgänge vereinfacht, bestimmte Details ausgeblendet und Daten geschützt werden. Sobald Ansichten erstellt wurden, können sie auf die gleiche Weise wie Tabellen verwendet werden.
Die Ansicht kann weder indiziert werden, noch können ihr Trigger oder Standardwerte zugeordnet werden. Wenn in der Ansicht selbst „Ordnung nach“ vorhanden ist, wird die Reihenfolge in der Ansicht erneut überschrieben.
Erstellen Sie eine Ansicht: Erstellen Sie die Ansicht XXX als XXXXXXXXXXXXXX. Sie kann aktualisiert werden, und Aktualisierungen der Ansicht aktualisieren die Basistabelle. Die Ansicht wird jedoch hauptsächlich zum Vereinfachen des Abrufens und zum Schutz verwendet Daten, nicht zur Aktualisierung, und die meisten Ansichten können nicht aktualisiert werden.
4. Der Unterschied zwischen „Drop“, „Delete“ und „Truncate“
„Drop“ löscht die Tabelle direkt und „Truncate“ löscht die Daten Beim erneuten Einfügen erhöht sich die ID automatisch und der Löschvorgang beginnt bei 1, um die Daten in der Tabelle zu löschen.
(1) Der Löschvorgang durch die DELETE-Anweisung besteht darin, jeweils eine Zeile aus der Tabelle zu löschen und gleichzeitig den Löschvorgang der Zeile im Protokoll als Transaktionsdatensatz zu speichern für den Rollback-Vorgang. TRUNCATE TABLE löscht alle Daten auf einmal aus der Tabelle und zeichnet einzelne Löschvorgangsdatensätze nicht im Protokoll auf. Gelöschte Zeilen können nicht wiederhergestellt werden. Und der Löschauslöser für die Tabelle wird während des Löschvorgangs nicht aktiviert. Die Ausführungsgeschwindigkeit ist hoch.
(2) Der von Tabellen und Indizes belegte Platz. Wenn eine Tabelle TRUNCATE ist, wird der von der Tabelle und den Indizes belegte Speicherplatz auf die ursprüngliche Größe zurückgesetzt, und der DELETE-Vorgang verringert nicht den von der Tabelle oder den Indizes belegten Speicherplatz. Die Drop-Anweisung gibt den gesamten von der Tabelle belegten Speicherplatz frei.
(3) Generell gilt: Löschen > abschneiden > löschen
(4) Anwendungsbereich. TRUNCATE kann nur für TABLE verwendet werden; DELETE kann für Tabelle und Ansicht verwendet werden
(5) TRUNCATE und DELETE löschen nur Daten, während DROP die gesamte Tabelle (Struktur und Daten) löscht.
(6) Abschneiden und Löschen ohne Wo: Nur die Daten löschen, nicht die Struktur (Definition) der Tabelle. Die Drop-Anweisung löscht die Einschränkungen (Einschränkungen), für die die Struktur gilt von der Tabelle abhängig, Triggerindex (Index); die von der Tabelle abhängigen gespeicherten Prozeduren/Funktionen bleiben erhalten, ihr Status wird jedoch: ungültig.
(7) Die Löschanweisung ist DML (Datenpflegesprache). Dieser Vorgang wird im Rollback-Segment platziert und wird erst wirksam, nachdem die Transaktion übermittelt wurde. Wenn ein entsprechender Tigger vorhanden ist, wird dieser während der Ausführung ausgelöst.
(8) Abschneiden und Löschen sind DLLs (Daten definieren die Sprache). Die ursprünglichen Daten werden nicht im Rollback-Segment platziert und können nicht zurückgesetzt werden
(9) Wenn keine Sicherung vorhanden ist, verwenden Sie Drop und Truncate mit Vorsicht. Um einige Datenzeilen zu löschen, verwenden Sie „delete“ und kombinieren Sie es mit „wo“, um den Einflussbereich einzuschränken. Das Rollback-Segment muss groß genug sein. Um eine Tabelle zu löschen, verwenden Sie „Drop“. Wenn Sie die Tabelle behalten, aber die Daten in der Tabelle löschen möchten, verwenden Sie „Truncate“, wenn dies nichts mit der Transaktion zu tun hat. Wenn es sich um eine Transaktion handelt oder der Lehrer einen Auslöser auslösen möchte, verwenden Sie dennoch die Löschfunktion.
(10) Tabelle abschneiden ist schnell und effizient, weil:
Tabelle abschneiden ist funktionell mit der DELETE-Anweisung ohne WHERE-Klausel identisch: Beide löschen alle Zeilen in der Tabelle . Allerdings ist TRUNCATE TABLE schneller als DELETE und verbraucht weniger System- und Transaktionsprotokollressourcen. Die DELETE-Anweisung löscht jeweils eine Zeile und zeichnet für jede gelöschte Zeile einen Eintrag im Transaktionsprotokoll auf. TRUNCATE TABLE löscht Daten, indem es die Datenseiten freigibt, die zum Speichern von Tabellendaten verwendet werden, und zeichnet nur die Seitenfreigabe im Transaktionsprotokoll auf.
(11) TRUNCATE TABLE löscht alle Zeilen in der Tabelle, aber die Tabellenstruktur und ihre Spalten, Einschränkungen, Indizes usw. bleiben unverändert. Der zum Identifizieren neuer Zeilen verwendete Zähler wird auf den Startwert dieser Spalte zurückgesetzt. Wenn Sie den Wert der Identitätsanzahl beibehalten möchten, verwenden Sie stattdessen DELETE. Wenn Sie eine Tabellendefinition und ihre Daten löschen möchten, verwenden Sie die DROP TABLE-Anweisung.
(12) Für Tabellen, auf die durch FOREIGN KEY-Einschränkungen verwiesen wird, kann TRUNCATE TABLE nicht verwendet werden, es sollte jedoch eine DELETE-Anweisung ohne WHERE-Klausel verwendet werden. Da TRUNCATE TABLE nicht protokolliert wird, kann der Trigger nicht aktiviert werden.
5. Das Funktionsprinzip und die Arten von Indizes
Datenbankindex ist eine Datenbank Eine sortierte Datenstruktur im Verwaltungssystem, die das schnelle Abfragen und Aktualisieren von Daten in Datenbanktabellen unterstützt. Die Indeximplementierung verwendet normalerweise den B-Baum und seine Variante B+-Baum.
Zusätzlich zu den Daten verwaltet das Datenbanksystem auch Datenstrukturen, die bestimmte Suchalgorithmen erfüllen. Diese Datenstrukturen verweisen in irgendeiner Weise auf die Daten, sodass diese Datenstrukturen kann erweiterte Suchalgorithmen implementieren. Diese Datenstruktur ist ein Index.
Das Festlegen eines Indexes für eine Tabelle hat seinen Preis: Erstens erhöht es den Speicherplatz der Datenbank und zweitens nimmt das Einfügen und Ändern von Daten mehr Zeit in Anspruch ( weil der Index auch jederzeit geändert werden muss).
Die Abbildung zeigt eine mögliche Indizierungsmethode. Auf der linken Seite befindet sich eine Datentabelle mit insgesamt zwei Spalten und sieben Datensätzen. Die Spalte ganz links ist die physische Adresse des Datensatzes (beachten Sie, dass logisch benachbarte Datensätze nicht unbedingt physisch benachbart auf der Festplatte liegen). Um die Suche nach Col2 zu beschleunigen, können Sie wie rechts gezeigt einen binären Suchbaum verwalten, der den Indexschlüsselwert und einen Zeiger auf die physische Adresse des entsprechenden Datensatzes enthält Binäre Suche in O(log2n) Die entsprechenden Daten werden innerhalb der Komplexität erhalten.
Durch das Erstellen eines Index kann die Leistung des Systems erheblich verbessert werden.
Erstens kann durch die Erstellung eines eindeutigen Index die Eindeutigkeit jeder Datenzeile in der Datenbanktabelle garantiert werden.
Zweitens kann es den Datenabruf erheblich beschleunigen, was auch der Hauptgrund für die Erstellung eines Index ist.
Drittens kann es die Verbindung zwischen Tabellen beschleunigen, was besonders wichtig ist, um die referenzielle Integrität von Daten zu erreichen.
Viertens kann durch die Verwendung von Gruppierungs- und Sortierklauseln zum Datenabruf auch die Zeit für das Gruppieren und Sortieren in der Abfrage erheblich verkürzt werden.
Fünftens können Sie durch die Verwendung von Indizes Optimierungs-Hider während des Abfrageprozesses verwenden, um die Systemleistung zu verbessern.
Jemand könnte fragen: Das Hinzufügen eines Indexes hat so viele Vorteile, warum nicht für jede Spalte in der Tabelle einen Index erstellen? Denn das Hinzufügen von Indizes hat auch viele Nachteile.
Erstens nimmt die Erstellung und Pflege von Indizes Zeit in Anspruch, und diese Zeit nimmt mit zunehmender Datenmenge zu.
Zweitens müssen Indizes zusätzlich zum von der Datentabelle belegten Datenspeicherplatz auch eine bestimmte Menge an physischem Speicherplatz belegen Clustered-Index, dann benötigen Sie Der Speicherplatz wird größer sein.
Drittens muss der Index dynamisch verwaltet werden, wenn die Daten in der Tabelle hinzugefügt, gelöscht und geändert werden, was die Geschwindigkeit der Datenverwaltung verringert.
Indizes werden auf bestimmten Spalten in der Datenbanktabelle erstellt. Wenn Sie einen Index erstellen, sollten Sie berücksichtigen, welche Spalten indiziert werden können und welche nicht. Im Allgemeinen sollten Indizes für diese Spalten erstellt werden: Bei Spalten, die häufig durchsucht werden, kann dies die Suche nach Spalten beschleunigen, die als Primärschlüssel dienen. Außerdem wird die Eindeutigkeit der Spalte erzwungen und die Anordnungsstruktur der Daten in der Tabelle organisiert ; Bei häufig durchsuchten Spalten handelt es sich bei diesen Spalten hauptsächlich um Fremdschlüssel, die die Verbindung beschleunigen können, da der Index häufig nach dem Bereich durchsucht werden muss Der angegebene Bereich ist kontinuierlich. In vielen Fällen ist es erforderlich, einen Index für die sortierte Spalte zu erstellen, da der Index sortiert wurde, sodass die Abfrage die Sortierzeit für die Spalte beschleunigen kann Wird häufig in der WHERE-Klausel verwendet, um die Beurteilung von Bedingungen zu beschleunigen.
Ebenso sollten für einige Spalten keine Indizes erstellt werden. Im Allgemeinen weisen diese Spalten, die nicht indiziert werden sollten, die folgenden Merkmale auf:
Erstens sollten keine Indizes für Spalten erstellt werden, die in Abfragen selten verwendet oder referenziert werden. Dies liegt daran, dass diese Spalten nur selten verwendet werden und eine Indizierung oder Nicht-Indizierung die Abfragegeschwindigkeit nicht verbessert. Im Gegenteil: Durch das Hinzufügen von Indizes wird die Wartungsgeschwindigkeit des Systems verringert und der Platzbedarf erhöht.
Zweitens sollten Indizes nicht zu Spalten mit wenigen Datenwerten hinzugefügt werden. Dies liegt daran, dass die Datenzeilen im Ergebnissatz einen großen Teil der Datenzeilen in der Tabelle ausmachen, da diese Spalten in den Abfrageergebnissen nur sehr wenige Werte enthalten, z. B. die Geschlechtsspalte der Personaltabelle. Die Daten, die in der Tabelle durchsucht werden müssen. Der Anteil der Zeilen ist riesig. Durch Erhöhen des Index wird der Abruf nicht wesentlich beschleunigt.
Drittens sollten keine Indizes zu Spalten hinzugefügt werden, die als Text-, Bild- und Bit-Datentypen definiert sind. Dies liegt daran, dass das Datenvolumen dieser Spalten entweder recht groß ist oder nur sehr wenige Werte aufweist.
Viertens: Wenn die Änderungsleistung weitaus größer ist als die Abrufleistung, sollte der Index nicht erstellt werden. Dies liegt daran, dass die Änderungsleistung und die Abrufleistung im Widerspruch zueinander stehen. Beim Hinzufügen von Indizes wird die Abrufleistung verbessert, die Änderungsleistung wird jedoch verringert. Beim Reduzieren von Indizes erhöht sich die Änderungsleistung und die Abrufleistung verringert sich. Daher sollten keine Indizes erstellt werden, wenn die Änderungsleistung viel höher ist als die Abrufleistung.
Basierend auf den Funktionen der Datenbank können im Datenbankdesigner drei Arten von Indizes erstellt werden: eindeutiger Index, Primärschlüsselindex und Clustered-Index.
Einzigartiger Index
Ein eindeutiger Index ist ein Index, der nicht zulässt, dass zwei Zeilen denselben Indexwert haben.
Die meisten Datenbanken erlauben nicht, dass neu erstellte eindeutige Indizes mit der Tabelle gespeichert werden, wenn in den vorhandenen Daten doppelte Schlüsselwerte vorhanden sind. Die Datenbank verhindert möglicherweise auch das Hinzufügen neuer Daten, die zu doppelten Schlüsselwerten in der Tabelle führen würden. Wenn beispielsweise ein eindeutiger Index für den Nachnamen des Mitarbeiters (lname) in der Mitarbeitertabelle erstellt wird, können keine zwei Mitarbeiter denselben Nachnamen haben. Primärschlüsselindex-Datenbanktabellen verfügen häufig über eine Spalte oder eine Kombination von Spalten, deren Werte jede Zeile in der Tabelle eindeutig identifizieren. Diese Spalte wird als Primärschlüssel der Tabelle bezeichnet. Durch das Definieren eines Primärschlüssels für eine Tabelle in einem Datenbankdiagramm wird automatisch ein Primärschlüsselindex erstellt, bei dem es sich um einen bestimmten Typ eines eindeutigen Index handelt. Der Index erfordert, dass jeder Wert im Primärschlüssel eindeutig ist. Es ermöglicht auch einen schnellen Zugriff auf Daten, wenn in Abfragen ein Primärschlüsselindex verwendet wird. Clustered-Index In einem Clustered-Index entspricht die physische Reihenfolge der Zeilen in der Tabelle der logischen (Index-)Reihenfolge der Schlüsselwerte. Eine Tabelle kann nur einen Clustered-Index enthalten.
Wenn ein Index kein Clustered-Index ist, stimmt die physische Reihenfolge der Zeilen in der Tabelle nicht mit der logischen Reihenfolge der Schlüsselwerte überein. Clustered-Indizes bieten im Allgemeinen einen schnelleren Datenzugriff als Nicht-Clustered-Indizes.
Lokalitätsprinzip und Disk-Read-Ahead
Aufgrund der Eigenschaften des Speichermediums kann auf die Festplatte selbst zugegriffen werden ist langsamer als die Hauptfestplatte. In Verbindung mit den Kosten für die mechanische Bewegung beträgt die Zugriffsgeschwindigkeit der Festplatte daher häufig ein Hundertstel der Geschwindigkeit des Hauptspeichers . Um dieses Ziel zu erreichen, liest die Festplatte häufig nicht ausschließlich bei Bedarf, sondern jedes Mal im Voraus. Auch wenn nur ein Byte benötigt wird, beginnt die Festplatte an dieser Position und liest sequentiell eine bestimmte Länge an Daten rückwärts Erinnerung. Die theoretische Grundlage dafür ist das in der Informatik bekannte Lokalitätsprinzip: Bei der Nutzung eines Datenstücks werden in der Regel unmittelbar benachbarte Daten genutzt. Die während der Programmausführung benötigten Daten sind in der Regel konzentriert.
Da sequentielle Lesevorgänge auf der Festplatte sehr effizient sind (keine Suchzeit, sehr kurze Spin-Zeit), kann Read-Ahead für Programme mit Lokalität verwendet werden, um die E/A-Effizienz zu verbessern.
Die Länge des Vorlesens beträgt im Allgemeinen ein ganzzahliges Vielfaches der Seite. Seiten sind logische Blöcke computerverwalteten Speichers. Hardware und Betriebssysteme unterteilen häufig Hauptspeicher- und Festplattenspeicherbereiche in aufeinanderfolgende gleich große Blöcke. Jeder Speicherblock wird als Seite bezeichnet (in vielen Betriebssystemen beträgt die Seitengröße normalerweise 4 KB). Hauptspeicher und Festplattenaustauschdaten in Seiteneinheiten. Wenn sich die vom Programm zu lesenden Daten nicht im Hauptspeicher befinden, wird eine Seitenfehlerausnahme ausgelöst. Zu diesem Zeitpunkt sendet das System ein Lesesignal an die Festplatte und die Festplatte findet die Startposition der Daten und eine oder mehrere Seiten rückwärts lesen, dann abnormal zurückkehren und das Programm weiter ausführen.
Leistungsanalyse des B-/+Baum-Index
Hier können wir endlich den B-/+Baum analysieren Indexleistung.
Wie oben erwähnt, wird die Anzahl der Festplatten-I/Os im Allgemeinen zur Bewertung der Qualität der Indexstruktur verwendet. Beginnen wir mit der B-Tree-Analyse. Gemäß der Definition von B-Tree ist ersichtlich, dass für einen Abruf maximal h Knoten besucht werden müssen. Die Designer des Datenbanksystems machten sich geschickt das Disk-Read-Ahead-Prinzip zunutze und legten die Größe eines Knotens auf eine Seite fest, sodass jeder Knoten mit nur einem I/O vollständig geladen werden kann. Um dieses Ziel zu erreichen, müssen bei der tatsächlichen Implementierung von B-Tree die folgenden Techniken verwendet werden:
Jedes Mal, wenn ein neuer Knoten erstellt wird, wird eine Seite Speicherplatz direkt angewendet Dadurch wird sichergestellt, dass ein Knoten physisch auf einer Seite gespeichert ist und die Speicherzuweisung des Computers seitenorientiert ist, sodass ein Knoten nur einen E/A benötigt.
Ein Abruf im B-Tree erfordert höchstens h-1 I/O (Wurzelknoten-residenter Speicher) und die asymptotische Komplexität ist O(h)=O(logdN). In allgemeinen praktischen Anwendungen ist der Out-Grad d eine sehr große Zahl, normalerweise mehr als 100, sodass h sehr klein ist (normalerweise nicht mehr als 3).
Bei Strukturen wie rot-schwarzen Bäumen ist h offensichtlich viel tiefer. Da logisch nahe Knoten (Eltern und Kinder) physisch weit entfernt sein können, kann die Lokalität nicht ausgenutzt werden, sodass die asymptotische E/A-Komplexität des rot-schwarzen Baums ebenfalls O (h) ist und die Effizienz offensichtlich viel schlechter ist als die von der B-Baum.
Zusammenfassend ist die Verwendung von B-Tree als Indexstruktur sehr effizient.
6. Art der Verbindung
Im Abfrageanalysator ausführen:
--Erstellen Sie die Tabellen Tabelle1, Tabelle2:
create table table1(id int,name varchar(10)) create table table2(id int,score int) insert into table1 select 1,'lee' insert into table1 select 2,'zhang' insert into table1 select 4,'wang' insert into table2 select 1,90 insert into table2 select 2,100 insert into table2 select 3,70
Beispiel: Tabelle
------------------------------------------------- table1 | table2 | ------------------------------------------------- id name |id score | 1 lee |1 90| 2 zhang| 2 100| 4 wang| 3 70| -------------------------------------------------
Die folgenden sind alle in der Abfrageanalyse Im Prozessor ausgeführt
1. Outer Join
1. Konzept: einschließlich Left Outer Join, Right Outer Join oder vollständiger Outer Join
2.左连接:left join 或 left outer join
(1)左向外联接的结果集包括 LEFT OUTER 子句中指定的左表的所有行,而不仅仅是联接列所匹配的行。如果左表的某行在右表中没有匹配行,则在相关联的结果集行中右表的所有选择列表列均为空值(null)。
(2)sql 语句
select * from table1 left join table2 on table1.id=table2.id
-------------结果------------- idnameidscore ------------------------------ 1lee190 2zhang2100 4wangNULLNULL ------------------------------
注释:包含table1的所有子句,根据指定条件返回table2相应的字段,不符合的以null显示
3.右连接:right join 或 right outer join
(1)右向外联接是左向外联接的反向联接。将返回右表的所有行。如果右表的某行在左表中没有匹配行,则将为左表返回空值。
(2)sql 语句
select * from table1 right join table2 on table1.id=table2.id
-------------结果------------- idnameidscore ------------------------------ 1lee190 2zhang2100 NULLNULL370 ------------------------------
注释:包含table2的所有子句,根据指定条件返回table1相应的字段,不符合的以null显示
4.完整外部联接:full join 或 full outer join
(1)完整外部联接返回左表和右表中的所有行。当某行在另一个表中没有匹配行时,则另一个表的选择列表列包含空值。如果表之间有匹配行,则整个结果集行包含基表的数据值。
(2)sql 语句
select * from table1 full join table2 on table1.id=table2.id
-------------结果------------- idnameidscore ------------------------------ 1lee190 2zhang2100 4wangNULLNULL NULLNULL370 ------------------------------
注释:返回左右连接的和(见上左、右连接)
二、内连接
1.概念:内联接是用比较运算符比较要联接列的值的联接
2.内连接:join 或 inner join
3.sql 语句
select * from table1 join table2 on table1.id=table2.id
-------------结果------------- idnameidscore ------------------------------ 1lee190 2zhang2100 ------------------------------
注释:只返回符合条件的table1和table2的列
4.等价(与下列执行效果相同)
A:select a.*,b.* from table1 a,table2 b where a.id=b.id
B:select * from table1 cross join table2 where table1.id=table2.id
(注:cross join后加条件只能用where,不能用on)
三、交叉连接(完全)
1.概念:没有 WHERE 子句的交叉联接将产生联接所涉及的表的笛卡尔积。第一个表的行数乘以第二个表的行数等于笛卡尔积结果集的大小。(table1和table2交叉连接产生3*3=9条记录)
2.交叉连接:cross join (不带条件where...)
3.sql语句
select * from table1 cross join table2
-------------结果------------- idnameidscore ------------------------------ 1lee190 2zhang190 4wang190 1lee2100 2zhang2100 4wang2100 1lee370 2zhang370 4wang370 ------------------------------
注释:返回3*3=9条记录,即笛卡尔积
4.等价(与下列执行效果相同)
A:select * from table1,table2
7、数据库范式
1) 第一范式(1NF)
在任何一个关系数据库中,第一范式(1NF)是对关系模式的基本要求,不满足第一范式(1NF)的数据库就不是关系数据库。
所谓第一范式(1NF)是指数据库表的每一列都是不可分割的基本数据项,同一列中不能有多个值,即实体中的某个属性不能有多个值或者不能有重复的属性。如果出现重复的属性,就可能需要定义一个新的实体,新的实体由重复的属性构成,新实体与原实体之间为一对多关系。在第一范式(1NF)中表的每一行只包含一个实例的信息。简而言之,第一范式就是无重复的列。
2 )第二范式(2NF)
第二范式(2NF)是在第一范式(1NF)的基础上建立起来的,即满足第二范式(2NF)必须先满足第一范式(1NF)。第二范式(2NF)要求数据库表中的每个实例或行必须可以被惟一地区分。为实现区分通常需要为表加上一个列,以存储各个实例的惟一标识。这个惟一属性列被称为主关键字或主键、主码。
第二范式(2NF)要求实体的属性完全依赖于主关键字。所谓完全依赖是指不能存在仅依赖主关键字一部分的属性,如果存在,那么这个属性和主关键字的这一部分应该分离出来形成一个新的实体,新实体与原实体之间是一对多的关系。为实现区分通常需要为表加上一个列,以存储各个实例的惟一标识。简而言之,第二范式就是非主属性非部分依赖于主关键字。
3 )第三范式(3NF)
满足第三范式(3NF)必须先满足第二范式(2NF)。简而言之,第三范式(3NF)要求一个数据库表中不包含已在其它表中已包含的非主关键字信息。例如,存在一个部门信息表,其中每个部门有部门编号(dept_id)、部门名称、部门简介等信息。那么在员工信息表中列出部门编号后就不能再将部门名称、部门简介等与部门有关的信息再加入员工信息表中。如果不存在部门信息表,则根据第三范式(3NF)也应该构建它,否则就会有大量的数据冗余。简而言之,第三范式就是属性不依赖于其它非主属性。(我的理解是消除冗余)
8、数据库优化的思路
这个我借鉴了慕课上关于数据库优化的课程。
一、SQL语句优化
1)应尽量避免在 where 子句中使用!=或操作符,否则将引擎放弃使用索引而进行全表扫描。
2)应尽量避免在 where 子句中对字段进行 null 值判断,否则将导致引擎放弃使用索引而进行全表扫描,如:
select id from t where num is null
可以在num上设置默认值0,确保表中num列没有null值,然后这样查询:
select id from t where num=0
3)很多时候用 exists 代替 in 是一个好的选择
4)用Where子句替换HAVING 子句 因为HAVING 只会在检索出所有记录之后才对结果集进行过滤
二、索引优化
看上文索引
三、数据库结构优化
1)范式优化: 比如消除冗余(节省空间。。)
2)反范式优化:比如适当加冗余等(减少join)
3)拆分表: 分区将数据在物理上分隔开,不同分区的数据可以制定保存在处于不同磁盘上的数据文件里。这样,当对这个表进行查询时,只需要在表分区中进行扫描,而不必进行全表扫描,明显缩短了查询时间,另外处于不同磁盘的分区也将对这个表的数据传输分散在不同的磁盘I/O,一个精心设置的分区可以将数据传输对磁盘I/O竞争均匀地分散开。对数据量大的时时表可采取此方法。可按月自动建表分区。
4)拆分其实又分垂直拆分和水平拆分: 案例: 简单购物系统暂设涉及如下表: 1.产品表(数据量10w,稳定) 2.订单表(数据量200w,且有增长趋势) 3.用户表 (数据量100w,且有增长趋势) 以mysql为例讲述下水平拆分和垂直拆分,mysql能容忍的数量级在百万静态数据可以到千万 垂直拆分:解决问题:表与表之间的io竞争 不解决问题:单表中数据量增长出现的压力 方案: 把产品表和用户表放到一个server上 订单表单独放到一个server上 水平拆分: 解决问题:单表中数据量增长出现的压力 不解决问题:表与表之间的io争夺
方案: 用户表通过性别拆分为男用户表和女用户表 订单表通过已完成和完成中拆分为已完成订单和未完成订单 产品表 未完成订单放一个server上 已完成订单表盒男用户表放一个server上 女用户表放一个server上(女的爱购物 哈哈)
四、服务器硬件优化
这个么多花钱咯!
9、存储过程与触发器的区别
Trigger sind den gespeicherten Prozeduren sehr ähnlich. Der einzige Unterschied zwischen den beiden besteht darin, dass Trigger nicht mit EXECUTE-Anweisungen aufgerufen werden können, sondern automatisch ausgelöst (aktiviert) werden, wenn der Benutzer eine ausführt Transact-SQL-Anweisung implementieren. Ein Trigger ist eine gespeicherte Prozedur, die ausgeführt wird, wenn Daten in einer angegebenen Tabelle geändert werden. Trigger werden häufig erstellt, um die referenzielle Integrität und Konsistenz logisch verknüpfter Daten in verschiedenen Tabellen durchzusetzen. Da Benutzer Trigger nicht umgehen können, können sie zur Durchsetzung komplexer Geschäftsregeln zur Gewährleistung der Datenintegrität verwendet werden. Trigger unterscheiden sich von gespeicherten Prozeduren. Trigger werden hauptsächlich über Ereignisausführungstrigger ausgeführt, während gespeicherte Prozeduren direkt über den Namen der gespeicherten Prozedur aufgerufen werden können. Wenn Vorgänge wie UPDATE, INSERT und DELETE für eine bestimmte Tabelle ausgeführt werden, führt SQLSERVER automatisch die durch den Trigger definierten SQL-Anweisungen aus und stellt so sicher, dass die Datenverarbeitung den durch diese SQL-Anweisungen definierten Regeln entsprechen muss.
Ursprüngliche Adresse: https://www.cnblogs.com/frankielf0921/p/5930743.html
Das obige ist der detaillierte Inhalt vonMySQL-Interviewfragen mit Antworten – 2019. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!