mysql索引

前言 读这篇文章之前可以先了解一下 MySQL中InnoDB数据结构 一、InnoDB引擎对隔离级别的支持 事务隔离级别 脏读 不可重复读 幻读 读未提交（read-uncommitted） 可能 可能 可能 不可重复读（read-committed） 不可能 可能 可能 可重复读（repeatable-read） 不可能 不可能 InnoDB不可能 串行化（serializable） 不可能 不可能 不可能 隔离级别到底如何实现？ 二、锁的介绍 1、表锁、行锁 通过锁来管理不同事务对共享资源的并发访问 表锁与行锁的区别： 锁定粒度：表锁 > 行锁 加锁效率：表锁 > 行锁 冲突概率：表锁 > 行锁 并发性能：表锁 < 行锁 InnoDB存储引擎只支持行锁，表锁是通过锁住所有行实现 2、InnoDB锁类型 共享锁（行锁，又称S锁）：Shared Locks 又称为读锁，简称S锁，顾名思义，共享锁就是多个事务对于同一数据可以共享一把锁， 都能访问到数据，但是只能读不能修改。 select * from teachers WHERE id = 1 LOCK IN SHARE MODE ; commit / rollback 排它锁（行锁，又称X锁）：Exclusive Locks 又称为写锁，简称X锁，排他锁不能与其他锁并存，如一个事务获取了一个数据行的排他 锁

一、单表 创建索引之前：type=ALL全表扫描，Extra里面的Using filesort(文件内部排序) 根据where后面的条件创建 ： CREATE INDEX idx_article_ccv ON article(category_id,comments,views); 可以看出type由ALL变成了range,但是Extra里面的Using filesort(文件内部排序)未解决 此时删除索引 : DROP INDEX idx_article_ccv ON article; 重新建立 ： CREATE INDEX idx_article_ccv ON article(category_id,views); 此时完美解决！！ 二、双表 创建索引之前：type=ALL全表扫描 此时有两个表，里面都有字段card,但是现在不知道应该建左表class还是右表book,所以可以先建右表book，查看之后再进行优化 ALTER TABLE book ADD index Y('card'); 此时可以明显看到book表得到优化type=ref,但是class表未得到改变，于是删除索引 ： DROP INDEX Y ON book; 现在加左表class: ALTER TABLE class ADD INDEX Y ('card'); 此时看到class表的type=index

http://blog.csdn.net/alongken2005/article/details/6394016 Analyze Table MySQL 的Optimizer（优化元件）在优化SQL语句时，首先需要收集一些相关信息，其中就包括表的cardinality（可以翻译为“散列程度”），它表示某个索引对应的列包含多少个不同的值——如果cardinality大大少于数据的实际散列程度，那么索引就基本失效了。 我们可以使用SHOW INDEX语句来查看索引的散列程度： SHOW INDEX FROM PLAYERS; TABLE KEY_NAME COLUMN_NAME CARDINALITY ------- -------- ----------- ----------- PLAYERS PRIMARY PLAYERNO 14 因为此时PLAYER表中不同的PLAYERNO数量远远多于14，索引基本失效。 下面我们通过Analyze Table语句来修复索引： ANALYZE TABLE PLAYERS; SHOW INDEX FROM PLAYERS; 结果是： TABLE KEY_NAME COLUMN_NAME CARDINALITY ------- -------- ----------- ----------- PLAYERS PRIMARY PLAYERNO

面对当今大数据存储，设想当mysql中一个表的总记录超过1000W，会出现性能的大幅度下降吗？ 答案是肯定的，一个表的总记录超过1000W，在操作系统层面检索也是效率非常低的 解决方案： 目前针对海量数据的优化有两种方法： 1、大表拆小表的方式（主要有分表和分区两者技术） （1）分表技术 垂直分割 优势：降低高并发情况下，对于表的锁定。 不足：对于单表来说，随着数据库的记录增多，读写压力将进一步增大。 水平分割 如果单表的IO压力大，可以考虑用水平分割，其原理就是通过hash算法，将一张表分为N多页，并通过一个新的表（总表），记录着每个页的的位置。假如一 个门户网站，它的数据库表已经达到了1000万条记录，那么此时如果通过select去查询，必定会效率低下（不做索引的前提下）。为了降低单表的读写 IO压力，通过水平分割，将这个表分成10个页，同时生成一个总表，记录各个页的信息，那么假如我查询一条id=100的记录，它不再需要全表扫描，而是 通过总表找到该记录在哪个对应的页上，然后再去相应的页做检索，这样就降低了IO压力。 水平分表技术就是将一个表拆成多个表，比较常见的方式就是将表中的记录按照某种HASH算法进行拆分，同时，这种分区方法也必须对前端的应用程序中的 SQL进行修改方能使用，而且对于一个SQL语句，可能会修改两个表，那么你必须要修改两个SQL语句来完成你这个逻辑的事务

个人简介 ​ Java后台开发方向。 非计算机专业硕士，专业涉及到一些开发。 实验室项目主要是Java Web系统，挖掘小亮点。 无实习经验。 闲话唠嗑 ​ 回顾这几个月，宛若梦一场。 一开始心态不好，看到要学习的东西一大堆，沉不下心来学习，看什么东西都是看着看着就很浮躁，开始疯狂抖腿，沉迷幻想，以为找工作只看少量面经重点即可。 实验室原因无法实习，四五月份春招的时候参加了阿里和网易的实习招聘提前感受面试，惨败。可以说是一塌糊涂。当头一棒，脑子清醒了，既然想要从事互联网行业，早学晚学还是要学，不如现在踏踏实实好好学，一生受用（室友的面试官对她说的原话，感觉很有道理）。开始分阶段制定学习计划，每碰到一个知识点就来牛客查相关面经问题，逐个攻破。 总共投了三十多家公司，大小公司都有，想给自己多几个机会，到提前批结束为止只有十家左右有回复。目前收到阿里盒马、腾讯在线教育、网易严选、头条抖音、华为Cloud BU这几个意向offer。 易紧张体质，一紧张就肠道蠕动汗如雨下，题目答得歪七歪八了，编程题也做不出来了，但面试面多一些紧张感就好一些，不考虑结果，只思考问题，就会好很多了。 能够拿到offer得益于牛客上大家的面经分享和在线编程练习，是时候回报牛客啦，当然是恭喜各位收到offer的小伙伴们，但是暂时没收到offer的小伙伴们也不用着急，沉下心来好好学习，offer总会有的。

以下的内容，简单的讲解了两种索引的区别，但是深层次的还需要自己再好好看看，才能深入理解，最重要的是理解，而不是死记硬背。 Hash 索引结构的特殊性，其 检索效率非常高，索引的检索可以一次定位，不像B-Tree 索引需要从根节点到枝节点，最后才能访问到页节点这样多次的IO访问，所以 Hash 索引的查询效率要远高于 B-Tree 索引 。 可能很多人又有疑问了，既然 Hash 索引的效率要比 B-Tree 高很多，为什么大家不都用 Hash 索引而还要使用 B-Tree 索引呢？任何事物都是有两面性的，Hash 索引也一样， 虽然 Hash 索引效率高，但是 Hash 索引本身由于其特殊性也带来了很多 限制和弊端 ，主要有以下这些。 （1）Hash 索引仅仅能满足"=","IN"和"<=>"查询，不能使用范围查询。 由于 Hash 索引比较的是进行 Hash 运算之后的 Hash 值 ，所以它只能用于 等值的过滤 ，不能用于基于范围的过滤，因为经过相应的 Hash 算法处理之后的 Hash 值的大小关系，并不能保证和Hash运算前完全一样。 （2） Hash 索引无法被用来避免数据的排序操作 。 由于 Hash 索引中存放的是经过 Hash 计算之后的 Hash 值，而且Hash值的大小关系并不一定和 Hash 运算前的键值完全一样， 所以数据库无法利用索引的数据来避免任何排序运算

【摘要】 这是从《MySQL性能调优与架构设计》第六章摘录的一些知识点。 【主题】 Hash索引 B-Tree索引 【内容】 1. Hash索引 Hash 索引结构的特殊性，其检索效率非常高，索引的检索可以一次定位，不像B-Tree 索引需要从根节点到枝节点，最后才能访问到页节点这样多次的IO访问，所以 Hash 索引的查询效率要远高于 B-Tree 索引。 可能很多人又有疑问了，既然 Hash 索引的效率要比 B-Tree 高很多，为什么大家不都用 Hash 索引而还要使用 B-Tree 索引呢？任何事物都是有两面性的，Hash 索引也一样，虽然 Hash 索引效率高，但是 Hash 索引本身由于其特殊性也带来了很多限制和弊端，主要有以下这些。 （1）Hash 索引仅仅能满足"=","IN"和"<=>"查询，不能使用范围查询。 由于 Hash 索引比较的是进行 Hash 运算之后的 Hash 值，所以它只能用于等值的过滤，不能用于基于范围的过滤，因为经过相应的 Hash 算法处理之后的 Hash 值的大小关系，并不能保证和Hash运算前完全一样。 （2）Hash 索引无法被用来避免数据的排序操作。 由于 Hash 索引中存放的是经过 Hash 计算之后的 Hash 值，而且Hash值的大小关系并不一定和 Hash 运算前的键值完全一样

limit 查询导出优化 耗时本质 mysql大数据量使用limit分页，随着页码的增大，查询效率越低下。 当一个表数据有几百万的数据的时候成了问题！ 如 select * from table limit 0,10 这个没有问题 当 limit 200000,10 的时候数据读取就很慢 原因本质： 1）limit语句的查询时间与起始记录（offset）的位置成正比 2）mysql的limit语句是很方便，但是对记录很多:百万，千万级别的表并不适合直接使用。 例如： limit10000,20的意思扫描满足条件的10020行，扔掉前面的10000行，返回最后的20行，问题就在这里。 ​ LIMIT 2000000, 30 扫描了200万+ 30行，怪不得慢的都堵死了，甚至会导致磁盘io 100%消耗。 ​ 但是: limit 30 这样的语句仅仅扫描30行。 优化手段 干掉或者利用 limit offset,size 中的offset 不是直接使用limit，而是首先获取到offset的id然后直接使用limit size来获取数据 对limit分页问题的性能优化方法 利用表的覆盖索引来加速分页查询 覆盖索引: 就是select 的数据列只用从索引中就能获得，不必读取数据行。mysql 可以利用索引返回select列表中的字段，而不必根据索引再次读取数据文件，换句话说：

自从两年前了解到的索引以来的，就一直想写一篇有关索引的文章。然而我是个拖延癌症患者，一拖就是两年，不愧是我。该篇文章算是自己的笔记，欢迎批评。 概述 索引是什么？很多书和文章都会使用图书的目录来类比。目录的目的就是用方便我们查找具体内容的位置，具体的章节的范围。与此类似，MySQL中索引的用途是帮助我们加速查询以及排序。 在InnoDB中的索引类型有哈希索引、B+树索引、全文索引。哈希索引在InnoDB中设计为自适应的，不展开讨论。在InnoDB1.12之后有了全文索引，也是应用倒排，还没踩过坑(据说不支持中文)，有时间可以研究一下。 本篇主要讨论B+树索引。 B+树 学习MySQL的索引，必须得先了解其原理，否则很多问题将一头雾水。下文将讲述索引数据结构的原理，而不涉及其复杂的具体实现。 在谈B+树之前，不妨先思考，为什么索引能加快查询？为什么要用B+树作为索引而不用B树？哈希索引查询复杂度为O(1)为什么又不用哈希索引？ BST和AVL 在了解B树和B+树之前，先了解一下二叉搜索树(BST)和平衡二叉树(AVL)。 在顺序存储结构中(如数组)，最快的情况是第一个就是目标值，最坏的情况是最后一个是目标值，假设有n个元素，用大O标记法平均的时间复杂度为O(n)。 使用二叉搜索树可以有效的优化搜索时间。利用二叉搜索树的特性左子节点比父节点小、右子节点比父节点大

目录 1、使用的表 2、explain 中的列 2.1 id列 1）简单子查询 2）from子句中的子查询 3）union查询 2.2 select_type列 2.3 table列 2.4 type列 2.5 possible_keys列 2.6 key列 2.7 key_len列 2.8 ref列 2.9 rows列 2.10 Extra列 3、索引优化实战 2.1 使用的表 2.2 索引优化原则 EXPLAIN命令（执行计划）是查看优化器如何决定执行查询的主要方法。使用EXPLAIN关键字可以模拟优化器执行SQL语句，从而知道MySQL是 如何处理你的SQL语句的，让我们知道 SQL 的执行计划 ，可以帮助我们深入了解MySQL的基于开销的优化器，还可以获得很多可能被优化器考虑到的访问策略的细节，以及当运行SQL语句时哪种策略预计会被优化器采用，进而分析你的查询语句或是结构的性能瓶颈。 下面是使用 explain 的例子： 在 select 语句之前增加 explain 关键字，MySQL 会在查询上设置一个标记，执行查询时，会返回执行计划的信息，而不是执行这条SQL（如果 from 中包含子查询，仍会执行该子查询，将结果放入临时表中） 1 、使用的表 DROP TABLE IF EXISTS `actor`; CREATE TABLE `actor` ( `id` int