Heim > Datenbank > MySQL-Tutorial > Hauptteil

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

coldplay.xixi
Freigeben: 2020-10-26 17:44:33
nach vorne
2163 Leute haben es durchsucht

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

MySQL kann sich auf die Indizierung verlassen, aber ich kann mich nur auf Teilzeitarbeit verlassen ... 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)复制代码
      Nach dem Login kopieren
      Index in der Tabelle anzeigen

      ALTER TABLE test add UNIQUE idx_id_card(id_card)复制代码
      Nach dem Login kopieren
      Index analysieren
      EXPLAIN SELECT * from test WHERE name = "xhJaver"复制代码
      Nach dem Login kopieren
      Nach dem Login kopieren

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

      ALTER TABLE test add INDEX idx_name(name)复制代码
      Nach dem Login kopieren

      查看test表中的索引

      SHOW INDEX FROM test复制代码
      Nach dem Login kopieren

      其中的属性

      • 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"复制代码
      Nach dem Login kopieren

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

      五、覆盖索引

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

      select address from test where  name = "xhJaver"复制代码
      Nach dem Login kopieren

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

      六、最左匹配原则

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

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

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

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

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

      七、explain分析索引语句

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

      EXPLAIN SELECT * from test WHERE name = "xhJaver"复制代码
      Nach dem Login kopieren
      Nach dem Login kopieren

      它的属性有

      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>, <, in, zwischen und anderen Abfragen

      • Index: vollständiger Tabellenscan, durchläuft aber den gesamten Indexbaum

      • all: Vollständiger Tabellenscan, es wird kein Index verwendet. Mögliche_Schlüssel: Wenn ein Index für das Abfragefeld vorhanden ist, wird dieser angezeigt.

      • Schlüssel: Der spezifische Index, der verwendet wird verwendet, mögliche_schlüssel sind null und werden nur im Schlüssel angezeigt

      key_len : Die Anzahl der im Index verwendeten Bytes, die maximal mögliche Länge, nicht die tatsächliche Länge, key_len wird basierend auf der Tabellendefinition berechnet und nicht abgerufen die Tabelle

      ref: Gibt an, welches Feld im Index verwendet wird

      rows: Schätzt grob die Anzahl der Zeilen, die gelesen werden müssen

      filtered: Zeigt die prozentuale Schätzung der Anzahl der gefilterten Zeilen an der Zustand.

      Extra:

      Verwendung von Dateisortierung: Die Sortierung, die MySQL nicht mithilfe des Index durchführen kann, wird Dateisortierung genannt

      • Verwendung temporär: Verwenden Sie eine temporäre Tabelle, um die Zwischenergebnisse zu speichern, wenn MySQL die sortiert Abfrageergebnisse Es werden temporäre Tabellen verwendet, die in der Reihenfolge nach und in der Gruppierung üblich sind
      • Using index:使用了覆盖索引,查询内容在索引内

        1. 如果出现了Using where,表示对查询出来的数据进行了过滤
        2. 如果没有出现Using where,表示对查询出来的数据没有进行过滤
      • 只有Using where 查询内容不在索引内,且对查出来的数据进行了过滤

      1. EXPLAIN SELECT (select student.id from student WHERE student.`name`="xhJaver") FROM teacher2. EXPLAIN SELECT * FROM teacher where teacher.id = (select student.id from student WHERE student.`name`="xhJaver") 
      复制代码
      Nach dem Login kopieren

      我们写几个sql语句实际分析下 1.SELECT后面2.where后面

      我们就拿后面这个图来实战分析一下,挑几个重要的属性说一下

      select_type:

      • 我们最外层的查询是 from teacher 所以table为teacher的那个表的select_type就是primary

      • select/where后面的括号中的查询语句中的表是student,所以table为student的那个表的select_type就是subquery

      table: 这条sql查询用到的表

      type: 访问类型

      • 第一行const : teacher.id =巴拉巴拉巴拉(这个是常数)主键和常数比较时,这个表最多有一个匹配数据,只读取一次

      • 第二行ref:代表用到了普通索引,就是这个索引name和xhJaver匹配,可能匹配到很多相同的值

      possible_key: 代表可能用到的索引,但是不一定会用到

      key: 代表用到的索引, 用到了idx_name,PRIMARY索引

      ref: 这一列显示了在key列记录的索引中,表查找值所用到的列或常量, 常见的有:const,字段名

      extra:

      • using index: 一般是使用了覆盖索引,看我们这个sql语句,
      select student.id from student WHERE student.`name`="xhJaver"复制代码
      Nach dem Login kopieren

      name字段有索引,查询的是id,b+树叶子节点存的数据就是id,所以不需要回表查询了,用到了覆盖索引

      八、索引失效原因

      1. 遇到范围查询(>,<,like,beetwon),右边的索引列会失效

      2. 索引字段不能有函数操作或者不能是表达式的一部分

      3. 索引字段隐式类型转换 索引字段类型是string,我们传进来个int

      4. 使用时or,is null ,is not null , !=, <>, 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!

    Verwandte Etiketten:
    Quelle:juejin.im
    Erklärung dieser Website
    Der Inhalt dieses Artikels wird freiwillig von Internetnutzern beigesteuert und das Urheberrecht liegt beim ursprünglichen Autor. Diese Website übernimmt keine entsprechende rechtliche Verantwortung. Wenn Sie Inhalte finden, bei denen der Verdacht eines Plagiats oder einer Rechtsverletzung besteht, wenden Sie sich bitte an admin@php.cn
    Beliebte Tutorials
    Mehr>
    Neueste Downloads
    Mehr>
    Web-Effekte
    Quellcode der Website
    Website-Materialien
    Frontend-Vorlage