mariadb的explain分析及InnoDB存储引擎

id: 当前查询语句中,每个SELECT语句的编号,     id: 1  表示简单类型的查询

  复杂类型的查询有三种:简单子查询,用于FROM中的子查询,联合查询:UNION

  注意:UNION查询的分析结果会出现一张额外匿名临时表

select_type:

    简单查询为SIMPLE

    复杂查询:

        SUBQUERY: 简单子查询

            DERIVED: 用于FROM中的子查询    

        UNION:UNION语句的第一个之后的SELECT语句

        UNION RESULT: 匿名临时表 

简单子查询示例:

    PRIMARY:主查询或整个查询语句的最外层查询

    SUBQUERY:用在where子句中的子查询

联合查询示例:

table:SELECT语句关联到的表

type:关联类型,或访问类型,即MariaDB决定的如何去查询表中的行的方式

    ALL: 全表扫描

    index:根据索引的次序进行全表扫描;如果在Extra列出现“Using index”表示了使用覆盖索引,而非全表扫描

      range:有范围限制的根据索引实现范围扫描;扫描位置始于索引中的某一点,结束于另一点

    ref: 根据索引返回表中匹配某单个值的所有行

    eq_ref:仅返回一行,但需要额外与某个参考值做比较

    const, system: 直接返回单个行

    性能从上到下依次提升

possible_keys:查询可能会用到的索引

key: 查询中使用了的索引

key_len: 在索引中使用的字节数

ref: 在利用key字段所表示的索引完成查询时所有的列或某常量值

rows:MariaDB估计为找所有的目标行而需要读取的行数

Extra:额外信息

    Using index:MySQL将会使用覆盖索引,以避免访问表

    Using where:MySQL服务器将在存储引擎检索后,再进行一次过滤

    Using temporary:MySQL对结果排序时会使用临时表

    Using filesort:对结果使用一个外部索引排序

InnoDB:

  处理大量的短期事务

  数据存储于“表空间(table space)”中

    (1) 所有InnoDB表的数据和索引放置于同一个表空间中

      表空间文件:datadir定义的目录下

        数据文件:ibddata1, ibddata2, ...

    (2) 每个表单独使用一个表空间存储表的数据和索引

      innodb_file_per_table=ON   查看是否开启(show global variables like ‘innodb_file_%‘;)

      数据文件(存储数据和索引):tbl_name.ibd

      表格式定义:tbl_name.frm

lock table students read; 只允许对students表查询(不过仍然可以从缓存中取数据)   释放:unlock table;

lock table students write;  连查询请求都不允许

      

时间: 2024-08-10 19:18:46

mariadb的explain分析及InnoDB存储引擎的相关文章

MySQL内核:InnoDB存储引擎 卷1

MySQL内核:InnoDB存储引擎卷1(MySQL领域Oracle ACE专家力作,众多MySQL Oracle ACE力捧,深入MySQL数据库内核源码分析,InnoDB内核开发与优化必备宝典) 姜承尧 蒋鸿翔 饶珑辉 温正湖 著   ISBN 978-7-121-22908-4 2014年5月出版 定价:69.00元 360页 16开 编辑推荐 预售前100位读者送MySQL 5.6 InnoDB存储引擎的架构图 l  <高性能MySQL>配套深度阅读数据库内核解析篇 l  网易资深数据

MySQL数据库InnoDB存储引擎多版本控制(MVCC)实现原理分析

文/何登成 导读:   来自网易研究院的MySQL内核技术研究人何登成,把MySQL数据库InnoDB存储引擎的多版本控制(简称:MVCC)实现原理,做了深入的研究与详细的文字图表分析,方便大家理解InnoDB存储引擎实现的多版本控制技术(简称:MVCC). 基本知识 假设对于多版本控制(MVCC)的基础知识,有所了解.MySQL数据库InnoDB存储引擎为了实现多版本的一致性读,采用的是基于回滚段的协议. 行结构 MySQL数据库InnoDB存储引擎表数据的组织方式为主键聚簇索引.由于采用索引

[MySQL Reference Manual]14 InnoDB存储引擎

14 InnoDB存储引擎 14 InnoDB存储引擎... 1 14.1 InnoDB说明... 5 14.1.1 InnoDB作为默认存储引擎... 5 14.1.1.1 存储引擎的趋势... 5 14.1.1.2 InnoDB变成默认存储引擎之后... 5 14.1.1.3 InnoDB表好处... 6 14.1.1.4 InnoDB表最佳实践... 6 14.1.1.5 InnoDB表提升... 6 14.1.1.6 InnoDB作为默认存储引擎测试... 6 14.1.1.7 验证In

InnoDB存储引擎介绍-(4)Checkpoint机制二

原文链接 http://www.cnblogs.com/chenpingzhao/p/5107480.html 一.简介 思考一下这个场景:如果重做日志可以无限地增大,同时缓冲池也足够大,那么是不需要将缓冲池中页的新版本刷新回磁盘.因为当发生宕机时,完全可以通过重做日志来恢复整个数据库系统中的数据到宕机发生的时刻. 但是这需要两个前提条件:1.缓冲池可以缓存数据库中所有的数据:2.重做日志可以无限增大 因此Checkpoint(检查点)技术就诞生了,目的是解决以下几个问题:1.缩短数据库的恢复时

关于InnoDB存储引擎text和blob类型的优化

我们在数据库优化的时候,看到一些表在设计上使用了text或者blob的字段,如果单表的存储空间达到了近上百G或者大几十G,这种情况再去改变和优化就非常难了 一.简介 为了清楚大字段对性能的影响,我们有必要知道innodb存储引擎的处理方式: 1.一些知识点 1.1 在InnoDB 1.0.x版本之前,InnoDB 存储引擎提供了 Compact 和 Redundant(Redundant 格式是为兼容之前版本而保留的) 两种格式来存放行记录数据,compact 和 redundant 合称为An

mysql中InnoDB存储引擎的行锁和表锁

Mysql的InnoDB存储引擎支持事务,默认是行锁.因为这个特性,所以数据库支持高并发,但是如果InnoDB更新数据的时候不是行锁,而是表锁的话,那么其并发性会大打折扣,而且也可能导致你的程序出错. 而导致行锁变为表锁的情况之一就是: SQL的更新(update)或者删除(delete)语句中未使用到索引,导致在InnoDB在对数据进行相应操作的时候必须把整个表锁起来进行检索(表锁).而如果使用了索引的话,InnoDB只会通过索引条件检索数据,而只锁住索引对应的行(行锁). 下面记录一下我遇到

MySQL 温故而知新--Innodb存储引擎中的锁

近期碰到非常多锁问题.所以攻克了后,细致再去阅读了关于锁的书籍,整理例如以下:1,锁的种类 Innodb存储引擎实现了例如以下2种标准的行级锁: ? 共享锁(S lock),同意事务读取一行数据. ?  排它锁(X lock).同意事务删除或者更新一行数据. 当一个事务获取了行r的共享锁.那么另外一个事务也能够马上获取行r的共享锁,由于读取并未改变行r的数据.这样的情况就是锁兼容. 可是假设有事务想获得行r的排它锁,则它必须等待事务释放行r上的共享锁-这样的情况就是锁不兼容.二者兼容性例如以下表

mysql技术内幕InnoDB存储引擎-阅读笔记

mysql技术内幕InnoDB存储引擎这本书断断续续看了近10天左右,应该说作者有比较丰富的开发水平,在源码级别上分析的比较透彻.如果结合高可用mysql和高性能mysql来看或许效果会更好,可惜书太厚,还在啃当中,希望能早点读完……. 应该说与oracle相比,mysql数据库还是相对比简单,以后还是深入学习下oracle去. 搞数据库也比搞应用运维相对单纯,不用知道各种应用架构,不用写各种脚本工具,只要掌握这个软件就足够了.当然希望自己的知识还是全面一些好.

MySQL:InnoDB存储引擎的B+树索引算法

很早之前,就从学校的图书馆借了MySQL技术内幕,InnoDB存储引擎这本书,但一直草草阅读,做的笔记也有些凌乱,趁着现在大四了,课程稍微少了一点,整理一下笔记,按照专题写一些,加深一下印象,不枉读了一遍书.与此同时,也加深一下对MySQL的了解,认识了原理,对优化的原则才有把握,对问题的分析才有源头. 关于B+树数据结构 ①InnoDB存储引擎支持两种常见的索引. 一种是B+树,一种是哈希.B+树中的B代表的意思不是二叉(binary),而是平衡(balance),因为B+树最早是从平衡二叉树