mysql索引

mongodb的默认存储引擎WiredTiger使用了B树索引 mysql的默认存储引擎InnoDB索引使用了B+树实现，那么各自为什么这样实现呢？ 二叉搜索树 如上图是一个简单的二叉搜索树，是最为大家熟知的一种数据结构，它为什么不适合用作数据库索引？ （1）当数据量大的时候，树的高度会比较高，数据量大的时候，查询会比较慢 （2）每个节点只存储一个记录，可能导致一次查询有很多次磁盘IO B树 B树的特点是： （1）不再是单纯的二叉而是m叉 （2）叶子节点，非叶子节点，都存储数据 （3）中序遍历，可以获得所有节点 （4） 非根节点包含的关键字个数j满足， (┌m/2┐)-1 <= j <= m-1 ，节点分裂时要满足这个条件。 B+树 B+树，如上图，仍是m叉搜索树，在B树的基础上，做了一些改进： （1）非叶子节点不再存储数据，数据只存储在同一层的叶子节点上；B+树种 根到每一个节点的路径长度一样，而B树不是这样 （2）叶子之间，增加了链表，获取所有节点，不再需要中序遍历 这些改进让B+树比B树有更优的特性： （1）范围查找，定位min与max之后，中间叶子节点，就是结果集，不用中序回溯；范围查询在SQL中用得多，这是B+树比B树最大的优势。 （2）叶子节点存储实际记录行，记录行相对比较紧密的存储，适合大数据量磁盘存储；非叶子节点存储记录的PK，用于查询加锁，适合内存存储。 （3

Reference： https://time.geekbang.org/column/article/117247 死锁产生 行锁的具体实现算法有三种：record lock、gap lock以及next-key lock。 record lock是专门对索引项加锁； gap lock是对索引项之间的间隙加锁； next-key lock则是前面两种的组合，对索引项及其之间的间隙加锁。 只在可重复读或以上隔离级别下的特定操作才会取得gap lock或next-key lock，在Select、Update和Delete时，除了基于唯一索引的查询之外，其它索引查询时都会获取gap lock或next-key lock，即锁住其扫描的范围。主键索引也属于唯一索引，所以主键索引是不会使用gap lock或next-key lock。 在MySQL中，gap lock默认是开启的，即innodb_locks_unsafe_for_binlog参数值是disable的，且MySQL中默认的是RR事务隔离级别。 当执行以下查询SQL时，由于order_no列为非唯一索引，此时又是RR事务隔离级别，所以SELECT的加锁类型为gap lock，这里的gap范围是(4,+∞）。 1 SELECT id FROM demo.order_record where order_no = 4 for

参考了这篇文章： http://www.cnblogs.com/LBSer/p/5183300.html 《 mysql死锁问题分析 》 写的不错。 如果Mysql死锁，会报出： 1.1 死锁成因&&检测方法 我们mysql用的存储引擎是innodb，从日志来看，innodb主动探知到死锁，并回滚了某一苦苦等待的事务。问题来了，innodb是怎么探知死锁的？ 直观方法是在两个事务相互等待时，当一个等待时间超过设置的某一阀值时，对其中一个事务进行回滚，另一个事务就能继续执行。这种方法简单有效，在innodb中，参数innodb_lock_wait_timeout用来设置超时时间。 仅用上述方法来检测死锁太过被动，innodb还提供了 wait-for graph算法 来主动进行死锁检测，每当加锁请求无法立即满足需要并进入等待时，wait-for graph算法都会被触发。 1.2 innodb隔离级别、索引与锁 1.2.1 锁与索引的关系 假设我们有一张消息表（msg），里面有3个字段。假设id是主键，token是非唯一索引，message没有索引。 id: bigint token: varchar(30) message: varchar(4096) innodb对于主键使用了 聚簇索引 ，这是一种数据存储方式，表数据是和主键一起存储，主键索引的叶结点存储行数据。对于普通索引

存储引擎 存储引擎是指定在表之上的，即一个库中的每一个表都可以指定专用的存储引擎 。 不管表采用什么样的存储引擎，都会在数据区，产生对应的一个frm文件(表结构定义描述文件) 。 在新版本中frm文件已经被mysql舍弃 CSV存储引擎 为其添加索引时报错 Too many keys specified; max 0 keys allowed 为其添加默认为null的列时 提示 The storage engine for the table doesn't support nullable columns 因此，CSV引擎的表不能定义索引，列定义必须是NOT NULL,不能设置自增列 CSV数据的存储是用,隔开，可直接编辑CSV文件进行数据的插入或删除；编辑之后，要生效使用flush table xxx; Create Table : CREATE TABLE ` csv_name ` ( ` name ` varchar ( 10 ) NOT NULL , ` age ` tinyint ( 4 ) NOT NULL ) ENGINE = CSV DEFAULT CHARSET = utf8mb4 COMMENT = 'csv 测试' //插入操作 insert into csv_name values ( "wojiushiwo" , 2 ) ; insert into

简答题 1.MySQL常见的三种存储引擎（InnoDB、MyISAM、MEMORY）的区别(至少5点)？ l InnoDB存储引擎 InnoDB是事务型数据库的首选引擎，支持事务安全表（ACID），其它存储引擎都是非事务安全表，支持行锁定和外键，MySQL5.5以后默认使用InnoDB存储引擎。 InnoDB主要特性 为MySQL提供了具有提交、回滚和崩溃恢复能力的事务安全（ACID兼容）存储引擎。InnoDB锁定在行级并且也在 SELECT语句中提供一个类似Oracle的非锁定读。这些功能增加了多用户部署和性能。在SQL查询中，可以自由地将InnoDB类型的表和其他MySQL的表类型混合起来，甚至在同一个查询中也可以混合。 。 l MyISAM存储引擎 MyISAM基于ISAM存储引擎，并对其进行扩展。它是在Web、数据仓储和其他应用环境下最常使用的存储引擎之一。MyISAM拥有较高的插入、查询速度，但不支持事务，不支持外键。 MyISAM主要特性： 被大文件系统和操作系统支持。 当把删除和更新及插入操作混合使用的时候，动态尺寸的行产生更少碎片。这要通过合并相邻被删除的块，若下一个块被删除，就扩展到下一块自动完成。 每个MyISAM表最大索引数是64，这可以通过重新编译来改变。每个索引最大的列数是16。 最大的键长度是1000字节，这也可以通过编译来改变

应用程序慢如牛，原因多多，可能是网络的原因、可能是系统架构的原因，还有可能是数据库的原因。 那么如何提高数据库SQL语句执行速度呢？有人会说性能调优是数据库管理员（DBA）的事，然而性能调优跟程序员们也有莫大的关系。 程序中嵌入的一行行的SQL语句，如果使用了一些优化小技巧，定能达到事半功倍的效果。 技巧一：比较运算符能用“=”就不用“<>” “=”增加了索引的使用几率。 技巧二：明知只有一条查询结果，那请使用“LIMT 1” ”LIMT 1“可以避免全表扫描，找到对应结果就不会再继续扫描了。 技巧三：为列选择合适的数据类型 能用TINYINT就不用SMALLINT，能用SMALLINT就不用INT，磁盘和内存消耗的越小越好。 技巧四：将大的DELETE UPDATE OR INSERT 查询变成多个小查询 技巧五：使用UNION ALL 代替UNION，如果结果集允许重复的话。 因为UNION ALL不去重，效率高于UNION。 技巧六：为获取相同结果集的多次执行，请保持sql语句前后一致。 为了充分利用查询缓存。 * 技巧七：尽量避免使用“SELECT ” 其不能有效利用索引，增大了数据库服务器的负担，以及它与应用程序客户端之间网络IO开销。 技巧八：WHERE子句里面的列尽量被索引 索引太多也会降低性能。 技巧九：JOIN子句里面的列尽量被索引 技巧十：ORDER

背景 dba的日常工作肯定有一项是ddl变更，ddl变更会锁表，这个可以说是dba心中永远的痛，特别是执行ddl变更，导致库上大量线程处于“Waiting for meta data lock”状态的时候。因此mysql 5.6的online ddl特性是dba们最期待的新特性，这个特性解决了执行ddl锁表的问题，保证了在进行表变更时，不会堵塞线上业务读写，保障在变更时，库依然能正常对外提供访问。网上关于online ddl的文章很多，但涉及原理的很少，都是介绍语法之类的，本文将详细介绍online ddl的原理，知其然，更要知其所以然。 ddl实现方式 5.6 online ddl推出以前，执行ddl主要有两种方式copy方式和inplace方式，inplace方式又称为(fast index creation)。相对于copy方式，inplace方式不拷贝数据，因此较快。但是这种方式仅支持添加、删除索引两种方式，而且与copy方式一样需要全程锁表，实用性不是很强。下面以加索引为例，简单介绍这两种方式的实现流程。 copy方式 (1).新建带索引的临时表 (2).锁原表，禁止DML，允许查询 (3).将原表数据拷贝到临时表(无排序，一行一行拷贝) (4).进行rename，升级字典锁，禁止读写 (5).完成创建索引操作 inplace方式 (1).新建索引的数据字典 (2).锁表

一 什么是驱动表 1）指定了联接条件时，满足查询条件的记录行数少的表为[驱动表]； 2）未指定联接条件时，行数少的表为[驱动表]（Important!）。 表现 explain第一行出现的就是驱动表 二 多表查询的分类 1 多表join查询 2 多表join+子查询 三 驱动表的分类 1 单表 单表执行顺序有2种情况 1 单表先执行条件过滤,结算出结果再进行关联join 2 单表先进行关联join,再结果进行条件过滤 可以根据explain驱动表的索引选择进行判断是根据哪种情况执行 1 选择条件索引,先过滤 2 选择连接字段索引,先关联 2 派生表 explain->type-><derived>名称 即为派生表 eg SELECT column_list FROM (SELECT column_list FROM table_1) derived_table_nameWHERE derived_table_name.column > 1 注意 执行的是 select from之后 where和join之前的语句 执行顺序 1 执行子查询的内容 2 把子查询的结果写到临时表中 3 回读,应用上层SELECT的WHERE条件 四 多表查询几点注意 1 对驱动表可以直接排序，对非驱动表（的字段排序）需要对循环查询的合并结果（临时表）进行排序 2 一旦连接字段没有应用索引

原因：性能低、执行时间长、等待时间长、SQL语句欠佳（连接查询）、索引失效、服务器参数不合理（缓冲、多线程）； 　　1.SQL:　　 　　　　　　编写过程 select ... from ... join ... on ... where ... group by ... having ... order by ... limit ...; 　　　　　　解析过程 from ... on ... join ... where ... group by ... having ... select ... order by ... limit ...; 　　2.SQL优化，主要就是优化索引 　　　　索引：index是帮助MYSQL高效获取数据的数据结构，索引熟数据结构（树：B树(默认)、Hash树...） 　　　　索引的弊端： 　　　　　　　　1.索引本身就很大，可以存放在内存/硬盘（通常为硬盘） 　　　　　　　　2.索引本身不是所有情况都适用　　a.少量数据 　　b.频繁更新的字段 　　c.很少使用的字段 　　　　　　　　3.索引会降低增删改的效率 　　　　索引的优势： 　　　　　　　　1.提高查询的效率（降低了IO）的使用率 　　　　　　　　2.降低cpu的使用率（因为B树索引本来就是排好序的，所以可以直接使用） 来源： https://www.cnblogs.com

MySQL 查询优化之 Block Nested-Loop 与 Batched Key Access Joins 在MySQL中，可以使用批量密钥访问（BKA）连接算法，该算法使用对连接表的索引访问和连接缓冲区。 BKA算法支持 ：内连接，外连接和半连接操作，包括嵌套外连接。 BKA的优点 ：更加高效的表扫描提高了连接性能。 此外，先前仅用于内连接的块嵌套循环（BNL）连接算法现已扩展，可用于 外连接 和 半连接 操作，包括 嵌套外连接 。 以下部分讨论了连接缓冲区管理，它是原始BNL算法扩展，扩展BNL算法和BKA算法的基础。 有关半连接策略的信息，请参见 “使用半连接转换优化子查询，派生表和视图引用” Nested Loop Join 算法 Block Nested-Loop 算法 Batched Key Access 算法 BNL和BKA算法的优化器Hint Nested Loop Join算法 将外层表的结果集作为循环的基础数据，然后循环从该结果集每次一条获取数据作为下一个表的过滤条件去查询数据，然后合并结果。如果有多个表join，那么应该将前面的表的结果集作为循环数据，取结果集中的每一行再到下一个表中继续进行循环匹配，获取结果集并返回给客户端。 伪代码如下 ： for each row in t1 matching range { for each row in t2