在线时间 1630 小时 最后登录 2024-1-29 注册时间 2017-5-16 听众数 82 收听数 1 能力 120 分 体力 559448 点 威望 12 点 阅读权限 255 积分 173207 相册 1 日志 0 记录 0 帖子 5313 主题 5273 精华 18 分享 0 好友 163
TA的每日心情 开心 2021-8-11 17:59
签到天数: 17 天
[LV.4]偶尔看看III
网络挑战赛参赛者
网络挑战赛参赛者
自我介绍 本人女,毕业于内蒙古科技大学,担任文职专业,毕业专业英语。
群组 : 2018美赛大象算法课程
群组 : 2018美赛护航培训课程
群组 : 2019年 数学中国站长建
群组 : 2019年数据分析师课程
群组 : 2018年大象老师国赛优
, b+ d! m5 T( [. @4 @
mysql索引和explain的详解 索引原理分析
. c" k' W4 Y9 d& h) C ~, U8 _ 5 R' u& v- I% h$ ?1 ]
索引存储结构! [ ]' D- [$ _: x [9 D5 {: Q
索引是在存储引擎中实现的,也就是说不同的存储引擎,会使使用不同的索引
" O) Y: ~4 U: D* c! B% ?' h5 X* x MyISAM和InnoDB存储引擎:只支持B+ TREE索引, 也不能够更换6 }) {6 N8 V- k
MEMORY/HEAP存储引擎:支持HASH和BTREE索引' h/ ?. R. P5 \# |: e. ?
" w) {; G1 C* r( U1 W B树图示
3 M, H- Q8 j5 a+ e
$ `( z( d0 ^4 w& ?) \+ ~ B树是为了磁盘或其它存储设备设计的一种多叉(下面你会看到,相对于二叉,B树每个内结点有多个分支,即多叉)平衡查找树。 多叉平衡。
! ]9 m8 H/ d8 {5 y F" J t 2 v) }7 Q# L# O' X1 ?. l8 A( I
8 Z' W5 ~( k% }8 v! i: A3 M3 }: g
% d3 K& n# i7 z; Y: A) N3 i
5 s5 q- }$ W% v B树和B+树的区别:
2 u9 t; T& o; } B树和B+树的最大区别在于非叶子节点是否存储数据的问题
; b* S# T+ N5 G$ r8 ]* W
3 |# _, F& a9 Q9 G 在结构上:
6 F# f( z# B- t, c# V% ^# Z) W: ^5 b8 l (1) B树是非也只节点和叶子节点都会存储数据。
% B; {6 w3 \1 N3 Y% f3 g" c (2) B+树只有叶子节点才会存储数据,而且数据都是在一行上,而且这些数据都是指针指向的,也是有顺序的。6 D1 B1 d. E- a$ w6 F$ y
0 B v) z" R5 P# `* l5 e$ Z, w 在性能上:
+ C9 ]" ^$ u5 b$ E; B: a* G- M- v (1)对于B-树相对于B+数据,B-Tree因为非叶子结点也保存具体数据,所以在查找某个关键字的时候找到即可返回。而B+Tree所有的数据都在叶子结点,每次查找都得到叶子结点。所以在同样高度的B-Tree和B+Tree中,B-Tree查找某个关键字的效率更高。B-Tree在单条数据读写有着更强的性能。
8 B" _1 q8 I1 p( z9 I# K1 g& ^ (2)但由于B+Tree所有的数据都在叶子结点,并且结点之间有指针连接,在找大于某个关键字或者小于某个关键字的数据的时候,B+Tree只需要找到该关键字然后沿着链表遍历就可以了,而B-Tree还需要遍历该关键字结点的根结点去搜索。这个也决定当连表查询的时候mysql比起mongo有显著的优势。更重要的是由于B-Tree的每个结点(这里的结点可以理解为一个数据页)都存储主键+实际数据,而B+Tree非叶子结点只存储关键字信息,而每个页的大小有限是有限的,所以同一页能存储的B-Tree的数据会比B+Tree存储的更少。这样同样总量的数据,B-Tree的深度会更大,增大查询时的磁盘I/O次数,进而影响查询效率。) T3 _! D$ c+ z2 `! O
$ W+ O1 o2 v, ~5 Q- x 聚集索引(MyISAM)* B$ G9 J2 j- H+ w5 H
B+树叶节点只会存储数据行(数据文件)的指针,简单来说数据和索引不在一起,就是聚集0 j; ]3 t) ]5 a2 e7 n9 d: {
索引。7 I! \" c7 T5 ^. N7 r
聚集索引包含主键索引和辅助索引都会存储数据指针的值。* Z2 \: G. N* [6 E4 E
, O' H0 Z8 q* E( f' b% D
7 {* |- O s2 P" D, o! m2 l! d
) S3 O+ D/ ]& q
辅助索引(次要索引)
5 n+ G: {# g. m& b: N9 V' ^ 在 MyISAM 中,主索引和辅助索引(Secondary key)在结构上没有任何区别,只是主索引要求 key 是唯一的, 4 S7 ~* v2 L2 {
而辅助索引的 key 可以重复。如果我们在 Col2 上建立一个辅助索引,则此索引的结构如下图所示 . n; D$ j" y) e, o7 X
) `" a* g2 \+ K. s1 ~- ` 同样也是一颗 B+Tree,叶子节点中保存数据记录的地址。因此,MyISAM 中索引检索的算法为首先按照B+Tree 搜索算法搜索索引,如果指定的 Key 存在,则取出其data 域的值,然后以 data 域的值为地址,读取相应数据记录。
: J( ]* X$ j& Q3 \* w6 D3 x 4 Q* A, G) D5 `8 \; Y* d* s2 U
聚集索引(InnoDB); T! |0 q, l$ k* s' G# O
; A4 x/ z2 C1 g8 [' e, ~' d
主键索引(聚集索引)的叶子节点会存储数据行,也就是说数据和索引是在一起,这就是聚集索引。
, D' c+ l. l2 n4 _ 辅助索引只会存储主键值+ y+ Q8 H e( K; x7 L2 P
如果没有没有主键,则使用唯一索引建立聚集索引;如果没有唯一索引,MySQL会按照一定规则创建聚集索引。
6 W/ G D. z/ W1 M
/ r- w7 e% M4 b* B( c# k 主键索引( D; U! ]9 z# I% j
1.InnoDB 要求表必须有主键(MyISAM 可以没有),如果没有显式指定,则 MySQL系统会自动选择一个可以
3 M" @/ M% ^3 @, ~2 O$ c 唯一标识数据记录的列作为主键,如果不存在这种列,则MySQL 自动为 InnoDB 表生成一个隐含字段作为主键,类型为长整形。
+ ]: K; x" ?/ n) ]" R0 Y; J: n5 Y& H+ s 5 @' I( N) K1 V( M2 B
# I/ D* a J% R2 d+ s) a9 x- ]
3 o; h3 h, u" D! M1 K, `
% B: V" m% h4 X: a. ?% A$ A 上图是 InnoDB 主索引(同时也是数据文件)的示意图,可以看到叶节点包含了完整的数据记录。这种索引叫做聚集索引。因为 InnoDB 的数据文件本身要按主键聚集。
+ I2 M1 J" O, }" W1 I; [
# V! @5 C8 a9 N% K4 d3 t+ i
% C9 H( N: M9 j- R4 _3 R
/ e; _3 n- `! [0 C; ~
! n X/ i+ o; B ( \$ A& I0 _8 A1 M7 |. U, h
$ h7 L, S y' i0 \6 ^/ o6 n( c
mysql创建索引的时候和用法与索引息息相关,要建立合适的索引和理解一些索引的执行计划,就需要认识索引的结构。
9 y O1 t' \! u' `
, m e3 v, B4 v* L; r, d explain的详解
' \ F2 y2 b5 n" L" ?+ l ; L9 N: u1 E2 Y, m' }4 Q# F3 p
参数说明:, f7 |. F! g5 `
explain后会出现十列数据,下面将介绍这下面的十列数据。* ^+ [/ q% F# c* n" P( H
' A: z1 l2 c# T& P$ W: i. H id、select_type、table、type、possible_keys、key、key_len、ref、rows、Extra# F1 M6 L5 @5 j/ ]9 v4 s
, h7 b) E2 z8 |& @5 E
先附上案例表:
}+ y2 V, |# Z, F* I' H; p* S
" V7 B7 n+ d- {- F CREATE TABLE `taddr` (' q8 N$ I( |' B' K
`id` int(11) NOT NULL AUTO_INCREMENT,
" k1 }0 H7 V+ { `country` varchar(100) DEFAULT '',
- f; O. d: E8 H6 }- ?5 b `province` varchar(100) DEFAULT '',8 C8 b: N- \% s
PRIMARY KEY (`id`)" J; g# v9 e1 V1 x- X
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8
0 D5 b0 C Y) L, ?# Z4 a
1 P s* X+ D# ?. @ CREATE TABLE `user` (3 T. l. }. u( F1 H9 X
`id` int(11) NOT NULL AUTO_INCREMENT,% ]: x: g! x- y j
`username` varchar(50) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,9 ^: v7 o# g9 `) b+ O9 _% v
`password` varchar(50) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
; @0 A m1 V& n' _) a! L6 o `name` varchar(50) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,0 f7 I9 t5 P$ t; B- k! J+ w
`addr_id` int(11) NULL DEFAULT NULL,+ [* O8 ]- k6 M0 T- r5 s" P* D" b
PRIMARY KEY (`id`) USING BTREE,
% U$ w6 F/ M* b: `! v8 h' \' ^ INDEX `addr_id`(`addr_id`) USING BTREE' ^( e. i& v: S3 d( Z+ g7 Q
) ENGINE = InnoDB AUTO_INCREMENT = 3 CHARACTER SET = utf8 COLLATE = utf8_general_ci ROW_FORMAT = Compact;3 {. _. ~, v. n
0 l* f/ _, v$ p. C$ M# o) ~
1 L' ?2 \+ P8 H9 o
CREATE TABLE `type_time` (
7 \. ?2 k( I O, S8 \9 \ `id` int(11) NOT NULL AUTO_INCREMENT,1 L1 P7 i5 @8 e
`time` varchar(255) DEFAULT '[]',
! V: w6 I/ H X f! _7 w `name` varchar(100) DEFAULT '',
: f, ^% X! g; @# x! H0 u PRIMARY KEY (`id`),& |8 I% ~7 X: m1 s% T# i }
INDEX `name_time_index`(`name`,`time`) USING BTREE
+ ~5 ?. h: I% Q$ L& h& i ) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8: _1 }+ d& i7 s5 n# f9 E8 o8 G
3 y- H5 n0 @: f P6 O
一、id
* t* | ~* v0 I2 I& ]6 W) e: P( I$ w 每个 SELECT语句都会自动分配的一个唯一标识符.
3 \7 O2 ]$ r, B- E& W5 u/ [5 K- q 表示查询中操作表的顺序,有三种情况:
) ^- n6 f3 _' p id相同:执行顺序由上到下
& N7 f( ~- |4 ^0 t! | id不同:如果是子查询,id号会自增,id越大,优先级越高。* w, ~) N: v( y9 P5 f
id相同的不同的同时存在
8 r2 B; l, D# P7 i2 p$ e0 b. l id列为null的就表示这是一个结果集,不需要使用它来进行查询。3 @5 Y4 S8 o9 _7 U! V
& {( z6 R, k+ |( F+ w8 r# a$ L5 p 二、select_type
4 l( G) _" g* z! r# _* o7 ^
4 _) @1 w. Y! J- o3 I$ n+ m 查询类型,主要用于区别普通查询、联合查询(union、union all)、子查询等复杂查询* V _2 i; [( l0 M7 e
# `* i" [4 H5 A2 H, k/ ]& `" B1 S! l! W 2.1、simple
& j( | O. b0 |: }0 d F 表示不需要union操作或者不包含子查询的简单select查询。有连接查询时,外层的查询为simple* J3 C- ^/ V" ^) [* w) e# ]
2 o9 D `- b) `/ o) H: S1 K
EXPLAIN select * from user
* L' v1 e1 E5 T. N" w # `% M' D, r4 Z. Z
' k' x v$ a0 R, ?- U. s % m/ m% w; B* g1 q% ?4 q' {
EXPLAIN select u.id,u.addr_id,a.* from user u inner join taddr a on u.addr_id=a.id - w$ z4 d; w, Z+ H7 j
$ ^( t. i0 O$ W4 T% s" H
' L$ g( C* t8 q9 h: ^) y1 _5 w
2.2 primary# s8 Z" Z- W5 C! s: r
一个需要union操作或者含有子查询的select,位于最外层的单位查询的select_type为primary。, S/ E F0 V! Z5 L5 a
$ T0 O* K$ Z; F. B% M; Y explain select * from taddr t inner join (* U( K) D9 ~* ?
select addr_id from user ) u on t.id=u.addr_id1 M m4 Y) c, A: W7 N
/ T P" e1 V; [. {* a
explain select * from user u where u.addr_id =1q $ o* P& }) W% W4 g) M7 G
union all
3 d5 z9 @6 M" E3 V2 u1 \ select * from user u where u.addr_id =2 + i) [( t$ J3 m( u
, T/ O2 H& j8 |# d% d8 _5 {
, N" x v) `. X7 ^1 r% Q1 T
2.3 subquery* p9 Z( v& k4 @2 C. m7 h4 J3 N
除了from字句中包含的一查询外,其他地方出现的子查询都可能是subquery
8 i/ d7 I' P+ r( B1 O
$ z% Y4 z" P/ |: F 2.4 dependent subquery( M( i# t7 `; Z1 k5 D" Y- ]
/ \6 l7 Q; x3 [& ^1 k8 Y
与dependent union类似,表示这个subquery的查询要受到外部表查询的影响# p7 E$ e, z, Z* D$ Y' d, {
4 \) `! Y/ e4 b5 N6 c2 u explain select u.name,(select t.province from taddr t where u.addr_id=t.id) from user u: v! S0 H f! c$ h7 ~7 b5 ^8 y
$ w) t _- |$ }/ y/ k3 I9 }' B
2.5 union
7 V' O, P( M2 o8 M8 P0 \( b union连接的两个select查询,第⼀个查询是PRIMARY,除了第一个表外,第二个以后的表select_type都是union
6 D2 d ^8 {; `, R: Q" K$ y, e$ r8 J M ) L0 y( c2 M+ b4 ?8 x
三、table3 D0 M+ y4 s8 N. y# g6 p
显示的查询表名,如果查询使用了别名,那么这里显示的是别名
; U* E: T6 [2 _+ A3 z! C3 H 如果不涉及对数据表的操作,那么这显示为null
0 j9 s; U/ z; M: X1 A! W) k 如果显示为尖括号括起来的就表示这个是临时表,后边的N就是执行计划中的id,表示结果来自于这个查询产生。) W0 H: \4 v; A. E5 t
如果是尖括号括起来的<union M,N>,与类似,也是一个临时表,表示这个结果来自于union查询的id为M,N的结果集。5 f' B$ B H8 m: P- r' X; E8 B# z2 ~
9 j0 H, A3 m) {
四、type
M2 n/ `) d' I' x: m & d3 ?; u7 o, f- j
依次从好到差:
0 h$ B i, G4 P1 a, S& ]0 ]+ K6 `/ d0 w system,const,eq_ref,ref,fulltext,ref_or_null,unique_subquery,$ ^0 J3 _* c$ d2 n l% H! C
index_subquery,range,index_merge,index,ALL! O2 J# y' @: X" C5 M& u
+ P! v1 @4 s: L. e: x 除了all之外,其他的type都可以使⽤到索引,除了index_merge之外,其他的type只可以用到一个索引0 D* P" b4 O2 L0 g2 x8 t) p% x$ L. s/ t
# H- Q, `+ E1 m7 c/ @% q+ B) p
4、1 system( R. K; ]3 X5 p: \' z6 d! g+ j8 C
表中只有一行数据或者是空表。* ~; g0 _) s( E8 C4 v+ t
) \. x8 Y* m! ?+ _# l) F% T8 C: ^ P
4、2const
9 a: _' a$ t# r% x, T: M$ k 使用唯一索引或者主键,返回记录一定是1行记录的等值where条件时,通常type是const。其他数据库也叫做唯一索引扫描。 |" S7 p8 f9 x. r2 M
2 i" H: p# Q" s7 h$ _! v
4、3 eq_ref
5 x7 D: o m7 r5 N: S 关键字:连接字段主键或者唯一性索引。
7 ]' Q! D& T# M# G 此类型通常出现在多表的 join 查询, 表示对于前表的每一个结果, 都只能匹配到后表的一行结果. 并且查询的比较较操作通常是 ‘=’, 查询效率较高.
2 [# ]' O3 X% |7 {2 Y 4 Z, H% T5 t2 H& ]
EXPLAIN select u.id,u.addr_id,a.* from user u inner join taddr a on u.addr_id=a.id! t+ m0 Z W9 G0 f3 w6 H
' L2 u0 t% C _3 e5 A
& M3 m, Q/ V9 ]4 u
" t9 E4 s' m. J- ?( W; a . z. P" _# n7 f
5 Y/ d9 b( ~" ]* D* K
4、4 ref' X1 e, k5 J$ ?! X* `
针对非唯一性索引,使用等值(=)查询非主键。或者是使用了最左前缀规则索引的查询。
EXPLAIN select u.id,u.addr_id,a.* from taddr a left join user u on u.addr_id=a.id
4 d. w( U3 b% t- b; X
3 Y8 W+ Q: q4 k- C$ O/ Y 4.5 fulltext
7 [& f7 u N: r* @' t/ P3 R0 a 全文索引检索,要注意,全文索引的优先级很高,若全高索引和普通索引同时存在时,mysql不管代价,优先选择使用全文索引9 M$ y7 e& u; c, \. y. h
( c; C- f% Q7 s/ ~6 }0 m
4、6 unique_subquery2 X3 ^. {9 v) c+ m6 S7 B
用于where中的in形式子查询,子查询返回不重复值唯一值
$ T6 h; Y# z6 |8 E) d0 Z% u' Z# Q( |; s5 ~
2 ~8 j9 e6 g |+ j0 t 4、7 index_subquery
+ z! G3 D8 n Z' W5 m 用于in形式子查询使用到了辅助索引或者in常数列表,子查询可能返回重复值,可以使用索引将子查询去重。+ H8 `" @5 R9 v# g
* v5 t y7 i. y% _ 4、8 range; U% n2 M9 i# L
索引范围扫描,常用于使用>,<,is null,between ,in ,like等运算符的查询中。1 n0 i( l3 t" v/ p. @" t
: F# i" V3 s: m- X% t+ s1 f
explain select * from type_time a inner join (
. \0 d6 {3 b a7 z2 ^ select id from type_time where name =‘2’ and time in (‘2’,‘3’,‘4’) ) b on a.id=b.id2 z5 X" C& V$ H8 a3 s* o
+ w6 o# w5 R% K# u8 p9 h: c A5 e$ b8 `( u0 |' j. {5 x& W# Q
! R# S' c+ {( ~
6 |/ [8 _" b$ ]0 t 4、9 index
2 V2 `+ H6 ~3 ?" _ 键字:条件是出现在索引树中的节点的。可能没有完全匹配索引。
4 l' y k, _1 _/ a0 V 索引全表扫描,把索引从头到尾扫一遍,常用于使用索引列就可以处理不需要读取数据文件的查询、可以使使用索引排序或者分组的查询。3 X3 U' m% Y5 k) W8 v
6 e5 ]3 Q5 Q/ `7 R
explain select * from user group by addr_id7 Y/ }( Q6 |2 G* z) L" h. c! X
) ^8 U* n& i: T+ V9 z/ E( m' I
2 Y. S/ h- V1 a) Z) h/ r
$ B! \0 y( S7 f
2 `, i; C& I+ R: j! m
! M6 d5 y: x. b2 e0 M9 F; z# K! l% y
explain select addr_id from user, ^6 W6 Q2 @& j, e6 W4 f
5 f! m. |$ r7 }( [4 a p$ p) R1 i
! ?& ]/ ]. S! H# f/ o) H; N 4 p6 T0 e( ]( W# B
4 X G( y7 ] O! j2 R 4、10 all
9 ~/ a6 e% N) e9 Z# I 这个就是全表扫描数据文件,然后再在server层进行过滤返回符合要求的记录。
0 r7 L, x2 I5 N
% V- r$ F+ I" p: u 五、possible_keys
/ t1 B6 v- V6 a( Y ! ~* k# w7 q+ e+ U' S, A
此次查询中可能选用的索引,一个或多个( }; S+ c# b8 a, k
4 t( ]; ?7 @4 F D) d 六、key
% O, Q0 I) L* Y, N) F 查询真正使使用到的索引,select_type为index_merge时,这里可能出现两个以上的索引,其他的select_type这里只会出现一个。
$ ^1 B5 S6 f h* O) S' f 4 I' v% N, t1 r1 c. b% J0 K1 U: X
七、key_len
# W" b9 V9 Z7 ?. d" b" b9 i( M( i" c
, M0 S y5 K# A" S" Q8 j# H1 g" c 用于处理查询的索引长度度,如果是单列索引,那就整个索引长度算进去,如果是多列索引,那么查' ?6 {! d5 g9 O5 b J; I
询不一定都能使用到所有的列,具体使用到了多少个列的索引,这里就会计算进去,没有使用到的,这里不会计算进去。留意下这个列的值,算下你的多列索引总长度就知道有没有使用到所有的列了。
4 j' I; W. {# ~9 Q! [( j6 G 另外,key_len只计算where条件用到的索引长度,而排序和分组就算使用到了索引,也不会计算到key_len中。
0 v$ t9 X" _6 u" _) Z explain select id from type_time where name =‘2’ 用到长度303- _; r. c5 K# M* G
+ x, O0 A0 Z, K$ a+ W( Q. e
6 K+ Q1 D |0 C& ^ explain select id from type_time where name =‘2’ and time in (‘2’,‘3’,‘4’) 用到长度 1071
: y7 @9 d9 {- u0 ^/ O& N* Y . B N+ H% K" b
+ i# G: {/ h7 Z3 ?7 ] ! T8 `7 ?- {6 d$ [! Q
八、ref# s5 U) `4 ]9 \/ K- Z! X
如果是使用的常数等值查询,这里会显示const p3 @0 K) E. u1 {1 Y2 G) A9 T
如果是连接查询,被驱动表的执行计划这里会显示驱动表的关联字段
* R& Q9 _3 \( z M3 c5 a5 B5 E4 G* S 如果是条件使用了表达式或者函数,或者条件列发生了内部隐式转换,这里可能显示为func
8 I0 Q8 z0 s8 x5 H
8 U7 _6 T9 E c+ s5 U/ U& o. u 九、rows. \& [7 t, k! E* ]& z
这里是执行计划中估算的扫描行数,不是精确值(InnoDB不是精确的值,MyISAM是精确的值,主要原因是InnoDB使用了MVCC并发机制)1 E5 D. _: w5 Z' H5 z
; `( G" H/ C L' k i! j1 N
十、extra
' }( P# m' p$ t2 { B 这个列包含不适合在其他列中显示但十分重要的额外的信息,其中比较常见有一些:
?+ t$ @) u& Q
E! r) I" Z4 }- L6 X 10、1 using temporary, F& g0 b8 G+ d" B7 b; Z2 I2 R; J
表示使用了临时表存储中间结果。) L' u; o. {9 n, s
MySQL在对查询结果order by和group by时使用临时表
2 O" v2 N# c3 _0 ~ 临时表可以是内存临时表和磁盘临时表,执行计划中看不出来,需要查看status变量,4 x% B8 u( A7 {; a8 x% b
used_tmp_table,used_tmp_disk_table才能看出来。
& t' x7 n8 A7 [+ H9 y 8 a4 c6 ]( k/ L5 R( C% B. s2 a
explain select * from user u inner join taddr t on u.addr_id=t.id GROUP BY t.id
- J/ K* o6 A* A3 n . s$ y* ]% ^% |9 a7 T
& g8 X+ {3 B% x \' ?5 t
0 ~; a4 h* O8 G& B 10、2 using filesort
5 d# s# o4 g+ \6 l" [# P- N4 v 排序时无法使用到索引时,就会出现这个。常用于order by和group by语句中
7 s& ]) z! e4 c& t+ ^# {" Z % K2 J; x0 o6 X; p6 z+ h
说明MySQL会使用个外部的索引排序,而不是按照索引顺序进行读取。2 R, f- c$ ]$ C6 _; o9 C! v6 k
MySQL中无法利索引索引完成的排序操作称为“文件排序“; d7 s( a; U9 T) T! h! w/ v6 H& S
5 v ~8 N0 f1 D! z( }. B 10、3 using index
% n9 \# F. i$ E 查询时不需要回表查询,直接通过索引就可以获取查询的数据。; H) E4 s% J A" d! B0 P. V# j
表示相应的SELECT查询中使用到了覆盖索引(Covering Index),避免回表访问数据行,效率不* b S# Z, _; c/ D) S
错。
! T+ J% O' ^4 R+ A% w 如果同时出现Using Where ,说明索引被用来执行查找索引键值0 {. D9 e6 }: ]: Z
如果没有同时出现Using Where ,表明索引用来读取数据来执行查找动作。$ J7 r' r$ ]+ o6 O0 r+ _) J
7 t: w5 X& E* { 这里对索引的原理和explain做了一些介绍,需要索引需要建立之后对其改变查询方式可能会更能深刻理解 InnoDB 使用覆盖索引和非覆盖索引造成区别。这也是建立索引和使用sql需要特别考虑的问题。
1 y: m6 {4 c1 l9 S. `1 K$ l ————————————————
; A8 S c' R; u. V: r 版权声明:本文为CSDN博主「筏镜」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。, x; Q. ?. J! ?
原文链接:https://blog.csdn.net/fajing_feiyue/article/details/105616629' |* d8 {# k) O& Y p7 U! l
9 e2 m% u5 m0 O 1 P: n+ p# E S# T* n- v
zan