mysql索引

MySQL索引以及优化总结 B树和B+树结构 MyISAM与InnoDB 的存储区别 索引的本质 联合索引（最左前缀匹配原则） B树和B+树结构 MySQL为什么要用B+树：与二叉树和红黑树不同的是B树的节点上可以存放多个索引，这样降低了树的高度，使得查询效率更高。B+树在B树的基础上加以改进，父节点存放冗余索引，叶子节点存放所有的索引和数据（可能是索引对应行数据的文件地址或，也可能是整行数据），并且节点之间通过指针相互关联，查询效率进一步提升。 MyISAM与InnoDB 的存储区别 InnoDB 是聚集索引，数据文件是和索引绑在一起的，必须要有主键，通过主键索引效率很高，但是辅助索引需要两次查询，先查询到主键，然后再通过主键查询到数据。因此，主键不应该过大，否则其他索引也会很大。而 MyISAM 是非聚集索引，数据文件是分离的，索引保存的是数据文件的指针，主键索引和辅助索引是独立的。 索引的本质 为什么索引一般选用tree而不用hash：因为hash只使用与指定值的查找而范围查找就需要全表扫描。 联合索引（最左前缀匹配原则） 最左前缀匹配原则，是一个非常重要的原则，可以通过以下这几个特性来理解。 1、对于联合索引，MySQL 会一直向右匹配直到遇到范围查询（> ， < ，between，like）就停止匹配。比如 a = 3 and b = 4 and c > 5 and d

1) 没有查询条件，或者查询条件没有建立索引 2) 在查询条件上没有使用引导列 3) 查询的数量是大表的大部分，应该是30％以上。 4) 索引本身失效 5) 查询条件使用函数在索引列上，或者 对索引列进行运算， 运算包括(+，-，*，/，! 等) 错误的例子：select * from test where id-1=9; 正确的例子：select * from test where id=10; 6) 对小表查询 7) 提示不使用索引 8) 统计数据不真实 9) CBO计算走索引花费过大的情况。其实也包含了上面的情况，这里指的是表占有的block要比索引小。 10)隐式转换导致索引失效.这一点应当引起重视.也是开发中经常会犯的错误. 由于表的字段tu_mdn定义为varchar2(20),但在查询时把该字段作为number类型以where条件传给Oracle,这样会导致索引失效. 错误的例子：select * from test where tu_mdn=13333333333; 正确的例子：select * from test where tu_mdn='13333333333'; 12) 1,<> 2,单独的>,<,(有时会用到，有时不会) 13,like "%_" 百分号在前. 4,表没分析. 15,单独引用复合索引里非第一位置的索引列. 16

索引目的 索引的目的在于提高查询效率，可以类比字典，如果要查“mysql”这个单词，我们肯定需要定位到m字母，然后从下往下找到y字母，再找到剩下的sql。如果没有索引，那么你可能需要把所有单词看一遍才能找到你想要的，如果我想找到m开头的单词呢？或者w开头的单词呢？是不是觉得如果没有索引，这个事情根本无法完成？ 索引原理 除了词典，生活中随处可见索引的例子，如火车站的车次表、图书的目录等。它们的原理都是一样的，通过不断的缩小想要获得数据的范围来筛选出最终想要的结果，同时把随机的事件变成顺序的事件，也就是我们总是通过同一种查找方式来锁定数据。 数据库也是一样，但显然要复杂许多，因为不仅面临着等值查询，还有范围查询(>、<、between、in)、模糊查询(like)、并集查询(or)等等。数据库应该选择怎么样的方式来应对所有的问题呢？我们回想字典的例子，能不能把数据分成段，然后分段查询呢？最简单的如果1000条数据，1到100分成第一段，101到200分成第二段，201到300分成第三段……这样查第250条数据，只要找第三段就可以了，一下子去除了90%的无效数据。但如果是1千万的记录呢，分成几段比较好？稍有算法基础的同学会想到搜索树，其平均复杂度是lgN，具有不错的查询性能。但这里我们忽略了一个关键的问题，复杂度模型是基于每次相同的操作成本来考虑的，数据库实现比较复杂，数据保存在磁盘上

前言 工作的这些年发现一个比较奇怪的现象就是身边无论是工作十多年的老兵，还是初级刚入行的程序员，在高谈阔论技术和趋势的时候都是人工智能，大数据，区块链，各种框架，语言，算法，AI，BI，CI，DI…… 等等，倒是发现很少有人关注数据库，不知道是因为数据库感觉太低端还是太低调，总是不容易被人提起 技术就是这样，不太关注的地方就不会重视，越是不被重视的地方，掉进坑里的概率就会越大，所以就在这里给大家简单聊聊在使用数据库过程中有哪些防掉坑指南，也可以对刚入行的小朋友有一个提醒的作用，万丈高楼平地起，一定要先打好基础再去考虑上层的建筑，不要舍本逐末 本章主要分以下四个小节（预计读完 5 分钟左右）： 数据库为什么重要 数据库有哪些使用技巧 数据库有哪些容易掉进去的坑？ 深入学习数据库的建议 数据库为什么重要 很多人在开发过程中不太关注数据库，对于表结构的设计也没什么讲究大多属于“能用就行”，但是根据作者将近十年的开发经验来看的话，只要你是从事 Web 相关领域开发你就无法避免不和数据库打交道， 在Web开发中大多功能操作本质上都是对数据库进行操作 ，不管你用是 Pythod，Java，Ruby 等语言进行 Web 开发，你其实都是在面向数据库进行编程，很多 Web 框架作者为了避免程序员接触数据库的相关知识甚至还封装了一层 ORM （Object Relational Mapping

哈希索引：通过对键值进行一定的哈希算法得到新的哈希值，检索时不需要像btree那样从根节点到叶子节点逐级查找，而是通过哈希算法就可以快速定位到位置 btree和哈希结构的比较： 1、哈希结构的索引适合等值查询，前提是值唯一，因为会出现哈希碰撞的情况，就会导致找到具体的位置后，还得扫描链表 2、哈希结构不适合范围查找，原本有序的磁盘数据经过键值的哈希算法后可能试键值出现不连续，导致不能范围查找 3、哈希机构不适合排序、模糊查询、分组查询，因为这些本质上是范围查询 4、哈希结构不能遵循复合索引的最左原则 B-tree索引：是一个多路平衡搜索树，和二叉树的区别是二叉树每个节点只允许有两个子节点，而btree可以有多个节点 其特点是： 1、所有键值分布在整棵树中 2、任何一个关键字出现且只出现在一个节点中 3、一次查询可能未到叶子节点就可以查询结束，因为真实数据也存储在非叶子节点；性能逼近二分查找 B+tree也是一种多路平衡搜索树，它和B-tree的区别是： 1、B+tree存储的真实数据只在叶子节点 2、为所有叶子节点增加了一个链指针 为什么使用B+tree 1、B+树更适合外部存储,由于内节点无 data 域,一个结点可以存储更多的内结点,每个节点能索引的范围更大,也意味着 B+树单次磁盘IO的信息量大于B-树,I/O效率更高。 2、Mysql是一种关系型数据库

在日常工作中，我们会有时会开慢查询去记录一些执行时间比较久的SQL语句，找出这些SQL语句并不意味着完事了，些时我们常常用到explain这个命令来查看一个这些SQL语句的执行计划，查看该SQL语句有没有使用上了索引，有没有做全表扫描，这都可以通过explain命令来查看。所以我们深入了解MySQL的基于开销的优化器，还可以获得很多可能被优化器考虑到的访问策略的细节，以及当运行SQL语句时哪种策略预计会被优化器采用。 -- 实际SQL，查找用户名为Jefabc的员工 select * from emp where name = 'Jefabc'; -- 查看SQL是否使用索引，前面加上explain即可 explain select * from emp where name = 'Jefabc'; expain出来的信息有10列，分别是id、select_type、table、type、possible_keys、key、key_len、ref、rows、Extra 概要描述： id:选择标识符 select_type:表示查询的类型。 table:输出结果集的表 partitions:匹配的分区 type:表示表的连接类型 possible_keys:表示查询时，可能使用的索引 key:表示实际使用的索引 key_len:索引字段的长度 ref:列与索引的比较 rows

文章目录 缓存 memcache的分布式原理 memcache的内存分配机制 如何存放数据到memcached缓存中？（memcache内存分配机制） memcache的惰性失效机制 memcache缓存的无底洞现象 一致性Hash算法的实现原理 Hash环 一致性Hash算法 Hash环的倾斜 虚拟节点解决Hash环倾斜 hash算法平衡性 memcached与redis的区别 Redis的主从复制 Redis的部分复制过程 Redis的主从复制阻塞模式 Redis的数据持久化方式 Redis的高可用部署方式 哨兵模式 Redis哨兵主要功能 Redis哨兵的高可用 哨兵如何判断redis主从节点是否正常？ 集群模式 Redis可以在线扩容吗？zk呢 Redis高并发和快速的原因 浏览器本地缓存的了解和使用 缓存雪崩 缓存穿透 HashMap HashMap的Hash碰撞 HashMap的get和put原理 HashMap的rehash HashMap的线程不安全问题 HashMap和Hashtable的区别 为什么collection没有实现clonable接口 为什map没有实现collection接口 Map接口的实现有哪些,区别是什么 线程池 Executors框架的四种线程池及拒绝策略 四种线程池 JDK拒绝策略 Reactor模式 Reactor单线程模型

1 索引的常见模型 1.1 哈希表 哈希表是一种以键-值（key-value)存储数据的结构，只要输入待查找的键key, 就可以找到对应的值value。 哈希表适用于做等值查询（即查找的key值在表中有对应），但是哈希索引做区间查询的速度是很慢的 1.2 有序数组 查找数据的时间复杂度是O(log(N))。仅看查询效率，有序数组是一种非常好的数据结构，但是更新数据比较慢，因为要做数据的挪动工作。所以，有序数据只适用于静态存储引擎。 1.3 N叉搜索树 多叉树就是每个结点有多个儿子，儿子之间的大小保证从左到右递增。二叉搜索树效率是最高的，但是实际大多数的数据库存储并不使用二叉树，原因是，索引不止存在内存中，还要写到磁盘上。为了尽量少地读磁盘，一般使用N叉树。N取决于数据块的大小。 2 InnoDB的索引模型 2.1主键索引与非主键索引 在InnoDB中，表都是根据主键顺序以索引的形式存放的，这种存储方式称为索引组织表。InnoDB使用B+树索引模型，所以数据都是存储在B+树中的。 索引类型分为 主键索引 和 非主键索引 。 主键索引 的叶子结点是整行数据。在InnoDB中，主键索引也被称为聚簇索引（clustered index）。 非主键索引 的叶子结点是主键的值。在InnoDB中，非主键索引也被称为二级索引。 2.2 索引维护 自增主键是指自增列上定义的主键，在建表语句中一般是

一、SQL语句优化 （1）使用limit对查询结果的记录进行限定 （2）避免select *，将需要查找的字段列出来 （3）使用连接（join）来代替子查询 （4）拆分大的delete或insert语句 二、选择合适的数据类型 （1）使用可存下数据的最小的数据类型，整型 < date,time < char,varchar < blob （2）使用简单的数据类型，整型比字符处理开销更小，因为字符串的比较更复杂。如，int类型存储时间类型，bigint类型转ip函数 （3）使用合理的字段属性长度，固定长度的表会更快。使用enum、char而不是varchar （4）尽可能使用not null定义字段 （5）尽量少用text，非用不可最好分表 三、选择合适的索引列 （1）查询频繁的列，在where，group by，order by，on从句中出现的列 （2）where条件中<，<=，=，>，>=，between，in，以及like 字符串+通配符（%）出现的列 （3）长度小的列，索引字段越小越好，因为数据库的存储单位是页，一页中能存下的数据越多越好 （4）离散度大（不同的值多）的列，放在联合索引前面。查看离散度，通过统计不同的列值来实现，count越大，离散程度越高： mysql> SELECT COUNT(DISTINCT column_name) FROM table_name;

MySQL5.5后，默认存储引擎是InnoDB，5.5之前默认是MyISAM。 InnoDB（事务性数据库引擎）和MyISAM的区别补充： InnoDB是聚集索引，数据结构是B+树，叶子节点存K-V，V存的是 数据页 。MyISAM是非聚集索引，V上存的是主键值，查到后还需要再聚集索引上再查一次。 InnoDB是具有事务(commit)、回滚(rollback)和崩溃修复能力(crash recovery capabilities)的事务安全(transaction-safe (ACID compliant))型表。适合存在大量insert、update场景。 MyISAM强调的是性能，不支持事务，最大缺陷就是崩溃后无法安全恢复，更适合读密集的小型应用。 只有InnoDB支持MVCC（多版本控制）。应对高并发事务, MVCC比单纯的加锁更高效，所以InnoDB更适合高并发场景。 常用命令 //查所有引擎 mysql> show engines; //查当前引擎 mysql> show variables like '%storage_engine%'; 来源： https://www.cnblogs.com/ChengzhiYang/p/12402630.html