MySQL kann sich auf die Indizierung verlassen, aber ich kann mich nur auf Teilzeitarbeit verlassen ...

In der Spalte „MySQL-Tutorial“ werden verwandte Indizes vorgestellt.

1. Indexdatenstruktur

Diese Frage wird im Interview auf jeden Fall gestellt. Warum wählt MySQL b+tree als Index? Anstatt einen anderen Index zu wählen, beispielsweise einen B-Baum? Haschisch?

Die unten erwähnte Festplatten-E/A bezieht sich auf den Vorgang des Ladens von Daten von der Festplatte in den Speicher.

Hash-Index

unterstützt keine Bereichsabfrage, da Hash ein Schlüssel ist, der einem Wert entspricht Keine Möglichkeit, eine Bereichsabfrage durchzuführen

Für einen Binärbaum ist es charakteristisch, dass der linke Teilbaum kleiner als der Wurzelknoten und kleiner als der rechte Teilbaum ist. Wenn es ein Problem mit dem Wert des Wurzelknotens gibt, kann er zu einem degenerieren Verknüpfte Liste, das heißt, der Baum wird nicht verzweigt und der Baum bleibt nach links oder ganz rechts, sodass Sie nicht in der Hälfte suchen und die Anzahl der E/As reduzieren können Wenn Sie Bereichsabfragen verwenden, müssen Sie jedes Mal von der Wurzel aus durchlaufen. Je höher der Baum, desto häufiger werden E/A-Vorgänge ausgeführt. Wenn ein Binärbaum ausgeglichen ist , es wird nicht den Nachteil haben, dass der Binärbaum zu einer verknüpften Liste degeneriert, da der Unterschied zwischen seinen linken und rechten untergeordneten Knoten höchstens 1 Ebene beträgt, aber Bereichssuche und Binärbäume werden nicht unterstützt. Das Problem ist das gleiche

B-Baum

Der Baum ist sehr kurz und fett und die E/A-Operationen sind reduziert. Es handelt sich um einen Multi-Fork-Baum, und jeder Knoten speichert die entsprechenden Zeilendaten Wenn dies der Fall ist: Wenn die Anzahl der Spalten in einer Datenzeile weiter zunimmt, nimmt die Anzahl der auf dieser Seite gespeicherten Knoten ab. Da der belegte Platz weiter zunimmt, wird der Baum immer höher, wodurch die Anzahl der E/A-Vorgänge zunimmt. Gleichzeitig werden Bereiche nicht unterstützt. Es wäre besser, wenn die gleiche Speicherplatzgröße viele Knotendaten speichern könnte, daher gibt es den folgenden b+-Baum

b+-Baum

Es speichert nur Indexdaten für Nicht-Blattknoten, nicht die gesamte Zeile von Daten, aber die Blattknoten sind redundant und die Nicht-Blattknoten sind auch mit doppelt verknüpften Listen verknüpft, was die sequentielle Suche erleichtert. Im Vergleich zum B-Baum ist der B+-Baum kürzer und dicker. und die Anzahl der Festplatten-IOs ist geringer Wir können es einfach so verstehen Der Clustered-Index ist der Primärschlüsselindex und der Nicht-Clustered-Index ist der normale Index. Der wesentliche Unterschied besteht darin, dass die Blattknoten des Clustered-Index die gesamte Datenzeile speichern.

innodb implementiert den Clustering-Index über den Primärschlüssel. Wenn kein Primärschlüssel vorhanden ist, wird ein eindeutiger, nicht leerer Index zur Implementierung ausgewählt. Wenn kein Primärschlüssel vorhanden ist, wird implizit ein Primärschlüssel zur Implementierung des Clusterings generiert. Index

Nicht gruppierter Index speichert den Indexwert und den Primärschlüsselwert

• Gewöhnlicher Index Eine Tabelle kann mehrere gewöhnliche Indizes enthalten, und der Index kann für jedes Feld erstellt werden Normalerweise handelt es sich bei den meisten erstellten Indizes um gewöhnliche Indizes eine Tabelle Es kann mehrere eindeutige Indizes geben

• PrimärschlüsselindexDer Unterschied besteht darin, dass eine Tabelle nur einen Primärschlüsselindex haben kann 3. Informationen zu indiziertem SQL

  Indexnamen ändern: Zuerst löschen und dann hinzufügen
Index löschen (auf zwei Arten)

• ALTER TABLE test add  PRIMARY  KEY (id)复制代码

  Index in der Tabelle anzeigen

  ALTER TABLE test add UNIQUE idx_id_card(id_card)复制代码

  Index analysieren

  EXPLAIN SELECT * from test WHERE name = "xhJaver"复制代码

  我们先给name字段添加一个索引,索引名字叫做idx_name

  ALTER TABLE test add INDEX idx_name(name)复制代码

  查看test表中的索引

  SHOW INDEX FROM test复制代码

  

  其中的属性

  • table: 表名

  • Non_unique: 能重复的话为1，不能重复的话为0，我们主键的那里是0，而name那里是1，因为name可以重复，而主键不能重复

  • Key_name: 索引名称

  • Seq_in_index:索引中列的顺序

  • Column_name:列名称

  • Collation:列以什么方式存储的，A升序，null无序

  • Cardinality:数目越大，则使用该索引的可能性越大

  • Sub_part:如果列只是部分的编入索引，则被编入索引的字符数目，如果整列被编入索引，则为null

  • Packed：关键字是否被压缩，null表示没有被压缩

  • Null:如果该列含有null,则为yes,如果没有null,则为no

  • Index_type:索引数据结构

  • Comment:多种评注

  四、回表查询

  select * from test where  name = "xhJaver"复制代码

  假如说我们name字段建立了索引，然后当我们运行这一句sql语句的时候，因为建立的是普通索引，所以我们的b+树的叶子节点存储的数据是id，我们会找到name是xhJaver的这条记录的id，再根据这个id,去主键索引的那棵b+树去查询，查询到叶子节点时即查询出这条记录，可见这个过程中，我们从一棵树跑到了另一棵树继续查，这样就叫做“回表查询”，那有没有办法只查一棵树就可以查询出结果呢？

  五、覆盖索引

  办法当然是有的啦，那就是覆盖索引，我们注意到，刚才这个sql语句时查询出来了所有元素，假如说我们这样写的话

  select address from test where  name = "xhJaver"复制代码

  假如说我们建立的索引是（name,address）那么这个时候（name,address）这棵b+树的叶子节点存储的数据就包括address了，此时就不需要再根据name = "xhJaver"的id去第二棵树查了，这样就避免了回表查询

  六、最左匹配原则

  假如说现在我们写一个这样的sql语句

  select *  from test where  name = "xhJaver" and age =23  and address="京东"复制代码

  并且我们建立的索引是（name,address,age）这样是会用到（name,address,age）索引的，可是如果要这样写的话

  select *  from test where  name = "xhJaver" and age >23  and address="京东"复制代码

  这样只会用到（name，age）这两个索引，从左边开始匹配，如果要是遇到范围查询的话，则不继续往右匹配索引

  七、explain分析索引语句

  我们用explain语句解析一下下面这条sql语句

  EXPLAIN SELECT * from test WHERE name = "xhJaver"复制代码

  

  它的属性有

  id: 执行的顺序

  • id相同时，顺序从上到下执行
  • id不同时，id大的先执行

  select_type:  查询的类型

  • primary: 最外层的查询被标记为primary
  • simple:  简单查询，没有关联其他表，就一张表
  • subquery: 在where或者select中的子查询
  • derived: 衍生虚拟表  例如from(子查询) t,这个子查询的结果就被放在虚拟表t中

  table:  关于哪张表的

  partitions:  分区相关（还没搞懂呜呜呜）

  type:访问类型

  性能由好至坏依次是 system > const > eq_ref > ref > fulltext > ref_or_null > index_merge > unique_subquery > index_subquery > range > index > ALL一般来说，好的sql查询至少达到range级别，最好能达到ref

  • system: Es gibt nur eine Datenzeile in der Tabelle

  • const: Konstantenabfrage wird normalerweise verwendet, um den Primärschlüssel auf Gleichheit mit einer Konstante zu vergleichen, und er kann durch Indexabfrage gefunden werden einmal

  • eq_ref: Eindeutiger Index. Jeder Index entspricht einem Datenelement, z. B. einem Primärschlüsselindex.

  • ref: Nicht eindeutiger Index. Jeder Index kann mehreren Datenzeilen entsprechen, z als gewöhnlicher Index

  • Bereich: Bereichsabfrage, verwendet>, cb7135df2675de27eec790a139a3eef0,3730409ab0102a19484a1261b4c3727d, like "%xxx" 索引会失效

  但是用覆盖索引就可以解决 like左模糊查询走不到索引的情况 如果只select索引字段，或者select索引字段和主键，也会走索引的。

  更多相关免费学习推荐：mysql教程(视频)

Das obige ist der detaillierte Inhalt vonMySQL kann sich auf die Indizierung verlassen, aber ich kann mich nur auf Teilzeitarbeit verlassen .... Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!