公众号_IT老哥

公众号_IT老哥 查看完整档案

北京编辑  |  填写毕业院校大厂  |  高级java开发工程师 编辑 baidu.com 编辑
编辑

关注公众号:IT老哥
回复:面试题。获取2020年最新java面试题,涵盖java各个技术领域,非常全面,共80多个PDF文档
回复:Java实战项目视频教程:即可获取200G,27套实战项目视频教程
回复:Java 学习路线,即可获取2020年最新最全的一份学习路线图
回复:Java 电子书,即可领取 13 本顶级程序员必读书籍
回复:Java 全套教程,即可领取:Java 基础、Java web、JavaEE 全部的教程,包括 spring boot 等
回复:简历模板,即可获取 100 份精美简历

个人动态

公众号_IT老哥 发布了文章 · 今天 09:57

7种jvm垃圾回收器,这次全部搞懂

前言

之前我们讲解了jvm组成结构垃圾回收算法等知识点,今天我们来讲讲jvm最重要的堆内存是如何使用垃圾回收器进行垃圾回收,并且如何使用命令去配置使用这些垃圾回收器。

堆内存详解

image.png

上面这个图大家应该已经很明白了吧。大家就可以理解成一个房子被分成了几个房间,每个房间的作用不同而已,有的是婴儿住的,有的是父母住的,有的是爷爷奶奶住的

  • 堆内存被划分为两块,一块的年轻代,另一块是老年代
  • 年轻代又分为Edensurvivor。他俩空间大小比例默认为8:2,
  • 幸存区又分为s0s1。这两个空间大小是一模一样的,就是一对双胞胎,他俩是1:1的比例

堆内存垃圾回收过程

第一步

新生成的对象首先放到Eden区,当Eden区满了会触发Minor GC

第二步

第一步GC活下来的对象,会被移动到survivor区中的S0区,S0区满了之后会触发Minor GC,S0区存活下来的对象会被移动到S1区,S0区空闲。

S1满了之后在GC,存活下来的再次移动到S0区,S1区空闲,这样反反复复GC,每GC一次,对象的年龄就涨一岁,达到某个值后(15),就会进入老年代

第三步

在发生一次Minor GC后(前提条件),老年代可能会出现Major GC,这个视垃圾回收器而定。

Full GC触发条件

  • 手动调用System.gc,会不断的执行Full GC
  • 老年代空间不足/满了
  • 方法区空间不足/满了

注意

们需要记住一个单词:stop-the-world。它会在任何一种GC算法中发生。stop-the-world 意味着JVM因为需要执行GC而停止应用程序的执行。

当stop-the-world 发生时,除GC所需的线程外,所有的线程都进入等待状态,直到GC任务完成。GC优化很多时候就是减少stop-the-world 的发生。

回收哪些区域的对象

需要注意的是,JVM GC只回收堆内存方法区内的对象。而栈内存的数据,在超出作用域后会被JVM自动释放掉,所以其不在JVM GC的管理范围内。

堆内存常见参数配置

参数描述
-Xms堆内存初始大小,单位m、g
-Xmx堆内存最大允许大小,一般不要大于物理内存的80%
-XX:PermSize非堆内存初始大小,一般应用设置初始化200m,最大1024m就够了
-XX:MaxPermSize非堆内存最大允许大小
-XX:NewSize(-Xns)年轻代内存初始大小
-XX:MaxNewSize(-Xmn)年轻代内存最大允许大小
-XX:SurvivorRatio=8年轻代中Eden区与Survivor区的容量比例值,默认为8,即8:1
-Xss堆栈内存大小
-XX:NewRatio=老年代/新生代设置老年代和新生代的大小比例
-XX:+PrintGCjvm启动后,只要遇到GC就会打印日志
-XX:+PrintGCDetails查看GC详细信息,包括各个区的情况
-XX:MaxDirectMemorySize在NIO中可以直接访问直接内存,这个就是设置它的大小,不设置默认就是最大堆空间的值-Xmx
-XX:+DisableExplicitGC关闭System.gc()
-XX:MaxTenuringThreshold垃圾可以进入老年代的年龄
-Xnoclassgc禁用垃圾回收
-XX:TLABWasteTargetPercentTLAB占eden区的百分比,默认是1%
-XX:+CollectGen0FirstFullGC时是否先YGC,默认false

TLAB 内存

TLAB全称是Thread Local Allocation Buffer即线程本地分配缓存,从名字上看是一个线程专用的内存分配区域,是为了加速对象分配而生的。

每一个线程都会产生一个TLAB,该线程独享的工作区域,java虚拟机使用这种TLAB区来避免多线程冲突问题,提高了对象分配的效率。

TLAB空间一般不会太大,当大对象无法在TLAB分配时,则会直接分配到堆上。

参数描述
-Xx:+UseTLAB使用TLAB
-XX:+TLABSize设置TLAB大小
-XX:TLABRefillWasteFraction设置维护进入TLAB空间的单个对象大小,他是一个比例值,默认为64,即如果对象大于整个空间的1/64,则在堆创建
-XX:+PrintTLAB查看TLAB信息
-Xx:ResizeTLAB自调整TLABRefillWasteFraction阀值。

image.png

垃圾回收器总览

image.png

新生代可配置的回收器:Serial、ParNew、Parallel Scavenge

老年代配置的回收器:CMS、Serial Old、Parallel Old

新生代和老年代区域的回收器之间进行连线,说明他们之间可以搭配使用。

新生代垃圾回收器

Serial 垃圾回收器

Serial收集器是最基本的、发展历史最悠久的收集器。俗称为:串行回收器,采用复制算法进行垃圾回收

特点

串行回收器是指使用单线程进行垃圾回收的回收器。每次回收时,串行回收器只有一个工作线程。

对于并行能力较弱的单CPU计算机来说,串行回收器的专注性和独占性往往有更好的性能表现。

它存在Stop The World问题,及垃圾回收时,要停止程序的运行。

使用-XX:+UseSerialGC参数可以设置新生代使用这个串行回收器

ParNew 垃圾回收器

ParNew其实就是Serial的多线程版本,除了使用多线程之外,其余参数和Serial一模一样。俗称:并行垃圾回收器,采用复制算法进行垃圾回收

特点

ParNew默认开启的线程数与CPU数量相同,在CPU核数很多的机器上,可以通过参数-XX:ParallelGCThreads来设置线程数。

它是目前新生代首选的垃圾回收器,因为除了ParNew之外,它是唯一一个能与老年代CMS配合工作的。

它同样存在Stop The World问题

使用-XX:+UseParNewGC参数可以设置新生代使用这个并行回收器

ParallelGC 回收器

ParallelGC使用复制算法回收垃圾,也是多线程的。

特点

就是非常关注系统的吞吐量,吞吐量=代码运行时间/(代码运行时间+垃圾收集时间)

-XX:MaxGCPauseMillis:设置最大垃圾收集停顿时间,可用把虚拟机在GC停顿的时间控制在MaxGCPauseMillis范围内,如果希望减少GC停顿时间可以将MaxGCPauseMillis设置的很小,但是会导致GC频繁,从而增加了GC的总时间降低吞吐量。所以需要根据实际情况设置该值。

-Xx:GCTimeRatio:设置吞吐量大小,它是一个0到100之间的整数,默认情况下他的取值是99,那么系统将花费不超过1/(1+n)的时间用于垃圾回收,也就是1/(1+99)=1%的时间。

另外还可以指定-XX:+UseAdaptiveSizePolicy打开自适应模式,在这种模式下,新生代的大小、eden、from/to的比例,以及晋升老年代的对象年龄参数会被自动调整,以达到在堆大小、吞吐量和停顿时间之间的平衡点。

使用-XX:+UseParallelGC参数可以设置新生代使用这个并行回收器

老年代垃圾回收器

SerialOld 垃圾回收器

SerialOld是Serial回收器的老年代回收器版本,它同样是一个单线程回收器。

用途

  • 一个是在JDK1.5及之前的版本中与Parallel Scavenge收集器搭配使用,
  • 另一个就是作为CMS收集器的后备预案,如果CMS出现Concurrent Mode Failure,则SerialOld将作为后备收集器。

使用算法:标记 - 整理算法

ParallelOldGC 回收器

老年代ParallelOldGC回收器也是一种多线程的回收器,和新生代的ParallelGC回收器一样,也是一种关注吞吐量的回收器,他使用了标记压缩算法进行实现。

-XX:+UseParallelOldGc进行设置老年代使用该回收器

-XX:+ParallelGCThreads也可以设置垃圾收集时的线程数量。

CMS 回收器

CMS全称为:Concurrent Mark Sweep意为并发标记清除,他使用的是标记清除法。主要关注系统停顿时间。

使用-XX:+UseConcMarkSweepGC进行设置老年代使用该回收器。

使用-XX:ConcGCThreads设置并发线程数量。

特点

CMS并不是独占的回收器,也就说CMS回收的过程中,应用程序仍然在不停的工作,又会有新的垃圾不断的产生,所以在使用CMS的过程中应该确保应用程序的内存足够可用。

CMS不会等到应用程序饱和的时候才去回收垃圾,而是在某一阀值的时候开始回收,回收阀值可用指定的参数进行配置:-XX:CMSInitiatingoccupancyFraction来指定,默认为68,也就是说当老年代的空间使用率达到68%的时候,会执行CMS回收。

如果内存使用率增长的很快,在CMS执行的过程中,已经出现了内存不足的情况,此时CMS回收就会失败,虚拟机将启动老年代串行回收器;SerialOldGC进行垃圾回收,这会导致应用程序中断,直到垃圾回收完成后才会正常工作。

这个过程GC的停顿时间可能较长,所以-XX:CMSInitiatingoccupancyFraction的设置要根据实际的情况。

之前我们在学习算法的时候说过,标记清除法有个缺点就是存在内存碎片的问题,那么CMS有个参数设置-XX:+UseCMSCompactAtFullCollecion可以使CMS回收完成之后进行一次碎片整理

-XX:CMSFullGCsBeforeCompaction参数可以设置进行多少次CMS回收之后,对内存进行一次压缩

G1 回收器

篇幅太长,我们下篇文章讲解!!!

image.png

IT 老哥

一个在大厂做高级Java开发的程序猿,一路自学走到今天,关注 老哥,我们一起来自学技术

查看原文

赞 0 收藏 0 评论 0

公众号_IT老哥 关注了用户 · 10月20日

宗恩 @yzn

关注新科技

联系邮箱 yzn@sifou.com

交流微信:yyuuuuusjjjd

关注 30

公众号_IT老哥 发布了文章 · 10月20日

一文搞懂MySQL行锁、表锁、间隙锁详解

image

前言

我们前几篇讲了索引是什么,如何使用explain分析索引使用情况,如何去优化索引,以及show profiles分析SQL语句执行资源消耗的学习。今天我们来讲讲MySQL的各种锁,这里存储引擎我们使用InnoDB

准备工作

创建表 tb_innodb_lock

drop table if exists test_innodb_lock;
CREATE TABLE test_innodb_lock (
    a INT (11),
    b VARCHAR (20)
) ENGINE INNODB DEFAULT charset = utf8;
insert into test_innodb_lock values (1,'a');
insert into test_innodb_lock values (2,'b');
insert into test_innodb_lock values (3,'c');
insert into test_innodb_lock values (4,'d');
insert into test_innodb_lock values (5,'e');

创建索引

create index idx_lock_a on test_innodb_lock(a);
create index idx_lock_b on test_innodb_lock(b);

MySQL 各种锁演示

  • 先将自动提交事务改成手动提交:set autocommit=0;
  • 我们启动两个会话窗口 A 和 B,模拟一个抢到锁,一个没抢到被阻塞住了。

行锁(写&读)

  • A 窗口执行
update test_innodb_lock set b='a1' where a=1;
SELECT * from test_innodb_lock;

image.png

我们可以看到 A 窗口可以看到更新后的结果

  • B 窗口执行
SELECT * from test_innodb_lock;

image.png

我们可以看到 B 窗口不能看到更新后的结果,看到的还是老数据,这是因为 a = 1 的这行记录被 A 窗口执行的 SQL 语句抢到了锁,并且没有执行 commit 提交操作。所以窗口 B 看到的还是老数据。这就是 MySQL 隔离级别中的"读已提交"。

  • 窗口 A 执行 commit 操作
COMMIT;
  • 窗口 B 查询
SELECT * from test_innodb_lock;

image.png

这个时候我们发现窗口 B 已经读取到最新数据了

行锁(写&写)

  • 窗口 A 执行更新 a = 1 的记录
update test_innodb_lock set b='a2' where a=1;

这时候并没有 commit 提交,锁是窗口 A 持有。

  • 窗口 B 也执行更新 a = 1 的记录
update test_innodb_lock set b='a3' where a=1;

image.png

可以看到,窗口 B 一直处于阻塞状态,因为窗口 A 还没有执行 commit,还持有锁。窗口 B 抢不到 a = 1 这行记录的锁,所以一直阻塞等待。

  • 窗口 A 执行 commit 操作
COMMIT;
  • 窗口 B 的变化

image.png

可以看到这个时候窗口 B 已经执行成功了

表锁

当索引失效的时候,行锁会升级成表锁,索引失效的其中一个方法是对索引自动 or 手动的换型。a 字段本身是 integer,我们加上引号,就变成了 String,这个时候索引就会失效了。

  • 窗口 A 更新 a = 1 的记录
update test_innodb_lock set b='a4' where a=1 or a=2;
  • 窗口 B 更新 a = 2 的记录
update test_innodb_lock set b='b1' where a=3;

image.png

这个时候发现,虽然窗口 A 和 B 更新的行不一样,但是窗口 B 还是被阻塞住了,就是因为窗口 A 的索引失效,导致行锁升级成了表锁,把整个表锁住了,索引窗口 B 被阻塞了。

  • 窗口 A 执行 commit 操作
COMMIT;
  • 窗口 B 的变化

image.png

可以看到这个时候窗口 B 已经执行成功了

间隙锁

  • 什么是间隙锁

当我们采用范围条件查询数据时,InnoDB 会对这个范围内的数据进行加锁。比如有 id 为:1、3、5、7 的 4 条数据,我们查找 1-7 范围的数据。那么 1-7 都会被加上锁。2、4、6 也在 1-7 的范围中,但是不存在这些数据记录,这些 2、4、6 就被称为间隙。

  • 间隙锁的危害

范围查找时,会把整个范围的数据全部锁定住,即便这个范围内不存在的一些数据,也会被无辜的锁定住,比如我要在 1、3、5、7 中插入 2,这个时候 1-7 都被锁定住了,根本无法插入 2。在某些场景下会对性能产生很大的影响

  • 间隙锁演示

我们先把字段 a 的值修改成 1、3、5、7、9

  • 窗口 A 更新 a = 1~7 范围的数据
update test_innodb_lock set b='b5' where a>1 and a<7;
  • 窗口 B 在 a = 2 的位置插入数据
insert into test_innodb_lock values(2, "b6");

image.png

这个时候发现窗口 B 更新 a = 2 的操作一直在等待,因为 1~7 范围的数据被间隙锁,锁住了。只有等窗口 A 执行 commit,窗口 B 的 a = 2 才能更新成功

行锁分析

  • 执行 SQL 分析命令
show status like 'innodb_row_lock%';

image.png

  • Variable_name 说明

    • Innodb_row_lock_current_waits:当前正在等待锁定的数量。
    • Innodb_row_lock_time:从系统启动到现在锁定的时长。
    • Innodb_row_lock_time_avg:每次等待锁所花平均时间。
    • Innodb_row_lock_time_max:从系统启动到现在锁等待最长的一次所花的时间。
    • Innodb_row_lock_waits:系统启动后到现在总共等待锁的次数。

结语

大家可以根据 Variable_name 这几个参数考虑是否要进行优化,如果锁定时间,锁定次数过大,那就该考虑优化了。优化手段可以参考之前索引优化的文章。

IT 老哥

一个通过自学,在大厂做高级Java开发的程序员,关注我,每天分享技术干货

查看原文

赞 10 收藏 8 评论 0

公众号_IT老哥 发布了文章 · 10月19日

MySQL性能优化,MySQL索引优化,order by优化,explain优化

前言

今天我们来讲讲如何优化MySQL的性能,主要从索引方面优化。下期文章讲讲MySQL慢查询日志,我们是依据慢查询日志来判断哪条SQL语句有问题,然后在进行优化,敬请期待MySQL慢查询日志篇

建表

// 建表
CREATE TABLE IF NOT EXISTS staffs(
    id INT PRIMARY KEY AUTO_INCREMENT,
    name VARCHAR(24) NOT NULL DEFAULT "" COMMENT'姓名',
    age INT NOT NULL DEFAULT 0 COMMENT'年龄',
    pos VARCHAR(20) NOT NULL DEFAULT "" COMMENT'职位',
    add_time TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT'入职事件'
) CHARSET utf8 COMMENT'员工记录表';
// 插入数据
INSERT INTO `test`.`staffs` (`name`, `age`, `pos`, `add_time`) VALUES ('z3', 22, 'manager', now());
INSERT INTO `test`.`staffs` (`name`, `age`, `pos`, `add_time`) VALUES ('July', 23, 'dev', now());
INSERT INTO `test`.`staffs` (`name`, `age`, `pos`, `add_time`) VALUES ('2000', 23, 'dev', now());
// 建立复合索引(即一个索引包含多个字段)
ALTER TABLE staffs ADD INDEX idx_staffs_nameAgePos(name, age, pos);

优化一:全部用到索引

介绍

建立的复合索引包含了几个字段,查询的时候最好能全部用到,而且严格按照索引顺序,这样查询效率是最高的。(最理想情况,具体情况具体分析)

SQL 案例

优化二:最左前缀法则

介绍

如果建立的是复合索引,索引的顺序要按照建立时的顺序,即从左到右,如:a->b->c(和 B+树的数据结构有关)

无效索引举例

  • a->c:a 有效,c 无效
  • b->c:b、c 都无效
  • c:c 无效

SQL 案例

优化三:不要对索引做以下处理

以下用法会导致索引失效

  • 计算,如:+、-、*、/、!=、<>、is null、is not null、or
  • 函数,如:sum()、round()等等
  • 手动/自动类型转换,如:id = "1",本来是数字,给写成字符串了

SQL 案例

优化四:索引不要放在范围查询右边

举例

比如复合索引:a->b->c,当 where a="" and b>10 and 3="",这时候只能用到 a 和 b,c 用不到索引,因为在范围之后索引都失效(和 B+树结构有关)

SQL 案例

优化五:减少 select * 的使用

使用覆盖索引

即:select 查询字段和 where 中使用的索引字段一致。

SQL 案例

优化六:like 模糊搜索

失效情况

  • like "%张三%"
  • like "%张三"

解决方案

  • 使用复合索引,即 like 字段是 select 的查询字段,如:select name from table where name like "%张三%"
  • 使用 like "张三%"

SQL 案例

优化七:order by 优化

当查询语句中使用 order by 进行排序时,如果没有使用索引进行排序,会出现 filesort 文件内排序,这种情况在数据量大或者并发高的时候,会有性能问题,需要优化。

filesort 出现的情况举例

  • order by 字段不是索引字段
  • order by 字段是索引字段,但是 select 中没有使用覆盖索引,如:select * from staffs order by age asc;
  • order by 中同时存在 ASC 升序排序和 DESC 降序排序,如:select a, b from staffs order by a desc, b asc;
  • order by 多个字段排序时,不是按照索引顺序进行 order by,即不是按照最左前缀法则,如:select a, b from staffs order by b asc, a asc;

索引层面解决方法

  • 使用主键索引排序
  • 按照最左前缀法则,并且使用覆盖索引排序,多个字段排序时,保持排序方向一致
  • 在 SQL 语句中强制指定使用某索引,force index(索引名字)
  • 不在数据库中排序,在代码层面排序

order by 排序算法

  • 双路排序

    Mysql4.1 之前是使用双路排序,字面的意思就是两次扫描磁盘,最终得到数据,读取行指针和 ORDER BY 列,对他们进行排序,然后扫描已经排好序的列表,按照列表中的值重新从列表中读取对数据输出。也就是从磁盘读取排序字段,在 buffer 进行排序,再从磁盘读取其他字段。

文件的磁盘 IO 非常耗时的,所以在 Mysql4.1 之后,出现了第二种算法,就是单路排序。

  • 单路排序

    从磁盘读取查询需要的所有列,按照 orderby 列在 buffer 对它们进行排序,然后扫描排序后的列表进行输出, 它的效率更快一些,避免了第二次读取数据,并且把随机 IO 变成顺序 IO,但是它会使用更多的空间, 因为它把每一行都保存在内存中了。

当我们无可避免要使用排序时,索引层面没法在优化的时候又该怎么办呢?尽可能让 MySQL 选择使用第二种单路算法来进行排序。这样可以减少大量的随机 IO 操作,很大幅度地提高排序工作的效率。下面看看单路排序优化需要注意的点

单路排序优化点

  • 增大 max_length_for_sort_data

    在 MySQL 中,决定使用"双路排序"算法还是"单路排序"算法是通过参数 max_length_for_ sort_data 来决定的。当所有返回字段的最大长度小于这个参数值时,MySQL 就会选择"单路排序"算法,反之,则选择"多路排序"算法。所以,如果有充足的内存让 MySQL 存放须要返回的非排序字段,就可以加大这个参数的值来让 MySQL 选择使用"单路排序"算法。
  • 去掉不必要的返回字段,避免select *

    当内存不是很充裕时,不能简单地通过强行加大上面的参数来强迫 MySQL 去使用"单路排序"算法,否则可能会造成 MySQL 不得不将数据分成很多段,然后进行排序,这样可能会得不偿失。此时就须要去掉不必要的返回字段,让返回结果长度适应 max_length_for_sort_data 参数的限制。
  • 增大 sort_buffer_size 参数设置

    这个值如果过小的话,再加上你一次返回的条数过多,那么很可能就会分很多次进行排序,然后最后将每次的排序结果再串联起来,这样就会更慢,增大 sort_buffer_size 并不是为了让 MySQL 选择"单路排序"算法,而是为了让 MySQL 尽量减少在排序过程中对须要排序的数据进行分段,因为分段会造成 MySQL 不得不使用临时表来进行交换排序。

但是sort_buffer_size 不是越大越好:

  • Sort_Buffer_Size 是一个 connection 级参数,在每个 connection 第一次需要使用这个 buffer 的时候,一次性分配设置的内存。
  • Sort_Buffer_Size 并不是越大越好,由于是 connection 级的参数,过大的设置和高并发可能会耗尽系统内存资源。
  • 据说 Sort_Buffer_Size 超过 2M 的时候,就会使用 mmap() 而不是 malloc() 来进行内存分配,导致效率降低。

优化八:group by

其原理也是先排序后分组,其优化方式可参考order by。where高于having,能写在where限定的条件就不要去having限定了。

IT 老哥

一个通过自学,进入大厂做高级Java开发的程序猿,希望能通过我的分享,让你学到知识

查看原文

赞 14 收藏 11 评论 2

公众号_IT老哥 发布了文章 · 10月16日

索引失效底层原理分析,这么多年终于有人讲清楚了

前言

吊打面试官又来啦,今天我们讲讲MySQL索引为什么会失效,很多文章和培训机构的教程,都只会告诉你,在什么情况下索引会失效。

比如:没遵循最佳左前缀法则、范围查询的右边会失效、like查询用不到索引等等

但是没有一个人告诉你,索引失效的原理是什么,老哥今天就告诉大家,让你们知其然,还要知其所以然

image.png

单值索引B+树图

单值索引在B+树的结构里,一个节点只存一个键值对

image.png

联合索引

开局一张图,由数据库的a字段和b字段组成一个联合索引
image.png

从本质上来说,联合索引也是一个B+树,和单值索引不同的是,联合索引的键值对不是1,而是大于1个。

a, b 排序分析

a顺序:1,1,2,2,3,3

b顺序:1,2,1,4,1,2

大家可以发现a字段是有序排列,b字段是无序排列(因为B+树只能选一个字段来构建有序的树)

一不小心又会发现,在a相等的情况下,b字段是有序的。

大家想想平时编程中我们要对两个字段排序,是不是先按照第一个字段排序,如果第一个字段出现相等的情况,就用第二个字段排序。这个排序方式同样被用到了B+树里。

分析最佳左前缀原理

先举一个遵循最佳左前缀法则的例子

select * from testTable where a=1 and b=2

分析如下:

首先a字段在B+树上是有序的,所以我们可以通过二分查找法来定位到a=1的位置。

其次在a确定的情况下,b是相对有序的,因为有序,所以同样可以通过二分查找法找到b=2的位置。

再来看看不遵循最佳左前缀的例子

select * from testTable where b=2

分析如下:

我们来回想一下b有顺序的前提:在a确定的情况下。

现在你的a都飞了,那b肯定是不能确定顺序的,在一个无序的B+树上是无法用二分查找来定位到b字段的。

所以这个时候,是用不上索引的。大家懂了吗?
image.png

范围查询右边失效原理

举例

select * from testTable where a>1 and b=2

分析如下:

首先a字段在B+树上是有序的,所以可以用二分查找法定位到1,然后将所有大于1的数据取出来,a可以用到索引。

b有序的前提是a是确定的值,那么现在a的值是取大于1的,可能有10个大于1的a,也可能有一百个a。

大于1的a那部分的B+树里,b字段是无序的(开局一张图),所以b不能在无序的B+树里用二分查找来查询,b用不到索引。

like索引失效原理

where name like "a%"

where name like "%a%"

where name like "%a"

我们先来了解一下%的用途

  • %放在右边,代表查询以"a"开头的数据,如:abc
  • 两个%%,代表查询数据中包含"a"的数据,如:cab、cba、abc
  • %放在左边,代表查询以"a"为结尾的数据,如cba

为什么%放在右边有时候能用到索引

  • %放右边叫做:前缀
  • %%叫做:中缀
  • %放在左边叫做:后缀

没错,这里依然是最佳左前缀法则这个概念

image.png

大家可以看到,上面的B+树是由字符串组成的。

字符串的排序方式:先按照第一个字母排序,如果第一个字母相同,就按照第二个字母排序。。。以此类推

开始分析

一、%号放右边(前缀)

由于B+树的索引顺序,是按照首字母的大小进行排序,前缀匹配又是匹配首字母。所以可以在B+树上进行有序的查找,查找首字母符合要求的数据。所以有些时候可以用到索引。

二、%号放左边

是匹配字符串尾部的数据,我们上面说了排序规则,尾部的字母是没有顺序的,所以不能按照索引顺序查询,就用不到索引。

三、两个%%号

这个是查询任意位置的字母满足条件即可,只有首字母是进行索引排序的,其他位置的字母都是相对无序的,所以查找任意位置的字母是用不上索引的。

总结

这里把一些经典的索引失效案例给大家分析了,希望能引发大家的思考,能够通过这些案例,明白其他情况索引失效的原理。

之后我们在讲讲,如何通过索引查询到数据整个流程,InnoDBMyISAM两个引擎底层索引的实现区别。

授人以鱼不如授人以渔,这一瞬间,老哥感觉自己特别的shuai

image.png

关注我,一个自学进入大厂的高级Java开发工程师

查看原文

赞 24 收藏 18 评论 6

公众号_IT老哥 关注了专栏 · 10月14日

SegmentFault 行业快讯

第一时间为开发者提供行业相关的实时热点资讯

关注 24944

公众号_IT老哥 赞了文章 · 10月14日

思否独立开发者丨@功夫熊猫:按照自己的想法来做是一件多么激动又幸福的事情

思否独立开发者

独立项目名称:名校讲座

思否社区ID:@功夫熊猫


13年大学毕业后@功夫熊猫就来到了北京,在7k7k小游戏做手机小游戏。和很多「网瘾少年」不同,工作了一段时间后他发现自己是真的不喜欢游戏,正巧有个大学同学怂恿他一起创业,于是他毅然决然的离开了毕业后的第一家公司,成为了一个创业者。

那时国内很少有人意识到VR的前景,但@功夫熊猫在体验过Oculus Rift的VR设备后被深深吸引,决定自己的第一次创业要进入到VR行业中,之后他们陆陆续续的做了一些VR项目。虽然项目看起来非常酷炫,但却出现了无法落地的困境,也因此得不到投资人的青睐。有幸和鸟巢合作的VR视频直播也没有取得预期的效果,在不得已的情况下,15年2月份@功夫熊猫和同学离开了创业团队,创业也就告一段落。

这段创业经历结束后,@功夫熊猫觉得自己还是适合从事技术性工作,当时移动端开发非常火热,自学了一段时间后他顺利进入好未来公司成为了一名Android开发者。目前他跳槽到了一家视频公司担任高级开发工程师。

在平常工作与产品沟通过程中,他发现自己想法很多,但是很难将这些想法付诸实践,总是要听产品的,这些被压抑的想法渐渐在他的心中形成了一个独立开发者的梦想,每次想到可以自己独立开发一个项目,按照自己的想法来做是一件多么激动又幸福的事情。最终他成为了一名兼职独立开发者。

独立开发者项目:名校讲座

立项时间:腾讯发布小程序时
项目背景:发现北京各个大学有很多质量高的线下讲座,平常通过一些公众号或者学校官方网站获取讲座信息,但是这种方式太过原始,讲座没有分类,没有提醒,查找起来也很费劲,当时恰好腾讯发布了小程序,经过调研发现,正好符合我的需求,我要做一个小程序,来汇总所有讲座信息,我也可以在小程序上开发更多功能,来解决一些痛点。
面向群体:关于目标用户,刚开始的设想是刚毕业一两年同时对继续学习感兴趣的职场人士,不过后来发现学生群里才是主要的目标用户

名校讲座

1、如何做的第一版产品?

由于这个产品只有自己一个人制作,所以不管是后台、前端都需要自己搞定,自己之前也倒腾过个人网站,大学时自学过php,于是网站后台就选取了php开发。而对于小程序是一个新鲜事物,自己也是边写代码,边摸索。当时在规划项目的时候,其实规划了很多功能,但是为了让第一版尽快上线,舍弃了很多。后来发现这个模式是对的,毕竟小步快跑才能及时调整方向。

2、独立开发过程中遇到过哪些困难?最难搞定的是什么?

独立开发中首先是要舍弃自己的业余时间,第一版上线之前,基本上每个周末都是从早忙到晚,有时候一天都忘记吃饭。后来第一版上线后才发现,原来最难的不是技术开发,而是推广。甚至去各个大学发传单,不过收效甚微。还有一个问题是这个项目其实偏重资讯,所以每天都要有大量的时间去编辑整理信息,虽然自己也有一些爬虫,但是爬回来的信息还是需要花时间去整理发布,这个也是目前最难搞定的,耗费时间太长,很难做到规模化。

3、项目目前取得了哪些成就?项目为你带来了什么?

目前项目还处于不温不火的阶段,小程序的累计用户在6000左右。做这个项目的过程中,得到了很多朋友的鼓励,也正是这种鼓励让我坚持做下去,这个项目可能不会赚钱,但是我相信我做的东西是有价值的,我就想看待自己的孩子一样,看着他一天天成长。

4、你的商业模式是什么?是如何增长的?

目前的还没有探索到比较好的商业模式,只是在详情页底部很不起眼的位置加了一个广告位。主要的推广途径还是通过微信群进行传播,也通过建立公众号来增加与用户的粘性。

5、近阶段项目有哪些更新,未来会做什么变动

最近上线了提醒功能,通过微信提醒的方式,让用户不错过讲座信息,同时在优化爬虫方案,让收集信息简单一些。未来想通过社区的力量来继续推动这件事情继续下去,一个人的力量还是过于单薄。

个人相关问题

1、推荐你最喜欢的一款产品 / 游戏 / App?并说明原因

最喜欢的一款软件是Typora,是一款MarkDown编辑软件,喜欢它的简单,让你在写技术文档的生活可以很专注于内容本身,而且它可以实时预览,不像一般的MarkDown软件是左右分栏,这一点也是我喜欢它的主要原因。

2、分享一下你的技术栈和你日常的工作流?

我平常主要的开发工作是Android开发,工作中会涉及一些视频编解码相关的工作。会一些php用来搭建网站,最近在学习SpringBoot。

image

3、对独立开发者或编程初学者有什么建议?

独立开发者听起来是一个光鲜靓丽的名字,其实背后(尤其是业余时间独立开发者)隐藏着巨大的努力与个人生活的牺牲,也许大部分独立开发者都没有或者只有很少的收入,但是还是希望大家可以坚持下去,你平常的工作可能是为了混一口饭吃,但是自己的独立项目却不是,它是自己用心创作的一件艺术品,每个独立开发者都是一个“艺术家”。

4、生活中有什么爱好?有什么个人的特别的工作习惯么?

平常生活中最喜欢跑步,一个人在跑步过程中可以忘掉一切,感受与自然融为一体的感觉。基本上每个周末如果没有特殊的原因,我都会跑个五公里,跑完后能感受到浑身的细胞都被唤醒。对于工作习惯,有一件事情可能说出来大家不信,我经常在梦里解决一些疑难bug,哈哈,可能是入睡前还一直在思考的缘故。

5、对国内技术社区的看法

个人觉得思否比较注重用户体验。近两年逛技术论坛社区的时间少了一些,一方面可能是一般的技术社区对于技术的深度挖掘的不够,另一方面自己也开始喜欢比较成体系的去研究一些知识,所以看书会多一些。


开发者寄语

如果大家对我和我的产品感兴趣,可以给我发邮件一起探讨独立开发者或者产品技术方面的问题

gaotengxuelang@gmail.com


独立开发者支持计划-1.png

该内容栏目为「SFIDSP - 思否独立开发者支持计划」。为助力独立开发者营造更好的行业环境, SegmentFault 思否社区作为服务于开发者的技术社区,正式推出「思否独立开发者支持计划」,我们希望借助社区的资源为独立开发者提供相应的个人品牌、独立项目的曝光推介。

有意向的独立开发者或者独立项目负责人,可通过邮箱提供相应的信息(个人简介、独立项目简介、联系方式等),以便提升交流的效率。

联系邮箱:pr@segmentfault.com

image

查看原文

赞 5 收藏 0 评论 0

公众号_IT老哥 发布了文章 · 10月14日

MySQL索引优化,explain用法详细讲解

前言:这篇文章主要讲 explain 如何使用,还有 explain 各种参数概念,之后会讲优化

一、Explain 用法


模拟Mysql优化器是如何执行SQL查询语句的,从而知道Mysql是如何处理你的SQL语句的。分析你的查询语句或是表结构的性能瓶颈。

语法:Explain + SQL 语句;

如:Explain select * from user; 会生成如下 SQL 分析结果,下面详细对每个字段进行详解

二、id


是一组数字,代表多个表之间的查询顺序,或者包含子句查询语句中的顺序,id 总共分为三种情况,依次详解

  • id 相同,执行顺序由上至下
  • id 不同,如果是子查询,id 号会递增,id 值越大优先级越高,越先被执行
  • id 相同和不同的情况同时存在

三、select_type


select_type 包含以下几种值

  • simple
  • primary
  • subquery
  • derived
  • union
  • union result

simple

简单的 select 查询,查询中不包含子查询或者 union 查询

primary

如果 SQL 语句中包含任何子查询,那么子查询的最外层会被标记为 primary

subquery

在 select 或者 where 里包含了子查询,那么子查询就会被标记为 subQquery,同三.二同时出现

derived

在 from 中包含的子查询,会被标记为衍生查询,会把查询结果放到一个临时表中

union / union result

如果有两个 select 查询语句,他们之间用 union 连起来查询,那么第二个 select 会被标记为 union,union 的结果被标记为 union result。它的 id 是为 null 的

四、table


表示这一行的数据是哪张表的数据

五、type


type 是代表 MySQL 使用了哪种索引类型,不同的索引类型的查询效率也是不一样的,type 大致有以下种类

  • system
  • const
  • eq_ref
  • ref
  • range
  • index
  • all

system

表中只有一行记录,system 是 const 的特例,几乎不会出现这种情况,可以忽略不计

const

将主键索引或者唯一索引放到 where 条件中查询,MySQL 可以将查询条件转变成一个常量,只匹配一行数据,索引一次就找到数据了

eq_ref

在多表查询中,如 T1 和 T2,T1 中的一行记录,在 T2 中也只能找到唯一的一行,说白了就是 T1 和 T2 关联查询的条件都是主键索引或者唯一索引,这样才能保证 T1 每一行记录只对应 T2 的一行记录

举个不太恰当的例子,EXPLAIN SELECT * from t1 , t2 where t1.id = t2.id

ref

不是主键索引,也不是唯一索引,就是普通的索引,可能会返回多个符合条件的行。

range

体现在对某个索引进行区间范围检索,一般出现在 where 条件中的 between、and、<、>、in 等范围查找中。

index

将所有的索引树都遍历一遍,查找到符合条件的行。索引文件比数据文件还是要小很多,所以比不用索引全表扫描还是要快很多。

all

没用到索引,单纯的将表数据全部都遍历一遍,查找到符合条件的数据

六、possible_keys


此次查询中涉及字段上若存在索引,则会被列出来,表示可能会用到的索引,但并不是实际上一定会用到的索引

七、key


此次查询中实际上用到的索引

八、key_len


表示索引中使用的字节数,通过该属性可以知道在查询中使用的索引长度,注意:这个长度是最大可能长度,并非实际使用长度,在不损失精确性的情况下,长度越短查询效率越高

九、ref


显示关联的字段。如果使用常数等值查询,则显示 const,如果是连接查询,则会显示关联的字段。

  • tb_emp 表为非唯一性索引扫描,实际使用的索引列为 idx_name,由于 tb_emp.name='rose'为一个常量,所以 ref=const。
  • tb_dept 为唯一索引扫描,从 sql 语句可以看出,实际使用了 PRIMARY 主键索引,ref=db01.tb_emp.deptid 表示关联了 db01 数据库中 tb_emp 表的 deptid 字段。

十、rows


根据表信息统计以及索引的使用情况,大致估算说要找到所需记录需要读取的行数,rows 越小越好

十一、extra


不适合在其他列显示出来,但在优化时十分重要的信息

using  fileSort(重点优化)

俗称 " 文件排序 " ,在数据量大的时候几乎是“九死一生”,在 order by 或者在 group by 排序的过程中,order by 的字段不是索引字段,或者 select 查询字段存在不是索引字段,或者 select 查询字段都是索引字段,但是 order by 字段和 select 索引字段的顺序不一致,都会导致 fileSort

using temporary(重点优化)

使用了临时表保存中间结果,常见于 order by 和 group by 中。

USING index(重点)

表示相应的 select 操作中使用了覆盖索引(Coveing Index),避免访问了表的数据行,效率不错! 如果同时出现 using where,表明索引被用来执行索引键值的查找;如果没有同时出现 using where,表面索引用来读取数据而非执行查找动作。

Using wher

表明使用了 where 过滤

using join buffer

使用了连接缓存

impossible where

where 子句的值总是 false,不能用来获取任何元组

select tables optimized away

在没有 GROUPBY 子句的情况下,基于索引优化 MIN/MAX 操作或者 对于 MyISAM 存储引擎优化 COUNT(*)操作,不必等到执行阶段再进行计算, 查询执行计划生成的阶段即完成优化。

distinct

优化 distinct,在找到第一匹配的元组后即停止找同样值的工作

创作不易,辛苦大家动动手指 点个赞吧

查看原文

赞 1 收藏 0 评论 0

公众号_IT老哥 发布了文章 · 10月13日

老哥告诉你什么是MySQL索引

此后会针对数据库索引出一系列的文章,敬请期待

前言—学习索引几大理由

  • 高薪程序员必备知识,无论去哪里面试,数据库的索引优化是必考知识
  • 工作必备,无论任何系统都要和数据库打交道,当数据量达到百万级以上,查询速度就会变慢,影响数据库的并发,从而影响整体的系统并发
  • 不会数据库索引的程序员,不是一个合格的程序员,所以快来学习索引吧,哈哈

索引是什么

MySQL官方对索引的定义为:索引(Index)是帮助MySQL高校获取数据的数据结构。 可以得到索引的本质:索引是数据结构,索引的目的是提高查询效率,可以类比英语新华字典,如果我们要查询MySQL这个单词,首先我们需要在目录(索引)定位到M,然后在定位到y,以此类推找到SQL。 如果没有索引呢,那就需要从A到Z,去遍历的查找一遍,直到找到我们需要的,一个一个找和直接根据目录定位到数据,是不是差的天壤之别呢,这就是索引的妙用。 

索引底层数据结构

当数据量大的时候,索引的数据量也很大,所以索引不可能全部放到内存中,因此索引一般以文件的形式存储到硬盘上。

数据本身之外,数据库还维护着一个满足特定查找算法的数据结构,这些结构以某种方式指向数据,这样就可以基于这些数据结构实现高级查找算法。

索引算法种类

  • B-tree索引(重点掌握,之后文章详细讲解)
  • Hash索引
  • full-text索引
  • R-tree索引

索引的优势

  • 类似大学图书馆书目索引,提高数据检索效率,降低数据库IO成本
  • 通过索引列对数据进行排序,降低数据排序成本,降低了CPU消耗

索引的劣势

  • 实际上索引也是一张表,该表保存了主键和索引字段,并指向实体表的记录,所以索引列也是要占用空间的
  • 虽然索引大大提高了查询速度,同时却会降低更新表的速度,如果对表INSERT,UPDATE和DELETE。因为更新表时,MySQL不仅要不存数据,还要保存一下索引文件每次更新添加了索引列的字段,都会调整因为更新所带来的键值变化后的索引信息
  • 索引只是提高效率的一个因素,如果你的MySQL有大数据量的表,就需要花时间研究建立优秀的索引,或优化查询语句

索引分类

  • 单值索引:即一个索引只包含单个列,一个表可以有多个单列索引
  • 唯一索引:索引列的值必须唯一,但允许有空值
  • 复合索引:即一个索引包含多个列

索引语法

  • 创建一:create [unique] index indexName on tableName (columnName (length) )。
  • 如果是CHAR,VARCHAR类型,length可以小于字段实际长度;如果是

    BLOB和TEXT类型,必须指定length。

  • 创建二:alter tableName add [unique] index [indexName] on (columnName (length) )
  • 删除:DROP INDEX [indexName] ON mytable;
  • 查看:SHOW INDEX FROM table_nameG

哪些情况需要建索引

  • 主键自动建立唯一索引
  • 频繁作为查询的条件的字段应该创建索引
  • 查询中与其他表关联的字段,外键关系建立索引
  • 频繁更新的字段不适合创建索引:因为每次更新不单单是更新了记录还会更新索引,加重IO负担
  • Where条件里用不到的字段不创建索引
  • 单间/组合索引的选择问题(在高并发下倾向创建组合索引)
  • 查询中排序的字段,若通过索引去访问将大大提高排序的速度
  • 查询中统计或者分组字段

哪些不适合建索引

  • 表记录太少
  • 经常增删改的表
  • 数据重复且分布平均的表字段,因此应该只为经常查询和经常排序的数据列建立索引。注意,如果某个数据列包含许多重复的内容,为它建立索引就没有太大的实际效果。

今天索引先介绍到这来,之后文章会围绕索引优化讲解

敬请期待!!!

查看原文

赞 0 收藏 0 评论 2

公众号_IT老哥 关注了专栏 · 10月13日

SegmentFault 之声

在这里,我们将为你推送 SegmentFault 思否公司官方合作信息,和合作伙伴最新动态。SegmentFault 思否是中国领先的开发者社区和技术媒体,中国最大的 Hackathon 组织者。我们致力于成为科技企业和开发者沟通的桥梁,帮助科技企业和开发者对话。

关注 10130

认证与成就

  • 获得 49 次点赞
  • 获得 3 枚徽章 获得 0 枚金徽章, 获得 0 枚银徽章, 获得 3 枚铜徽章

擅长技能
编辑

开源项目 & 著作
编辑

(゚∀゚ )
暂时没有

注册于 10月13日
个人主页被 779 人浏览