mysql索引

上一篇文章一起学习Mysql索引二（索引的高性能策略）中我们提到了Mysql5.7版本的一个改进： "索引条件下推"（index condition pushdown）。 那么，今天就让我们来揭开它的神秘面纱。 从ICP（index condition pushdown）的字面意思来看，大家疑惑的点应该就是这个"pushdown"--下推了。 什么是下推，下推到哪里，有什么用？带着疑问，我们先从关闭和开启ICP对一些sql语句的影响，然后再进一步的解答提出的问题。 首先，我们可以通过如下语句开启或关闭Myslq的ICP特性： SET optimizer_switch = 'index_condition_pushdown=off'; //关闭 SET optimizer_switch = 'index_condition_pushdown=on'; //开启 Mysql 新版本默认开启该特性，然后我们准备一张表： CREATE TABLE demo ( id bigint(11) unsigned NOT NULL AUTO_INCREMENT, pid int(11) DEFAULT '0', nid int(5) DEFAULT NULL, country varchar(10) DEFAULT '', name varchar(10) DEFAULT '', status

CREATE TABLE t_mobilesms_11 ( id bigint(20) NOT NULL AUTO_INCREMENT, userId varchar(255) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL DEFAULT ‘’ COMMENT ‘用户id，创建任务时的userid’, mobile varchar(24) NOT NULL DEFAULT ‘’ COMMENT ‘手机号码’, billMonth varchar(32) DEFAULT NULL COMMENT ‘账单月’, time varchar(32) DEFAULT NULL COMMENT ‘收/发短信时间’, peerNumber varchar(64) NOT NULL COMMENT ‘对方号码’, location varchar(64) DEFAULT NULL COMMENT ‘通信地(自己的)’, sendType varchar(16) DEFAULT NULL COMMENT ‘SEND-发送; RECEIVE-收取’, msgType varchar(8) DEFAULT NULL COMMENT ‘SMS-短信; MSS-彩信’, serviceName varchar(256) DEFAULT NULL COMMENT

Sql如下: SELECT ( @id := @id + 1 ) AS id, t.* FROM sys_user t, ( SELECT @id := 0 ) AS id_temp 如果要分页,请把@id的初始值设置为动态传入即可 来源： 51CTO 作者： pannijingling 链接： https://blog.51cto.com/1197822/2478820

某厂面试归来，发现自己落伍了！>>> 索引是帮助MySQL高效获取数据的排好序的数据结构 一.存储引擎 这里只讨论 使用最多的两种引擎【MyISAM】和【InnoDB】 1. MyISAM 引擎（非聚集） 上图是是使用myisam引擎的文件，可以看出：MyISAM索引文件和数据是分离的（非聚集）。 当一个查询带有索引，得先通过MYI文件（B+TREE）读取到该条数据的磁盘文件指针，因此再在MYD文件中获取到该条数据。如果查询条件不是索引，则直接去MYD文件去找，做全表扫描，效率低下。 2. InnoDB引擎（聚集） 表数据文件本身就是按B+Tree组织的一个索引结构文件如上图 此为 聚集索引 -叶节点包含了完整的数据记录 1、为什么InnoDB表必须有主键，并且推荐使用整型的自增主键?（ 整型比字符串大小判断效率更高，自增会不容易造成B+Tree分裂 ） 2、为什么非主键索引结构叶子节点存储的是主键值? ( 一致性和节省存储空间 ) 简单总结一下这两个引擎： InnoDB ：支持事务处理，支持外键，支持崩溃修复能力和并发控制。如果需要频繁的更新、删除操作的数据库，也可以选择InnoDB，因为支持事务的提交（commit）和回滚（rollback）。 MyISAM ：插入数据快，空间和内存使用比较低。如果表主要是用于插入新记录和读出记录，那么选择MyISAM能实现处理高效率

1、MySQL 查询统计数据表行数三种方式：select count(*) 、select count(1) 、select count(具体字段)，三者查询效率是怎么样的呢？ 解答： 在MySQL InnoDB 存储引擎中，count(*) 和count(*) 都是对所有结果进行count。如果有where 子句，则是对所有筛选条件的数据行进行统计；如果没有where子句，则是对数据表的数据行数进行统计。 因此count(*) 和 count(1) 本质上并没有区别，执行的复杂度都是O(N)，也就是采用全表扫描，进行循环+计数的方式进行统计。 如果是MySQL MyISAM 存储引擎，统计数据表的行数只需要O(1)的复杂度，这是因为每张MyISAM的数据表都有一个meta信息存储了row_count值，而一致性则由表级锁来保证，因为InnoDB支持事务，采用行级锁和MVCC机制，所以无法像MyISAM一样，只维护一个row_count变量，因此采用扫描全表，进行循环+计数的方式来完成统计； 在执行过程中，count(*) 和 count(1)执行时间略有差别，不过效率可以基本看成是相等的。 一般情况，三者的执行效率count(1) = count(*) >count(字段)。我们尽量使用count(*),当然如果你知道你要统计的是某个字段的非空数据行数，则另当别论

索引的类型 索引是由存储引擎来实现的，而不是在服务层，所以不同的引擎的索引的工作方案可能会有不同，支持的索引种类也不尽相同等等。 B-Tree Indexes B-Tree索引中，所有的值都是按顺序来排列的，这让它 很适合查询一个范围里的数据 。 假设你有如下表： CREATE TABLE People ( last_name varchar(50) not null, first_name varchar(50) not null, dob date not null, gender enum('m', 'f')not null, key(last_name, first_name, dob) ); 以下查询会使用到B-Tree索引 全值匹配( Match the full value )：如查找一个出生于1960-01-01名叫Cuba Allen的人 左前缀匹配( Match a leftmost prefix )：如查找一个叫Allen的人，只对第一列有效 列前缀匹配( Match a column prefix ): 如查找所有姓以J开头的人，只对第一列有效 范围匹配( Match a range of values ): 如查找Allen到Barrymore之间的人，只对第一列有效 Match one part ane match a range of another

B+树索引是B+树在数据库中的一种实现，是最常见也是数据库中使用最为频繁的一种索引。B+树中的B代表平衡（balance），而不是二叉（binary），因为B+树是从最早的平衡二叉树演化而来的。在讲B+树之前必须先了解二叉查找树、平衡二叉树（AVLTree）和平衡多路查找树（B-Tree），B+树即由这些树逐步优化而来。 二叉查找树 二叉树具有以下性质：左子树的键值小于根的键值，右子树的键值大于根的键值。 如下图所示就是一棵二叉查找树， 对该二叉树的节点进行查找发现深度为1的节点的查找次数为1，深度为2的查找次数为2，深度为n的节点的查找次数为n，因此其平均查找次数为 (1+2+2+3+3+3) / 6 = 2.3次 二叉查找树可以任意地构造，同样是2,3,5,6,7,8这六个数字，也可以按照下图的方式来构造： 但是这棵二叉树的查询效率就低了。因此若想二叉树的查询效率尽可能高，需要这棵二叉树是平衡的，从而引出新的定义——平衡二叉树，或称AVL树。 平衡二叉树（AVL Tree） 平衡二叉树（AVL树）在符合二叉查找树的条件下，还满足任何节点的两个子树的高度最大差为1。下面的两张图片，左边是AVL树，它的任何节点的两个子树的高度差<=1；右边的不是AVL树，其根节点的左子树高度为3，而右子树高度为1； 如果在AVL树中进行插入或删除节点，可能导致AVL树失去平衡

kettle被很多中小企业使用，且常常结合ERP系统、内部系统，低成本打通内外部系统的业务。 kettle是一款开源工具，更多用于数据同步，支持SQL配置、请求转发、读写数据库的功能，也有很多拓展的内部函数使用。基于JAVA开发的工具，本身也支持java的一些属性，所以强依赖于JDK。 kettle是通过工作流的方式，定义业务需要实现的节点进行拆解和实现，学习成本低，易上手。 其实我第一个关心的是性能，其次才是实现，作为开源工具，功能实现基本符合业务，应该没有太大问题。对于大业务量抽数需要重点评估，以免做了无用功。所以这里重点描述一下如何做调优 Kettle 调优 1 、 调整 JVM 大小进行性能优化，修改 Kettle 定时任务中的 Kitchen 或 Pan或Spoon 脚本。 修改脚本代码片段 set OPT=-Xmx512m -cp %CLASSPATH% -Djava.library.path=libswt\win32\ -DKETTLE_HOME="%KETTLE_HOME%" -DKETTLE_REPOSITORY="%KETTLE_REPOSITORY%" -DKETTLE_USER="%KETTLE_USER%" -DKETTLE_PASSWORD="%KETTLE_PASSWORD%" -DKETTLE_PLUGIN_PACKAGES="%KETTLE

是什么 使用EXPLAIN关键字可以模拟优化器执行SQL语句，从而知道MySQL是如何处理你的SQL语句的。 用法：explain+sql语句 explain之id id是以数字形式呈现，表示查询中执行select子句或操作表的顺序。数字越大，优先级越高，优化器优先执行。 id相同，从上往下顺序执行 id不同，id值越大，优先级越高，越先执行。 explain之select_type select_type表示查询的类型，主要是用来区别普通查询、联合查询、子查询等复杂查询。主要有以下几种： SIMPLE：简单的select查询，查询中不包含子查询或者UNION PRIMARY：查询中若包含任何复杂的子部分，最外层查询则被标记为PRIMARY SUBQUERY：在select或WHERE列表中包含了子查询。 DERIVED：在FROM列表中包含的子查询被标记为DERIVED（衍生），MySQL会递归执行这些子查询，把结果放在临时表里。 UNION：若第二个SELECT出现在UNION之后则被标记为UNION；若UNION包含在FROM子句的子查询中，外层SELECT将被标记为：DERIVED。 UNION RESULT：从UNION表获取结果的SELECT。 explain之table 显示这一行的数据是关于哪张表的！ explain之type type显示查询使用了何种类型

在了解B+Tree之前，先简单介绍一下B Tree。 **B Tree：**数据库设计者，把数据存放到节点以树的形式存储，把节点的大小设置为一个页，那读取一个节点就需要一次I/O操作，如果一次检索需要访问四个节点，根节点常驻内存，那么完成这次检索，需要三次io。 那么数据越小，每页存放的数据就越多，树的高度就越小，io就少，检索就快。 索引就利用上面的性质，设计成B+tree。 **B+tree：**非叶子节点只存放key,叶子节点存放data,并且叶子节点存在指向相邻叶子节点的指针 这样一方面非叶子节点可以存放更多的记录，树更矮，io就少，另一方面，可以通过顺序指针提高区间查询的性能。 MySQL中普遍使用B+Tree做索引， 但在实现上又根据聚簇索引和非聚簇索引而不同。 聚簇索引(主键索引树) 所谓聚簇索引，就是指B+Tree的叶子节点上的data就是数据本身，key为主键，如果是一般索引的话，data便会指向对应的主索引。 非聚簇索（非主键索引树） 非聚簇索引就是指B+Tree的叶子节点上的data，并不是数据本身，而是数据存放的地址。 非聚簇索引比聚簇索引多了一次读取数据的IO操作，所以查找性能上会差。 因为主键索引树的叶子节点直接就是我们要查询的整行数据了。而非主键索引的叶子节点是主键的值，查到主键的值以后，还需要再通过主键的值再进行一次查询，这个过程叫 回表 。 来源：