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?
unterstützt keine Bereichsabfrage, da Hash ein Schlüssel ist, der einem Wert entspricht Keine Möglichkeit, eine Bereichsabfrage durchzuführenFü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ügenALTER TABLE test add PRIMARY KEY (id)复制代码
ALTER TABLE test add UNIQUE idx_id_card(id_card)复制代码
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语句解析一下下面这条sql语句
EXPLAIN SELECT * from test WHERE name = "xhJaver"复制代码
它的属性有
id: 执行的顺序
select_type: 查询的类型
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.
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
Using index:使用了覆盖索引,查询内容在索引内
只有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") 复制代码
我们写几个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:
select student.id from student WHERE student.`name`="xhJaver"复制代码
name字段有索引,查询的是id,b+树叶子节点存的数据就是id,所以不需要回表查询了,用到了覆盖索引
遇到范围查询(>,<,like,beetwon),右边的索引列会失效
索引字段不能有函数操作或者不能是表达式的一部分
索引字段隐式类型转换 索引字段类型是string,我们传进来个int
使用时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!