要想学习设计模式呢 我们就必须搞清楚设计模式到底在我们的编程过程中起到了怎样的作用,在编程世界中它处在一个什么样的位置,它到底是一种抽象的设计思想,还是一套具体的落地方案.

在学习设计模式之前呢 我们需要了解一下 代码质量的评价标准和编程的方法论

我们经常会听到有人对项目代码进行评价,一般就会说：“代码写得很烂”或者“代码写得很好”。
用“好”“烂”这样的词汇来描述代码质量，非常地笼统。

对于程序员来说，辨别代码写得“好”还是“烂”，是一个非常重要的能力。这也是我们写出好代码的前提。

代码质量的评价标准非常之多,我这里就给大家介绍一下最常用的几个标准

评价代码的质量,有以下几个常用标准:

1 ) 可维护性

可维护性强的代码指的是: 在不去破坏原有的代码设计以及不引入新的BUG的前提下,能够快速的修改或者新增代码.

不易维护的代码指的是: 在添加或者修改一些功能逻辑的时候,存在极大的引入新的BUG的风险,并且需要花费的时间也很长.

代码可维护性的评判标准比较模糊, 因为是否易维护是针对维护的人员来说的,不同水平的人对于同一份代码的维护能力是不同的. 所谓 ‘’难者不会 会者不难’’. 对于同样的系统,熟悉它的资深工程师会觉得代码可维护性还可以,而新人则会因为能力不足、了解不够深入等原因觉得代码的可维护性不是很好.

2 ) 可读性

软件开发教父，Martin Fowler曾经说过一句话: “任何傻瓜都能够编写计算机能理解的代码，而优秀的程序员能够编写人类能理解的代码。” 这句话的意思非常容易理解,就是要求我们写出的代码是易读的、易理解的,因为代码的可读性会在很大程度上影响代码的可维护行性.

code review ( 代码审查,一种测试代码可读性的手段 )

1.检查代码风格和编程规范: 代码是否符合编码规范、命名是否达意、注释是否详尽、模块划分是否清晰等

2.检查常规的 bad smell 和代码 bug: 是否存在重复代码、过长函数、过大类、过于亲密的两个 classes等

3 ) 可扩展性

代码的可扩展性表示，我们在不修改或少量修改原有代码的情况下，通过扩展的方式添加新的功能代码。

可扩展性的背后其实就是: “对修改关闭,对扩展开放” 这条设计原则,后面我们会详细的讲解

4 ) 灵活性

“灵活” 是指在添加新代码的时候，已有代码能够不受影响，不产生冲突，不出现排斥，在保证自身不遭到破坏的前提下灵活地接纳新代码。

下面的几个场景,可以体现代码的灵活性

1.添加新的功能代码时,原有代码已经预留了扩展点,我们不需要修改 直接在扩展点上新增代码即可.

2.当我们想实现一个功能模块时,发现原有代码中,已经抽象出了很多底层可以复用的模块、类等代码,我们可以直接拿来使用

3.当我们使用某组接口时,这组接口可以应对各种使用场景,满足不同需求,这个接口设计的十分的灵活易用.

5 ) 简洁性

我们要遵从KISS ( Keep It Simple Stupid) 原则，代码要尽可能的简单；但是思从深而行从简，真正的高手能云淡风轻地用最简单的方法解决最复杂的问题。这也是一个编程老手跟编程新手的本质区别之一。

代码的写法应当使别人理解它所需的时间最小化.

6 ) 可复用性

代码的可复用性可以简单地理解为，尽量减少重复代码的编写，复用已有的代码.

可复用性也是一个非常重要的代码评价标准，是很多设计原则、思想、模式等所 要达到的最终效果

可复用性与DRY(Don’t Repeat Yourself) 避免编写重复的代码逻辑. 原则关系紧密,后面我们会介绍有哪些编程方法可以提高代码复用性.

7 ) 可测试性

单元测试在一个完整的软件开发流程中是必不可少的、非常重要的一个环节。通常写单元测试并不难，但有的时候，有的代码和功能难以测试，导致写起测试来困难重重。所以写出的代码具有可测试性，具有很重要的作用。

代码可测试性的好坏，能从侧面上非常准确地反应代码质量的好坏

编程方法论

想要拥有编写高质量代码的能力,我们就要学习一些编程的方法论.其中就包含面向对象（我们可以把它看成一种设计思想）、设计原则、设计模式、编程规范、重构技巧等等

接下来我就给大家介绍一下这几个概念和他们之间的联系,介绍这些呢 有助于大家对于整个课程中包含的知识点, 有一个全局的了解,将我们学到的知识有序的组织在头脑中,方便大家记忆.

代码重构的工具就是面向对象设计思想、设计原则、设计模式、编码规范。

1 ) 面向对象

面向对象是一种编程思想,也是一种编程范式. 现在比较流行的编程语言大部分都是面向对象编程语言.而大部分项目也都是基于面向对象编程风格进行开发的.

作为一名Java程序员,相信同学们对于面向对象的特点,以及面向对象思想在实际工作中的应用,都有一定深度的了解,这里边关于面向对象的一些相关知识点我们就不做赘述了.

2 ) 设计原则 (本次课程重点讲解)

设计原则是指导我们代码设计的一些经验总结。在软件开发中，为了提高软件系统的可维护性和可复用性，增加软件的可扩展性和灵活性，程序员要尽量根据设计原则来开发程序，从而提高软件开发效率、节约软件开发成本和维护成本。

常用的设计原则

• 单一职责原则
• 开闭原则
• 里氏代换原则
• 依赖倒转原则
• 接口隔离原则
• 迪米特法则

设计原则的特点就是比较的抽象,大家不需要死记硬背.每个人根据自己所积累的经验和所处的业务场景, 去灵活的运用这些原则即可

3 ) 设计模式 (本次课程重点讲解)

设计模式是针对软件开发中经常遇到的一些设计问题，总结出来的一套解决方案或者设计思 路。大部分设计模式要解决的都是代码的可扩展性问题。

设计模式是遵循设计原则的, 设计模式相对于设计原则来说，没有那么抽象，而且大部分都不难理解，代码实现也并不复杂。这一块的学习难点是了解它们 都能解决哪些问题，掌握典型的应用场景，并且懂得不过度应用。

4 ) 编程规范

编程规范主要解决的是代码的可读性问题。编码规范相对于设计原则、设计模式，更加具 体、更加偏重代码细节。

对于编码规范，考虑到很多书籍已经讲得很好了（比如《编写可读性代码的艺术》《代码大全》《代码整洁之 道》等）。而且，每条编码规范都非常简单、非常明确，比较偏向于记忆，你只要照着来做 可以。

5 ) 重构

维基百科: 在软件工程学里，重构代码一词通常是指在不改变代码的外部行为情况下而修改源代码，有时非正式地称为“清理干净”。在极限编程或其他敏捷方法学中，重构常常是软件开发循环的一部分：开发者轮流增加新的测试和功能，并重构代码来增进内部的清晰性和一致性。

在软件开发中，只要软件在不停地迭代，就没有一劳永逸的设计。随着需求的变化，代码的 不停堆砌，原有的设计必定会存在这样那样的问题。针对这些问题，我们就需要进行代码重构。重构是软件开发中非常重要的一个环节。持续重构是保持代码质量不下降的有效手段， 能有效避免代码腐化到无可救药的地步。

6 ) 总结

提高代码质量的方法论包含:

• 面向对象思想 (基础)
• 设计原则 (指导方针)
• 设计模式 (设计原则的具体实现)
• 编程规范 (提高代码可读性)
• 重构 (面向对象设计思想、设计原则、设计模式、编码规范的融合贯通)

设计原则是高手的内功，设计模式是少林，武当，峨眉派的武术套路，规范是招式 出拳还 是横扫，重构是组合拳 融汇贯通各种组合，而想练好这些武功还要有扎实的基本功 面向对 象,在这里呢 也提醒同学们一句,不要一味的去追求最新的技术(并不是说这样做不好,但是千万不要本末倒置),而忘记了一个程序员最重要的能力 是写出高质量的代码.

设计模式概述

• 设计模式（Design pattern）是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结

  在GOF编写的设计模式(可复用面向对象软件的基础)一书中说道: 本书涉及的设计模式并不描述新的或未经证实的设计，我们只收录那些在不同系统中多次使用过的成功设计。

• 大部分设计模式要解决的都是代码的可重用性、可扩展性问题

如果说数据结构和算法是教你如何写出高效代码，那设计模式讲的是如何写出可扩展、可读、可维护的高质量代码，所以，它们跟平时的编码会有直接的关系，也会直接影响到你的开发能力。

• 学习设计模式的好处

  • 能够从容应对面试中的设计模式相关问题

    我们学习技术从最功利的角度讲,就是为了拿到心仪的offer,得到想要的薪资.所以在面试时特别是面试一些BAT大厂时,如果被问到设计模式的问题, 因为我们学了本次课程, 就不会再惧怕这些问题,设计模式反而会成为你面试中的亮点.

  • 不再编写 bullshit-code

    代码能力是一个程序员最基础的能力，是基本功，是展示一个程序员基础素养的最直接的衡量标准。你写的代码，实 际上就是你名片。我们通过学习设计模式,告别烂代码的编写,避免比如类设计不合理,代码结构混乱,分层不清晰 等等这样的代码问题. 让我们编写的代码成为团队中的标杆.

  • 提高复杂代码的设计和开发能力

    不再只是根据业务需求翻译代码,填充代码. 而是能够通过所学习的设计模式的相关知识写出高质量的代码.即使面对复杂代码功能或者系统的设计开发也能得心应手.

  • 有助于我们读懂源码,学习框架更加事半功倍

    对于一个有追求的程序员来说，对技术的积累，既要有广度，也要有深度。所以我们需要更多的去学习研究各种框架,中间件的底层原理,而这些优秀的框架 中间件的源码中会使用到很多设计思想 设计原则 设计模式 ,所以为了更好的独懂这些开源项目,我们必须好设计模式相关知识.

产生背景

“设计模式” 最初并不是出现在软件设计中，而是被用于建筑领域的设计中。

1977年美国著名建筑大师、加利福尼亚大学伯克利分校环境结构中心主任克里斯托夫·亚历山大（Christopher Alexander）在他的著作《建筑模式语言：城镇、建筑、构造》中描述了一些常见的建筑设计问题，并提出了 253 种关于对城镇、邻里、住宅、花园和房间等进行设计的基本模式。

四人帮（GOF）

1990年软件工程界开始研讨设计模式的话题，后来召开了多次关于设计模式的研讨会。

在之前设计模式的绝大部分以往并无文本记录，它们或是来源于面向对象设计者圈子里的非正式交流，或是来源于某些成功的面向对象系统的某些部分，但对设计新手来说，这些东西是很难学得到的。尽管这些设计不包括新的思路，但我们用一种新的、便于理解的方式将其展现给读者，即：具有统一格式的、已分类编目的若干组设计模式。

1994 年，艾瑞克·伽马（ErichGamma）、理査德·海尔姆（Richard Helm）、拉尔夫·约翰森（Ralph Johnson）、约翰·威利斯迪斯（John Vlissides）等 4 位作者合作出版了《设计模式：可复用面向对象软件的基础》一书，在此书中收录了 23 个设计模式，这是设计模式领域里程碑的事件，导致了软件设计模式的突破。

备注：由于书名太长， 人们将其简称为 “四人组 （Gang of Four， GoF） 的书”， 并且很快进一步简化为 “GoF 的书

设计模式分类

按照不同的业务领域和场景的复杂程度，以及选择不同的设计模式，在整个系统建设落地中都会有不同的呈现形式。

就像出行可以选择不同的交通工具一样，如近距离骑自行车、中短程驾车、远程乘坐高铁或飞机等

GoF设计模式只有23个，但是它们各具特色 ，每个模式都为某一个可重复的设计问题提供了一套解决方案。

根据它们的用途，设计模式可分为 创建型(Creational) ，结构型(Structural) 和行为型(Behavioral)

• 创建型模式(5种)：提供创建对象的机制，提升已有代码的灵活性和可复用性

  常用的有：单例模式、工厂模式（工厂方法和抽象工厂）、建造者模式。

  不常用的有：原型模式。

  

• 结构型模式(7种)：介绍如何将对象和类组装成较大的结构，并同时保持结构的灵活和高效

  常用的有：代理模式、桥接模式、装饰者模式、适配器模式。

  不常用的有：门面模式、组合模式、享元模式。

  

• 行为模式(11种)：负责对象间的高效沟通和职责传递委派

  常用的有：观察者模式、模板模式、策略模式、职责链模式、迭代器模式、状态模式。
  不常用的有：访问者模式、备忘录模式、命令模式、解释器模式、中介模式。

UML图

统一建模语言（Unified Modeling Language，UML）是用来设计软件的可视化建模语言。它的特点是简单、统一、图形化、能表达软件设计中的动态与静态信息。

UML 从目标系统的不同角度出发，定义了用例图、类图、对象图、状态图、活动图、时序图、协作图、构件图、部署图等 9 种图。

这里我们只介绍类图.

我们要去研究一个设计模式的时候,是需要借助UML类图更加准确的描述所使用的设计模式,和设计模式下类与类之间的关系

类图概述

类图(Class diagram)是显示了模型的静态结构，特别是模型中存在的类、类的内部结构以及它们与其他类的关系等。类图不显示暂时性的信息。类图是面向对象建模的主要组成部分。

类图的作用

• 在软件工程中，类图是一种静态的结构图，描述了系统的类的集合，类的属性和类之间的关系，可以简化了人们对系统的理解；
• 类图是系统分析和设计阶段的重要产物，是系统编码和测试的重要模型。

类图表示法

UML类图中具体类、抽象类、接口和包有不同的表示方法。

在UML类图中表示具体类

具体类在类图中用矩形框表示，矩形框分为三层：第一层是类名字。第二层是类的成员变量；第三层是类的方法。成员变量以及方法前的访问修饰符用符号来表示：

• “+” 表示 public；
• “-” 表示 private；
• “#” 表示 protected；
• 不带符号表示 default。

在UML类图中表示抽象类

抽象类在UML类图中同样用矩形框表示，但是抽象类的类名以及抽象方法的名字都用斜体字表示，如图所示。

在UML类图中表示接口

接口在类图中也是用矩形框表示，但是与类的表示法不同的是，接口在类图中的第一层顶端用构造型 <>表示，下面是接口的名字，第二层是方法。

此外，接口还有另一种表示法，俗称棒棒糖表示法，就是类上面的一根棒棒糖（圆圈+实线）。圆圈旁为接口名称，接口方法在实现类中出现。

在类图中表示关系

类和类、类和接口、接口和接口之间存在一定关系，UML类图中一般会有连线指明它们之间的关系。

关系共有六种类型 ,如下图:

实现关系

实现关系是接口与实现类之间的关系。在这种关系中，类实现了接口，类中的操作实现了接口中所声明的所有的抽象操作。

在 UML 类图中，实现关系使用带空心三角箭头的虚线来表示，箭头从实现类指向接口。

例如，汽车和船实现了交通工具，其类图:

泛化关系

泛化关系是对象之间耦合度最大的一种关系，表示一般与特殊的关系，是父类与子类之间的关系，是一种继承关系。

在 UML 类图中，泛化关系用带空心三角箭头的实线来表示，箭头从子类指向父类。在代码实现时，使用面向对象的继承机制来实现泛化关系。

例如，Student 类和 Teacher 类都是 Person 类的子类，其类图如下图所示：

关联关系

关联关系是对象之间的一种引用关系，用于表示一类对象与另一类对象之间的联系，如老师和学生、师傅和徒弟、丈夫和妻子等。关联关系是类与类之间最常用的一种关系，分为一般关联关系、聚合关系和组合关系。

我们先介绍一般关联关系, 一般关联关系又可以分为单向关联，双向关联，自关联。

1) 单向关联

在UML类图中单向关联用一个带箭头的实线表示。上图表示每个顾客都有一个地址，这通过让Customer类持有一个类型为Address的成员变量类实现。

2) 双向关联

​

从上图中我们很容易看出，所谓的双向关联就是双方各自持有对方类型的成员变量。

在UML类图中，双向关联用一个不带箭头的直线表示。上图中在Customer类中维护一个List\，表示一个顾客可以购买多个商品；在Product类中维护一个Customer类型的成员变量表示这个产品被哪个顾客所购买。

3) 自关联

​

自关联在UML类图中用一个带有箭头且指向自身的线表示。上图的意思就是Node类包含类型为Node的成员变量，也就是“自己包含自己”。

聚合关系

聚合关系是关联关系的一种，表示一种弱的‘拥有’关系，体现的是A对象可以包含B对象，但是B对象不是A对象的一部分

在代码中: 比如A 类对象包含 B 类对象，B 类对象的生命周期可以不依赖 A 类对象的生命周期，也就是说可以单独销毁 A 类对象而不影响 B 对象

1
2
3
4
5
6
7
8

public class A{

private B b;

public A(B b){
this.b = b;
}
}

在 UML 类图中，聚合关系可以用带空心菱形的实线来表示，菱形指向整体。

下图所示是大学和教师的关系图：

组合关系

组合关系是一种强‘拥有’关系，体现了严格的部分和整体的关系，部分和整体的声明周期一样

在代码中: 比如A 类对象包含 B 类对象，B 类对象的生命周期依赖A 类对象的生命周期，B 类对象不可以单独存在

1
2
3
4
5
6
7
8
9

public class A{
    
    private B b;
    
    public A(){
        this.b = new B();
    }
    
}

在 UML 类图中，组合关系用带实心菱形的实线来表示，菱形指向整体。

下图所示是头和嘴的关系图：

​

依赖关系

依赖关系是一种使用关系，它是对象之间耦合度最弱的一种关联方式，是临时性的关联。

在代码中，某个类的方法通过局部变量、方法的参数或者对静态方法的调用来访问另一个类（被依赖类）中的某些方法来完成一些职责。

在 UML 类图中，依赖关系使用带箭头的虚线来表示，箭头从使用类指向被依赖的类。

下图所示是司机和汽车的关系图，司机驾驶汽车：

​

UML类图总结

之前我们一共学习了六种类关系的表示方式

• 实现关系
• 泛化关系
• 关联关系
• 聚合关系
• 组合关系
• 依赖关系

为了节省学习成本, 方便记忆,我们可以将类和类之间的关系重新调整一下,使其更加贴近编程的角度:

• 实现关系
• 泛化关系
• 依赖关系
• 组合关系 (组合关系+关联关系+聚合关系)

我们也没有必要去区分组合与聚合这两个概念,只需要记住一点就是: 多用组合少用继承

也就是说只要 B 类对象是 A 类对象的成员变量，那我们就称，A 类跟 B 类是组合关 系.

六大设计原则 (SOLID)

设计原则概述

古人云: 有道无术,术可求.有术无道,止于术.

而设计模式通常需要遵循一些设计原则，在设计原则的基础之上衍生出了各种各样的设计模式。设计原则是设计要求，设计模式是设计方案，使用设计模式的代码则是具体的实现。

设计模式中主要有六大设计原则，简称为SOLID ，是由于各个原则的首字母简称合并的来(两个L算一个,solid 稳定的)，六大设计原则分别如下：

​ 1、单一职责原则（Single Responsibitity Principle）

​ 2、开放封闭原则（Open Close Principle）

​ 3、里氏替换原则（Liskov Substitution Principle）

​ 4、接口分离原则（Interface Segregation Principle）

​ 5、依赖倒置原则（Dependence Inversion Principle）

​ 6、迪米特法则（Law Of Demter）

软件开发中我们要基于这六个原则,设计建立稳定、灵活、健壮的程序.

单一职责原则

官方定义

单一职责原则，英文缩写SRP，全称 Single Responsibility Principle。

在<<架构整洁之道>>一书中 关于这个原则的英文描述是这样的：A class or module should have a single responsibility 。如果我们把它翻译成中文，那就是：一个类或者模块只负责完成一个职责（或者功能）。

通俗解释

单一职责原则的定义描述非常简单，也不难理解。一个类只负责完成一个职责或者功能。

也就是说在类的设计中 我们不要设计大而全的类,而是要设计粒度小、功能单一的类.

比如 我们设计一个类里面既包含了用户的一些操作,又包含了支付的一些操作,那这个类的职责就不够单一,应该将该类进行拆分,拆分成多个功能更加单一的,粒度更细的类.

场景示例

那么该如何判断一个类的职责是否单一 ?

其实在软件设计中，要真正用好单一职责原则并不简单，因为遵循这一原则最关键的地方在于职责的划分，而职责的划分是根据需求定的，同一个类（接口）的设计，在不同的需求里面，可能职责的划分并不一样.

我们来看下面这个例子:

在一个社交媒体产品中,我们使用UserInfo去记录用户的信息,包括如下的属性.

请问上面的UserInfo类是否满足单一职责原则呢 ?

• 观点1: 满足,因为记录的都是跟用户相关的信息
• 观点2: 不满足,因为地址信息应该被拆分出来,单独放到地址表中保存.

正确答案: 根据实际业务场景选择是否拆分

• 该社交产品的有用户信息只是用来展示的,那么这个类这样设计就没有问题
• 假设后面这个社交产品又添加了电商模块, 那就需要将地址信息提取出来,单独设计一个类

总结: 不同的应用场景、不同阶段的需求背景下，对同一个类的职责是否单一的判定，可能都是不一样的,最好的方式就是:

我们可以先写一个粗粒度的类，满足业务需求。随着业务的发展，如果粗粒度的类越来越庞大，代码越来越多，这个时候，我们就可以将这个粗粒度的类，拆分成几个更细粒度的类。这就是所谓的持续重构

如何判断一个类的职责是否单一?

这里没有一个具体的金科玉律，但从实际代码开发经验上，有一些可执行性的侧面判断指标，可供参考：

• 类中的代码行数、函数、或者属性过多；

• 类依赖的其他类过多

• 私有方法过多

• 类中大量的方法都是集中操作类中的几个属性

开闭原则

官方定义

一般认为最早提出开闭原则（Open-Close Principle，OCP）的是伯特兰·迈耶。他在1988 年发表的《面向对象软件构造》中给出的。在面向对象编程领域中，

开闭原则规定软件中的对象、类、模块和函数对扩展应该是开放的，但对于修改是封闭的。这意味着应该用抽象定义结构，用具体实现扩展细节，以此确保软件系统开发和维护过程的可靠性。

通俗解释

定义：对扩展开放，对修改关闭

对扩展开放和对修改关闭表示当一个类或一个方法有新需求或者需求发生改变时应该采用扩展的方式而不应该采用修改原有逻辑的方式来实现。因为扩展了新的逻辑如果有问题只会影响新的业务，不会影响老业务；而如果采用修改的方式，很有可能就会影响到老业务受影响。

开闭原则是所有设计模式的最核心目标，也是最难实现的目标，但是所有的软件设计模式都应该以开闭原则当作标准，才能使软件更加的稳定和健壮。

优点：

1. 新老逻辑解耦，需求发生改变不会影响老业务的逻辑

2. 改动成本最小，只需要追加新逻辑，不需要改的老逻辑

3. 提供代码的稳定性和可扩展性

场景示例

系统A与系统B之间进行数据传输使用的是427版本的协议，一年以后对427版本的协议进行了修正。

设计时应该考虑的数据传输协议的可变性，抽象出具有报文解译、编制、校验等所有版本协议使用的通用方法，调用方针对接口进行编程即可，如上述示例设计类图如下

调用方依赖于报文接口，报文接口是稳定的，而不针对具体的427协议或427修正协议。利用接口多态技术，实现了开闭原则。

顶层设计思维

• 抽象意识
• 封装意识
• 扩展意识

在写代码的时候后，我们要多花点时间往前多思考一下，这段代码未来可能有哪些需求变 更、如何设计代码结构，事先留好扩展点，以便在未来需求变更的时候，不需要改动代码整 体结构、做到最小代码改动的情况下，新的代码能够很灵活地插入到扩展点上，做到“对扩 展开放、对修改关闭”。

里氏替换原则

官方定义

里氏替换原则（Liskov Substitution Principle，LSP）是由麻省理工学院计算机科学系教授芭芭拉·利斯科夫于 1987 年在“面向对象技术的高峰会议”（OOPSLA）上发表的一篇论文《数据抽象和层次》（Data Abstractionand Hierarchy）里提出的.

她在论文中提到：如果S是T的子类型，对于S类型的任意对象，如果将他们看作是T类型的对象，则对象的行为也理应与期望的行为一致。

子类对象能够替换程序中父类对象出现的任何地方，并且保证原来程序的逻辑行为不变及正确性不被破坏。

通俗解释

如何理解里氏替换原则？

要理解里氏替换原则，其实就是要理解两个问题：

• 什么是替换？
• 什么是与期望行为一致的替换（Robert Martin所说的“必须能够替换”）？

1 ) 什么是替换 ?

替换的前提是面向对象语言所支持的多态特性，同一个行为具有多个不同表现形式或形态的能力。

以JDK的集合框架为例，List接口的定义为有序集合，List接口有多个派生类，比如大家耳熟能详的ArrayList, LinkedList。那当某个方法参数或变量是List接口类型时，既可以是ArrayList的实现, 也可以是LinkedList的实现，这就是替换。

2 ) 什么是与期望行为一致的替换？

在不了解派生类的情况下，仅通过接口或基类的方法，即可清楚的知道方法的行为，而不管哪种派生类的实现，都与接口或基类方法的期望行为一致。

不需要关心是哪个类对接口进行了实现,因为不管底层如何实现,最终的结果都会符合接口中关于方法的描述(也就是与接口中方法的期望行为一致).

或者说接口或基类的方法是一种契约，使用方按照这个契约来使用，派生类也按照这个契约来实现。这就是与期望行为一致的替换。

场景示例

里氏替换原则要求我们在编码时使用基类或接口去定义对象变量，使用时可以由具体实现对象进行赋值，实现变化的多样性，完成代码对修改的封闭，扩展的开放。

比如在一个商城项目中, 定义结算接口Istrategy，该接口有三个具体实现类，分别为 PromotionalStrategy （满减活动，两百以上百八折）、RebateStrategy （打折活动）、 ReduceStrategy（返现活动）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

public interface Istrategy {
    public double realPrice(double consumePrice);
}

public class PromotionalStrategy implements Istrategy {
    public double realPrice(double consumePrice) {
        if (consumePrice > 200) {
            return 200 + (consumePrice - 200) * 0.8;
        } else {
            return consumePrice;
        }
    }
}
public class RebateStrategy implements Istrategy {
    private final double rate;
    public RebateStrategy() {
        this.rate = 0.8;
    }
    public double realPrice(double consumePrice) {
        return consumePrice * this.rate;
    }
}
public class ReduceStrategy implements Istrategy {
    public double realPrice(double consumePrice) {
        if (consumePrice >= 1000) {
            return consumePrice - 200;
        } else {
            return consumePrice;
        }
    }
}

调用方为Context，在此类中使用接口定义了一个对象。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

public class Context {
    //使用基类定义对象变量
    private Istrategy strategy;
    // 注入当前活动使用的具体对象
    public void setStrategy(Istrategy strategy) {
        this.strategy = strategy;
    }
    // 计算并返回费用
    public double cul(double consumePrice) {
        // 使用具体商品促销策略获得实际消费金额
        double realPrice = this.strategy.realPrice(consumePrice);
        // 格式化保留小数点后1位，即：精确到角
        BigDecimal bd = new BigDecimal(realPrice);
        bd = bd.setScale(1, BigDecimal.ROUND_DOWN);
        return bd.doubleValue();
    }
}

Context 中代码使用接口定义对象变量，这个对象变量可以是实现了lStrategy接口的PromotionalStrategy、RebateStrategy 、 ReduceStrategy任意一个。

里氏代换原则与多态的区别 ?

虽然从定义描述和代码实现上 来看，多态和里式替换有点类似，但它们关注的角度是不一样的。多态是面向对象编程的一 大特性，也是面向对象编程语言的一种语法。它是一种代码实现的思路。而里式替换是一种 设计原则，用来指导继承关系中子类该如何设计，子类的设计要保证在替换父类的时候，不 改变原有程序的逻辑及不破坏原有程序的正确性。

里氏替换原则和依赖倒置原则，构成了面向接口编程的基础，正因为里氏替换原则，才使得程序呈现多样性。

接口隔离原则

官方定义

<<代码整洁之道>>作者罗伯特 C·马丁 为 “接口隔离原则” 的定义是：客户端不应该被迫依赖于它不使用的方法（Clients should not be forced to depend on methods they do not use）。

该原则还有另外一个定义：一个类对另一个类的依赖应该建立在最小的接口上

通俗解释

上面两个定义的含义用一句话概括就是：要为各个类建立它们需要的专用接口，而不要试图去建立一个很庞大的接口供所有依赖它的类去调用。

接口隔离原则与单一职责原则的区别

接口隔离原则和单一职责都是为了提高类的内聚性、降低它们之间的耦合性，体现了封装的思想，但两者是不同的：

• 单一职责原则注重的是职责，而接口隔离原则注重的是对接口依赖的隔离。
• 单一职责原则主要是约束类，它针对的是程序中的实现和细节；接口隔离原则主要约束接口，主要针对抽象和程序整体框架的构建。

场景示例

微服务用户系统提供了一组跟用户相关的 API 给其他系统 使用，比如：注册、登录、获取用户信息等。

1
2
3
4
5
6
7
8
9
10

public interface UserService {
    boolean register(String cellphone, String password);
    boolean login(String cellphone, String password);
    UserInfo getUserInfoById(long id);
    UserInfo getUserInfoByCellphone(String cellphone);
}

public class UserServiceImpl implements UserService {
//...
}

需求: 后台管理系统要实现删除用户的功能，希望用户系统提供一个删除用户的接口,应该如何设计这个接口(假设这里我们不去考虑使用鉴权框架).

• 方案1: 直接在UserService接口中添加一个删除用户的接口

  这个方法可以解决问题，但是也隐藏了一些安全隐患。删除用户是一个非常慎重的操作，我们只希望通过后台管理系统来执行，所以这个接口只限于给后台管理系统使用。如果我们把它放到 UserService 中，那所有使用到 UserService
  的系统，都可以调用这个接口。不加限制地被其他业务系统调用，就有可能导致误删用户。

• 方案2: 遵照接口隔离原则,为依赖接口的类定制服务。只提供调用者需要的方法，屏蔽不需要的方法。

​ 将删除接口单独放到另外 一个接口 RestrictedUserService 中, 然后将 RestrictedUserService 只打包提供给后台管理系统来 使用。

​

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

public interface UserService {
    boolean register(String cellphone, String password);
    boolean login(String cellphone, String password);
    UserInfo getUserInfoById(long id);
    UserInfo getUserInfoByCellphone(String cellphone);
}

public interface RestrictedUserService {
 boolean deleteUserByCellphone(String cellphone);
 boolean deleteUserById(long id);
}

public class UserServiceImpl implements UserService, RestrictedUserService {
//...
}

遵循接口隔离原则的优势

1. 将臃肿庞大的接口分解为多个粒度小的接口，可以预防外来变更的扩散，提高系统的灵活性和可维护性。
2. 使用多个专门的接口还能够体现对象的层次，因为可以通过接口的继承，实现对总接口的定义。
3. 能减少项目工程中的代码冗余。过大的大接口里面通常放置许多不用的方法，当实现这个接口的时候，被迫设计冗余的代码.

依赖倒置原则

官方定义

依赖倒置原则是Robert C.Martin于1996年在C++Report上发表的文章中提出的。

1
2

High level modules should not depend upon low level modules. Both should depend upon abstractions.
Abstractions should not depend upon details. Details should depend upon abstractions

依赖倒置原则（Dependence Inversion Principle，DIP）是指在设计代码架构时，高层模块不应该依赖于底层模块，二者都应该依赖于抽象。抽象不应该依赖于细节，细节应该依赖于抽象。

通俗解释

依赖倒置原则是实现开闭原则的重要途径之一，它降低了客户与实现模块之间的耦合。

1. 高层级的模块应该依赖的是低层级的模块的行为的抽象，取决于具体编程语言，可以是抽象类或者接口等技术；
2. 第2句话其实很简单，只有一个意思：只要依赖了实现，就是耦合了代码，所以我们需要始终依赖的是抽象，而不是实现。

• 传统的自定向下的设计

  传统设计方式采用自顶向下的原则， 逐级依赖，中层模块和高层模块的耦合度很高，如果需要修改其中的一个模块，则可能会导致其它很多模块也需要修改，牵一发动全身，不易于维护。

  不使用依赖反转的系统构架，控制流和依赖关系流的依赖箭头是一个方向的，由高层指向底层，也就是高层依赖底层

• 依赖倒置原则

  依赖倒置原则的好处:

  • 减少类间的耦合性，提高系统的稳定性 . (根据类与类之间的耦合度从弱到强排列：依赖关系、关联关系、聚合关系、组合关系、泛化关系和实现关系 )
  • 降低并行开发引起的风险 (两个类之间有依赖关系，只要制定出两者之间的接口（或抽象类）就可以独立开发了)
  • 提高代码的可读性和可维护性

​

场景示例

假设我们现在要组装一台电脑,需要的配件有 cpu，硬盘，内存条。只有这些配置都有了，计算机才能正常的运行。选择cpu有很多选择，如Intel，AMD等，硬盘可以选择希捷，西数等，内存条可以选择金士顿，海盗船等。

代码如下：

希捷硬盘类（XiJieHardDisk）:

1
2
3
4
5
6
7
8
9
10
11

public class XiJieHardDisk implements HardDisk {

    public void save(String data) {
        System.out.println("使用希捷硬盘存储数据" + data);
    }

    public String get() {
        System.out.println("使用希捷希捷硬盘取数据");
        return "数据";
    }
}

Intel处理器（IntelCpu）：

1
2
3
4
5
6

public class IntelCpu implements Cpu {

    public void run() {
        System.out.println("使用Intel处理器");
    }
}

金士顿内存条（KingstonMemory）：

1
2
3
4
5
6

public class KingstonMemory implements Memory {

    public void save() {
        System.out.println("使用金士顿作为内存条");
    }
}

电脑（Computer）：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

public class Computer {

    private XiJieHardDisk hardDisk;
    private IntelCpu cpu;
    private KingstonMemory memory;

    public IntelCpu getCpu() {
        return cpu;
    }

    public void setCpu(IntelCpu cpu) {
        this.cpu = cpu;
    }

    public KingstonMemory getMemory() {
        return memory;
    }

    public void setMemory(KingstonMemory memory) {
        this.memory = memory;
    }

    public XiJieHardDisk getHardDisk() {
        return hardDisk;
    }

    public void setHardDisk(XiJieHardDisk hardDisk) {
        this.hardDisk = hardDisk;
    }

    public void run() {
        System.out.println("计算机工作");
        cpu.run();
        memory.save();
        String data = hardDisk.get();
        System.out.println("从硬盘中获取的数据为：" + data);
    }
}

测试类（TestComputer）：

测试类用来组装电脑。

1
2
3
4
5
6
7
8
9
10

public class TestComputer {
    public static void main(String[] args) {
        Computer computer = new Computer();
        computer.setHardDisk(new XiJieHardDisk());
        computer.setCpu(new IntelCpu());
        computer.setMemory(new KingstonMemory());

        computer.run();
    }
}

上面代码可以看到已经组装了一台电脑，但是似乎组装的电脑的cpu只能是Intel的，内存条只能是金士顿的，硬盘只能是希捷的，这对用户肯定是不友好的，用户有了机箱肯定是想按照自己的喜好，选择自己喜欢的配件。

根据依赖倒转原则进行改进：

代码我们需要修改Computer类，让Computer类依赖抽象（各个配件的接口），而不是依赖于各个组件具体的实现类。

类图如下：

电脑（Computer）：

1
2
3
4
5
6
7
8
9
10
11
12

public class Computer {

    private HardDisk hardDisk;
    private Cpu cpu;
    private Memory memory;

    //getter/setter......
    
    public void run() {
        System.out.println("计算机工作");
    }
}

关于依赖倒置、依赖注入、控制反转这三者之间的区别与联系

1 ) 依赖倒置原则

依赖倒置是一种通用的软件设计原则, 主要用来指导框架层面的设计。

高层模块不依赖低层模块，它们共同依赖同一个抽象。抽象不要依赖具体实现细节，具体实现细节依赖抽象。

2 ) 控制反转

控制反转与依赖倒置有一些相似, 它也是一种框架设计常用的模式,但并不是具体的方法。

“控制”指的是对程序执行流程的控制，而“反转”指的是在没有使用框架之前，程序员自己控制整个程序的执行。在使用框架之后，整个程序的执行流程通过框架来控制。流程的控制权从程序员“反转”给了框架。

Spring框架，核心模块IoC容器,就是通过控制反转这一种思想进行设计的

3 ) 依赖注入

依赖注入是实现控制反转的一个手段，它是一种具体的编码技巧。

我们不通过 new 的方式在类内部创建依赖的对象，而是将依赖的对象在外部创建好之后，通过构造函数等
方式传递（或注入）进来, 给类来使用。

依赖注入真正实现了面向接口编程的愿景，可以很方便地替换同一接口的不同实现，而不会影响到依赖这个接口的客户端。

迪米特法则

官方定义

1987年秋天，迪米特法则由美国Northeastern University的Ian Holland(伊恩 霍兰德)提出，被UML的创始者之一Booch(布奇)等人普及。后来，因为经典著作The PragmaticProgrammer <<程序员修炼之道>>而广为人知。

迪米特法则（LoD：Law of Demeter）又叫最少知识原则（LKP：Least Knowledge Principle ），指的是一个类/模块对其他的类/模块有越少的了解越好。简言之：talk only to your immediate friends（只跟你最亲密的朋友交谈），不跟陌生人说话。

通俗解释

大部分设计原则和思想都非常抽象，有各种各样的解读，要想灵活地应用到 实际的开发中，需要有实战经验的积累。迪米特法则也不例外。

简单来说迪米特法则想要表达的思想就是: 不该有直接依赖关系的类之间，不要有依赖；有依赖关系的类之间，尽量只依赖必要的接口。

如果两个软件实体无须直接通信，那么就不应当发生直接的相互调用，可以通过第三方转发该调用。其目的是降低类之间的耦合度，提高模块的相对独立性。

场景示例

我们一起来看下面这个例子:

明星由于全身心投入艺术，所以许多日常事务由经纪人负责处理，如和粉丝的见面会，和媒体公司的业务洽淡等。这里的经纪人是明星的朋友，而粉丝和媒体公司是陌生人，所以适合使用迪米特法则。

迪米特法则的独特之处在于它简洁而准确的定义，它允许在编写代码时直接应用，几乎自动地应用了适当的封装、高内聚和低耦合。

但是，过度使用迪米特法则会使系统产生大量的中介类，从而增加系统的复杂性，使模块之间的通信效率降低。所以，在釆用迪米特法则时需要反复权衡，确保高内聚和低耦合的同时，保证系统的结构清晰。

代码如下：

明星类（Star）

1
2
3
4
5
6
7
8
9
10
11

public class Star {
    private String name;

    public Star(String name) {
        this.name=name;
    }

    public String getName() {
        return name;
    }
}

粉丝类（Fans）

1
2
3
4
5
6
7
8
9
10
11

public class Fans {
    private String name;

    public Fans(String name) {
        this.name=name;
    }

    public String getName() {
        return name;
    }
}

媒体公司类（Company）

1
2
3
4
5
6
7
8
9
10
11

public class Company {
    private String name;

    public Company(String name) {
        this.name=name;
    }

    public String getName() {
        return name;
    }
}

经纪人类（Agent）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

public class Agent {
    private Star star;
    private Fans fans;
    private Company company;

    public void setStar(Star star) {
        this.star = star;
    }

    public void setFans(Fans fans) {
        this.fans = fans;
    }

    public void setCompany(Company company) {
        this.company = company;
    }

    public void meeting() {
        System.out.println(fans.getName() + "与明星" + star.getName() + "见面了。");
    }

    public void business() {
        System.out.println(company.getName() + "与明星" + star.getName() + "洽淡业务。");
    }
}

设计原则总结

我们之前给的大家介绍了评判代码质量的标准,比如可读性、可复用性、可扩展性等等,这是从代码的整体质量的角度来评判.

而设计原则就是我们要使用到的更加具体的对于代码进行评判的标准,比如, 我们说这段代码的可扩展性比较差，主要原因是违背了开闭原则。

我们所学习的SOLID 原则它包含了：

1. 单一职责原则（SRP）
2. 开闭原则（OCP）
3. 里氏替换原则（LSP）
4. 接口隔离原则（ISP）
5. 依赖倒置原则（DIP）
6. 迪米特法则 (LKP)

这里我们只需要重点关注三个常用的原则即可:

1 ) 单一职责原则

单一职责原则是类职责划分的重要参考依据，是保证代码”高内聚“的有效手段，是我们在进行面向对象设计时的主要指导原则。

单一职责原则的难点在于，对代码职责是否足够单一的判定。这要根据具体的场景来具体分析。同一个类的设计，在不同的场景下，对职责是否单一的判定，可能是不同的。

2 ) 开闭原则

开闭原则是保证代码可扩展性的重要指导原则，是对代码扩展性的具体解读。很多设计模式诞生的初衷都是为了提高代码的扩展性，都是以满足开闭原则为设计目的的。

开闭原则是所有设计模式的最核心目标，也是最难实现的目标，但是所有的软件设计模式都应该以开闭原则当作标准，才能使软件更加的稳定和健壮。

3 ) 依赖倒置原则

依赖倒置原则主要用来指导框架层面的设计。高层模块不依赖低层模块，它们共同依赖同一个抽象。

依赖倒置原则其实也是实现开闭原则的重要途径之一，它降低了类之间的耦合，提高了系统的稳定性和可维护性，同时这样的代码一般更易读，且便于传承。

如果是在项目中，可以通过SpringAOP去查询这个接口运行的时间；

如果是一个sql，可以通过explain的指令去查这个sql的执行计划。

如果有数据库终端的话，也可以通过开启mysql的慢日志查询，设置好时间阈值，进行捕获。

补充

来源评论区补充：补充链接

在企业内部对于慢查SQL的优化主要经历以下的几个步骤：

在慢SQL的优化过程中，可以从以下五个角度去进行思考优化：SQL优化、资源占用、业务改造、数据减少、源头替换。

在治理慢查的过程中，SQL语句的使用问题是导致慢SQL的主要因素，因此本文主要从SQL优化角度出发，对慢SQL的常见原因和特征进行分析，介绍慢SQL的优化过程以及一些有效的调优技巧和工具，希望能够提供一些有用的方法和策略，帮助大家更好地应对慢SQL问题，并最终实现提升系统性能和优化用户体验的目标。

SQL优化

SQL语句的优化方式主要是通过选择合适的索引、优化查询语句、避免全表扫描等提高查询效率，减少慢SQL的出现

索引

索引主要用于加快数据的查询速度，有了正确的索引，数据库就可以根据索引的数据结构快速定位到匹配的数据行，从而提高查询效率和响应速度。在慢SQL中由于索引导致的主要有两个方面：索引缺失 与 索引失效

索引缺失

1

select * from t1 where text3 = 'text898'

text3列没有索引的情况下：

text3列增加了索引：

建议

一般在以下场景中需要为相应的列创建索引：

• 字段有唯一性限制
• 经常用于where查询条件的字段
• 经常用于group by 和 order by的字段，可以避免排序

但是并不是需要为每个字段都添加上索引，有一些场景下添加上索引反而会加重DB的负担：

• 不用于查询条件的字段
• 字段中存在大量重复的数据
• 数据量太少
• 频繁更新的字段（考虑）

注意：随着数据的增长和变化，索引的有效性可能会下降。定期评估和优化现有索引是十分必要的。可以通过删除不再使用的索引、调整索引的顺序和选择适当的索引类型等方式来进行索引维护和优化

索引失效

索引失效会导致SQL的执行变为全表扫描或选择错误的索引，在explain中一般是type=ALL或type=index

索引失效原因：

• 索引字段发送隐式转换
  • 数字转换为字符串会发生隐式转换失效
  • 字符串转换为数字是自动转换，不会导致索引失效
  • 通过在explain语句后增加extendedexplain extended sql语句，再执行show warnings查看是否存在隐式转换以及哪个字段存在隐式转换
• 使用 非/不等于（!=、not in）查询时可能会导致索引失效
  • 在满足索引覆盖的情况下可能会走索引
• 在查询条件中对索引使用函数或表达式计算
  • 比如from_unixtime(create_time) = ’2019-12-01’就不能使用到索引：需要先做一次全表扫描，将字段上的所有值使用表达式作用后再进行匹配，从而会导致Mysql放弃走索引。所以语句应该写成create_time = unix_timestamp(’2019-12-01’);
• 没有遵循最左前缀匹配原则，比如联合索引中没有使用到第一列索引、使用左右模糊匹配
• 在where子句中，or一些条件列是索引列，一些不是，会导致索引失效，直接全表扫描
• 索引的可选择性差（数据发布严重倾斜或区分度不高）
  • MYSQL查询优化器可能认为返回的数据量本身就很多，通过索引扫描并不能减少多少开销，此时选择全表扫描的权重会提高很多
  • 一般认为区分度 > 0.1的查询字段可以建立索引（经验性指标，一般要进行实际的测试，比如使用前缀索引时，不断尝试直到选择到合适的前缀长度以及合适的区分度）
• IS NOT NULL 或 IS NULL条件查询也可能导致索引失效
  • 当索引字段不可以为空（null）时
    • is null 不会使用索引，因为条件失效无法查询
    • 只有使用is not null 返回的结果集中只包含索引字段时，才使用索引，因为实现索引覆盖，优化器认为此时成本较小
  • 当索引字段可以为空（null）时
    • 使用 is null 会使用索引，因为NULL值在SQL中被认为是列中最小的值，存储在最左边，所以可以通过索引快速定位
    • 使用 is not null 返回的结果集中只包含索引字段时，才会使用索引，因为实现索引覆盖

总结来说，要让避免索引失效的原则为：遵循最左前缀原则、避免使用函数和表达式、避免隐式转换、尽量实现索引覆盖

建议

• 修改SQL语句
• force index强制使用索引
• ignore index忽略特定索引

SQL语句优化

分页写法（深翻页）

最常见的分页写法就是使用limit，在分页查询时，会在 LIMIT 后面传两个参数，一个是偏移量(offset)，一个是获取的条数(limit)。

实现方式是先查询offset+limit条数据，再将offset条数据丢弃给用户返回剩下的limit条数据。比如limit 10000,10实际上是mysql查找到前10010条数据，之后丢弃前面的10000行后再返回

这样子当偏移量很小时，查询速度很快，但是随着 offset 变大时，查询速度会越来越慢，因为查找的数据越来越多

在limit0,10的情况下执行速度很快，基本可以忽略不计

但是当limit n，n是值越来越大时，就导致查询时间增加了

建议

• 方式一：

1

select * from t1 where id >= 300000 order by id limit 10

避免了扫描前offset条记录

但是每次查询都需要拿到上一页的最大/小id。比如当前在第3页，需要查询第5页的数据就没办法了

• 方式二

结合普通limit与方式一，解决方式二的问题，但是offset要尽量小

1

select * from t1 where id > 300000 order by id limit 10, 10

• 方式三：

1

select * from t1 as a inner join (select id from t1 order by id limit 300000, 10) as b on a.id = b.id order by a.id

由于内部的子查询只扫描了id字段，而不是全表，所以性能会比较强

这种情况下还是扫描聚簇索引树，可能难以理解并且优化效果不是很明显。在order by换成其他字段达到索引覆盖的情况下会比较容易理解

• 方式四：

1

select * from t1 where id > (select id from t1 order by id limit 300000, 1) limit 10

同样是通过子查询扫描字段id，但是性能会略好于方式三，因为它不需要进行表的关联，而是一个简单的比较，在不知道上一页最大id的情况下，是比较推荐的用法

最大最小写法

MySQL提供了max()和min()用于获取最大最小值，但是优化得不是很好

text1没有索引，因此会全表扫描获取最小的id

建议：

由于id是主键我们可以知道第一次找到的记录对应的id就是我们需要的结果，所以可以根据结果的有序性修改SQL语句

1

select id from t1 where text1 = 'dd' limit 1

最大值同理

order by排序问题

MySQL进行排序是一个成本比较高的操作：

• 全字段排序会在sort_buffer中建立临时表进行排序
• 基于rowid排序不仅需要建立临时表，还会涉及回表操作

在需要排序时会在explain的Extra字段中出现Using filesort

1

select * from t1 where v1 < 100 order by v1

建议：

对于索引是本来就是有序的，所以可以给order by字段加上索引

• 如果order by后面的字段是单个索引，需要order by 条件要与where中条件一致，否则order by不会利用索引进行排序
• 如果order by 最后的字段是组合索引的一部分，需要把放在索引组合顺序的最后

group by临时表问题

• 内存占用：group by语句由于可能会建立内部临时表，用于保存和统计中间结果。首先会使用内存临时表，但是内存临时表的大小是有限制的，由参数 tmp_table_size 控制，当超过此限制时会把内存临时表转成磁盘临时表。因此内部临时表的存在会影响内存和磁盘的空间，且需要构造的是一个带唯一索引的表，执行代价都是比较高的。因此需要尽量避免内部临时表的建立
• 额外排序：group by column默认会根据column排序，因此还会触发排序开销问题

建议：

• 让 group by 字段用上表的索引，确认方法是 explain 的Extra结果里有没有 Using temporary 和 Using filesort；通过索引建立，只需要顺序扫描到数据结束，就可以拿到 group by 的结果，不需要临时表，也不需要再额外排序

• 如果对 group by 语句的结果没有排序要求，要在语句后面加 order by null
• 如果 group by 需要统计的数据量不大，尽量只使用内存临时表；可以通过适当调大tmp_table_size 参数，来避免用到磁盘临时表
• 如果数据量实在太大，使用 SQL_BIG_RESULT 这个hint，来告诉优化器直接使用排序算法得到 group by 的结果

join

当关联被驱动表上使用到索引时，会使用 Index Nested-Loop Join （NLJ）算法

当关联被驱动表上没有使用到索引时（即t2的字段a无索引），会使用 Block Nested-Loop Join（BNL）算法

建议：

NLJ算法优化：小表驱动大表，在join的时候如果明确知道哪张表是小表时可以使用straight_join写法固定连接驱动方式

BNL算法优化：

• 给被驱动表的join字段加上索引，把BNL算法转成NLJ算法
• 无法设置索引的情况可以通过设置join_buffer_size参数来控制Join Buffer的大小，以减少分段查询次数

Hash Join算法优化：增加 join_buffer_size值避免生成文件

in & exists

in执行流程：查询子查询的表且内外表有关联时，先执行内层表的子查询，然后将内表和外表做一个笛卡尔积，然后按照条件进行筛选，得到结果集。所以相对内表比较小的时候，in的速度较快

exists执行流程：指定一个子查询，检测行的存在。遍历循环外表，然后看外表中的记录有没有和内表的数据一样的，匹配上就将结果放入结果集中

建议：

遵循小表驱动大表：exists是以外层表为驱动表、IN是先执行内层表的**子查询**。如果子查询得出的结果集记录较少，主查询中的表较大且又有索引时应该用in；反之如果外层的主查询记录较少，子查询中的表大且又有索引时使用exists

not in & not exists

not in使用的是全表扫描没有用到索引；而not exists在子查询依然能用到表上的索引

建议：

使用not exists代替not in

查询记录是否存在

在很多时候开发人员判断某一条件对应的记录是否存在时会采用select count(*)，但是这样子会导致扫描所有符合条件的数据

建议：

改用limit 1，这样子数据库查询到一条符合条件的记录就会返回，不需要再继续查找还有多少条记录

资源占用

• 锁资源等待：在读写很热的表上，通常会发生锁资源争夺，从而导致慢查询的情况
  • 谨慎使用for update
  • 增删改尽量使用到索引
  • 降低并发，避免对同一条数据进行反复修改
• 网络波动：往客户端发送数据时发生网络波动导致的慢查询
• 硬件配置：CPU利用率高，磁盘IO经常满载，导致慢查询

在高并发、高流量下，数据库所在机器的负载load过高也会导致SQL整体执行时间过长，这时可能需要从机器和实例的分配，分布式部署，分库分表，读写分离等角度进行优化

业务改造

• 是不是真的需要全部查出来，还是取其中的top N就能够满足需求了
• 查询条件过多的情况下，能否前端页面提示限制过多的查询条件的使用
• 针对实时导出的数据，涉及到实时查DB导出大量数据时，限制导出数据量 or 走T+1的离线导出是不是也是可以的
• 现在业务上需要做数据搜索，使用了 LIKE “%关键词%” 做全模糊查询，从而导致了慢SQL。是不是可以让业务方妥协下，最右模糊匹配，这样就可以利用上索引了

源头替换

Mysql并不是任何的查询场景都是适合的，如需要支持全模糊搜索时，全模糊的like是无法走到索引的。同时结合数据本身的生命周期，对于热点数据，可以考虑存储到缓存解决。因此针对不适合mysql数据源的情况，我们需要替代新的存储介质

• 有like的全模糊的查询，比如基于文本内容去查订单信息，需要接搜索引擎解决
• 有热点数据的查询，考虑是否要接缓存解决
• 针对复杂条件的海量数据查询，可以考虑切换到OLAP(Online Analytical Processing)，可以考虑接Hybrid DB或ADB通道
• 有些场景Mysql不适用，需要用K-V的数据库，HBASE等列式存储的存储引擎

数据减少

SQL本身的性能已经到达极限了，但是耗时仍然很长，可能由于数据量或索引数据都比较大了。因此需要从数据量级减少的角度去处理

• 使用分库分表。由于单表的数据量过大，例如达到千万级别的数据了，需要使用分库分表技术拆分后减轻单库单表的单点压力
• 定时清理终态数据。针对已经状态为终态的业务单据或明显信息，可以使用idb历史数据清理的方式配置定时自动清理。如针对我们的仓储库存操作明细为完结状态的数据，我们只保留最近1天的数据在db中，其他直接删除，减少db查询压力
• 统计类查询可以单独维护汇总数据表。参考数据仓库中的数据分层设计，基于明细数据，抽出一张指标汇总表，或7天/15天等的视图数据进行预计算。此类汇总表数据量级相比明细表下降很多，从而避免直接根据大量明细查询聚合造成慢sql

实践举例

• SQL语句分析
• 分析sql时间点发现固定db某个示例会导致RT尖峰抖动，发现磁盘也有相应问题。怀疑DB某些库磁盘问题导致，联系DBA确认后进行主备切换解决
• 核销慢sql查询迟迟难以解决。发现库存核销记录每天增量数据达到百万级别，但是核销创建状态记录只有20%~30%左右，因此对完结状态的核销记录idb配置定时清理，由15天缩短到2天，减少db数据量
• 库存sn查询涉及复杂查询，采用切换到OLAP链路，通过数据同步中间件完成从db到HybridDB一键同步，切换数据源后问题解决

参考文章

MySQL中IS NULL、IS NOT NULL、!=是否走索引

创建数据卷映射目录

这里我存放的路径为data/app为例，按需创建data、conf、log目录

1
2
3

mkdir -p /data/app/redis/data
mkdir -p /data/app/redis/conf
mkdir -p /data/app/redis/log

获取配置文件

关于拉取配置文件这里建议访问redisConfig看一下,当前稳定的版本是哪些

截止至此文发布时最新版本为7.2，这里直接拿7.2做演示，在RedisGithub仓库中找到对应版本的redis.conf文件，点击复制

在/data/app/redis/conf/路径下创建redis.conf文件，随后修改文件，直接将复制的内容粘贴进去

1
2
3
4

touch redis.conf
vim redis.conf
或
vi redis.conf

修改配置文件

1
2
3
4
5
6
7

vim redis.conf

# 常见的配置项 这里仅作参考
daemonize yes #是否以守护进程方式运行
port 6379 # Redis服务器监听的端口
bind 127.0.0.1 # 绑定的主机IP地址
requirepass #设置密码

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92

# 通用设置
daemonize no                  # 是否以守护进程方式运行 Redis
pidfile /var/run/redis_6379.pid  # Redis 进程 ID 文件路径
port 6379                     # Redis 监听的端口号
bind 127.0.0.1                # Redis 监听的地址（默认为本地回环地址）
requirepass# 密码配置

# 连接设置
timeout 0                     # Redis 客户端连接超时时间
tcp-keepalive 0               # 是否开启 TCP keepalive
 
# 通信协议设置
tcp-backlog 511               # TCP listen() 函数的等待队列长度
tcp-keepalive 300             # TCP keepalive 时间间隔，单位为秒
unixsocket /var/run/redis/redis.sock  # Unix 套接字文件路径
unixsocketperm 700            # Unix 套接字文件的权限
 
# 通用配置项
loglevel notice               # 日志记录级别
logfile /var/log/redis/redis.log  # 日志文件路径
syslog-enabled no             # 是否将日志输出到系统日志
syslog-ident redis            # 系统日志标识符
syslog-facility local0        # 系统日志设施
databases 16                  # Redis 数据库数量
 
# 快照配置项
save 900 1                    # 触发快照保存的条件（900 秒内至少有一个键被修改）
save 300 10                   # 触发快照保存的条件（300 秒内至少有 10 个键被修改）
save 60 10000                 # 触发快照保存的条件（60 秒内至少有 10000 个键被修改）
stop-writes-on-bgsave-error yes  # 快照保存出错时是否停止写入操作
rdbcompression yes            # 是否开启 RDB 文件压缩
rdbchecksum yes               # 是否开启 RDB 文件校验
dbfilename dump.rdb           # RDB 文件名
 
# AOF 配置项
appendonly no                 # 是否开启 AOF 持久化
appendfilename "appendonly.aof"  # AOF 持久化文件名
appendfsync everysec          # AOF 持久化的同步方式
no-appendfsync-on-rewrite no  # 是否在 AOF 重写时禁止同步
auto-aof-rewrite-percentage 100  # 触发 AOF 重写的条件（AOF 文件大小增长率达到 100%）
auto-aof-rewrite-min-size 64mb  # 触发 AOF 重写的条件（AOF 文件最小大小）
aof-load-truncated yes        # 是否在 AOF 文件被截断时继续加载剩余内容
 
# 主从复制配置项
slave-serve-stale-data yes    # 从节点是否在主节点不可用时仍然向客户端提供服务
slave-read-only yes           # 从节点是否只读
repl-diskless-sync no         # 是否在复制时避免使用磁盘
repl-diskless-sync-delay 5    # 复制时磁盘同步延迟时间，单位为秒
repl-ping-slave-period 10     # 主节点发送 ping 命令的时间间隔，单位为秒
repl-timeout 60               # 主从节点之间的心跳超时时间，单位为秒
repl-disable-tcp-nodelay no   # 是否禁用 TCP_NODELAY 算法
slave-priority 100            # 从节点优先级
 
# Sentinel 配置项
sentinel deny-scripts-reconfig yes  # 是否允许 Sentinel 脚本重新配置 Redis
sentinel monitor mymaster 127.0.0.1 6379 2  # 监控的主节点名称、IP 地址、端口号、quorum
sentinel down-after-milliseconds mymaster 30000  # 主节点失效判定时间，单位为毫秒
sentinel failover-timeout mymaster 180000

# 附加配置项
always-show-logo
# 是否在命令行启动时显示 Redis Logo，默认为 yes。可以将该选项设置为 no，以屏蔽 Redis Logo 的显示。
hz
# 控制 Redis 在每秒钟运行的循环次数。默认为 10，表示每秒钟运行 10 次循环。可以将该选项设置为一个正整数，以控制 Redis 运行的速度
include
# 允许在配置文件中包含其他文件，默认为 ""，表示不包含其他文件。可以将该选项设置为实际文件名，以包含其他文件的配置项。
lua-time-limit
# 控制 Lua 脚本的执行时间限制，默认为 5000 毫秒。可以将该选项设置为一个正整数，以控制 Lua 脚本的最长执行时间。
repl-backlog-size
# 控制 Redis 复制功能的回放缓冲区大小，默认为 1MB。可以将该选项设置为一个正整数，以控制回放缓冲区的大小。
repl-diskless-sync
# 是否在复制时避免使用磁盘，即将数据直接从主节点传输到从节点的内存中，默认为 no。可以将该选项设置为 yes，以避免磁盘的使用。
repl-ping-slave-period
# 控制主节点发送 ping 命令的时间间隔，默认为 10 秒。可以将该选项设置为一个正整数，以控制 ping 命令的发送间隔。
repl-timeout
# 控制主从节点之间的心跳超时时间，默认为 60 秒。可以将该选项设置为一个正整数，以控制心跳超时时间。
appendonly
# 是否开启 AOF 持久化，默认为 no。AOF 持久化可以保证 Redis 在宕机时不会丢失数据，但会增加额外的磁盘写入操作。
appendfilename
# AOF 持久化文件名，默认为 appendonly.aof。可以将该选项设置为实际文件名。
appendfsync
# AOF 持久化的同步方式，默认为 everysec。可以将该选项设置为 always、everysec 或 no，分别表示每个写入命令时同步、每秒同步一次或不同步。
save
# RDB 持久化的触发条件，默认为 save 900 1，表示如果 900 秒内至少有一个键被修改，则执行 RDB 持久化。可以设置多个触发条件，例如 save 300 10 表示如果 300 秒内至少有 10 个键被修改，则执行 RDB 持久化。
rdbcompression
# 是否开启 RDB 文件压缩，默认为 yes。开启压缩可以减少磁盘空间的占用，但会增加 CPU 的负载。
maxmemory-policy
# Redis 内存达到最大限制后的淘汰策略，默认为 noeviction，表示停止写入操作。其他可选策略包括 volatile-lru、volatile-ttl、volatile-random、allkeys-lru、allkeys-random 等。
client-output-buffer-limit
# 控制客户端输出缓冲区的大小，默认为 client-output-buffer-limit normal 0 0 0，表示不限制缓冲区大小。可以将该选项设置为实际缓冲区大小，以避免客户端输出缓冲区溢出。
notify-keyspace-events
# 开启键空间通知功能，默认为 ""，表示关闭键空间通知功能。可以将该选项设置为 KEA、KgE、lsh、E、gxE 等，表示监听不同类型的键空间事件。

启动redis容器

在启动Redis容器前，请确定你的数据卷映射。在下属示例中，数据卷映射的路径为/data/app/redis/xxxx，如果不一样请记得修改。启动容器后，系统将自动从远程仓库拉取相应版本的Redis镜像。请务必确保所拉取的Redis版本与之前复制的配置文件版本一致。

1
2
3
4
5
6
7
8

docker run -p 6379:6379 \
    --name redis \
    -v /data/app/redis/conf/redis.conf:/etc/redis/redis.conf \
    -v /data/app/redis/data:/data \
    -v /data/app/redis/logs:/logs \
    --restart always \
    -d redis:7.2 redis-server /etc/redis/redis.conf \
    --appendonly yes

或不指定配置文件启动，不要/etc/redis/redis.conf：

1
2
3
4
5
6
7
8

docker run -p 6379:6379 \
--name redis \
-v /data/app/redis/conf/redis.conf:/etc/redis/redis.conf \
-v /data/app/redis/data:/data \
-v /data/app/redis/log:/var/log/redis \
--restart always \
-d redis:7.2 redis-server \
--appendonly yes

必须：

• -p 6379:6379 端口映射：前表示主机部分，：后表示容器部分。
• –name myredis 指定该容器名称，查看和进行操作都比较方便。

可选：

• -v 挂载目录，规则与端口映射相同。
• -d redis 表示后台启动redis
• redis-server /etc/redis/redis.conf 以配置文件启动redis，加载容器内的conf文件，最终找到的是挂载的录/data/app/redis/conf/redis.conf
• appendonly yes 开启redis 持久化
• —restart always 表示开机启动
• —network serms-net 网卡

常用命令

• 进入redis容器使用redis-cli命令进行连接

1

docker exec -it redis redis-cli

• 查看启动日志

1
2

docker logs myredis # 后面跟容器名 or 容器ID 都可以
docker logs --since 30m <容器名> # --since 30m 是查看此容器30分钟之内的日志情况。

• Docker 停止、删除、重启、启动容器

正常删除容器，一般是先停止容器，再进行删除

1
2
3
4
5

docker stop [容器名|容器ID] #停止容器
docker start   [容器名|容器ID]  #启动停止的容器
docker restart  [容器名|容器ID]  # 将容器重新启动
docker kill [容器名|容器ID] #强行终止
docker rm [容器名|容器ID]   # 删除停止的容器

常见报错

如果还有其他问题可留言，博主会尽力帮你解决

Redis Client On Error: Error: write ECONNABORTED Config right?

1. 方法一

   bind 0.0.0.0 注释 或者设置为bind 0.0.0.0

   protected-mode 设置为no

   

2. 方法二

   设置密码

   

Docker安装请看这篇: Docker安装部署

安装部署

oracle镜像来自registry.cn-hangzhou.aliyuncs.com/helowin/oracle_11g 账户：root/helowin

拉取镜像

1
2
3

docker pull registry.cn-hangzhou.aliyuncs.com/helowin/oracle_11g
或 
docker pull akaiot/oracle_11g

创建并启动容器

1
2
3
4

# 无数据卷挂载
docker run -d -p 1521:1521 --name oracle11g akaiot/oracle_11g
# 有数据卷挂载
docker run -d --name oracle11g -p 1521:1521 --privileged=true  -v /data/app/oracle/oradata:/serms/oracle/oradata akaiot/oracle_11g

进入oracle11g容器进行配置

1

docker exec -it oracle11g bash

切换到root用户下进行配置

1
2

su root
密码为：helowin

编辑profile文件配置ORACLE环境变量

1

vi /etc/profile

在最下边添加如下内容:

1
2
3

export ORACLE_HOME=/home/oracle/app/oracle/product/11.2.0/dbhome_2
export ORACLE_SID=helowin
export PATH=$ORACLE_HOME/bin:$PATH

让配置立刻生效

1

source /etc/profile

创建软连接

1

ln -s $ORACLE_HOME/bin/sqlplus /usr/bin

切换到oracle 用户

1

su - oracle

登录sqlplus并修改sys、system用户密码并刷新权限

1
2
3
4
5
6
7
8

sqlplus /nolog
conn /as sysdba
# 修改system用户的密码为"root"
alter user system identified by root;
# 修改sys用户的密码为"root"
alter user sys identified by root;
# 修改默认配置文件中密码有效期策略，将密码的有效期设置为永久有效（UNLIMITED）
ALTER PROFILE DEFAULT LIMIT PASSWORD_LIFE_TIME UNLIMITED;

退出：

1

exit;

查看一下oracle实例状态

lsnrctl status

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

[oracle@4b4795fdc52f ~]$ lsnrctl status

LSNRCTL for Linux: Version 11.2.0.1.0 - Production on 18-MAR-2024 11:16:46

Copyright (c) 1991, 2009, Oracle.  All rights reserved.

Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=EXTPROC1521)))
STATUS of the LISTENER
------------------------
Alias                     LISTENER
Version                   TNSLSNR for Linux: Version 11.2.0.1.0 - Production
Start Date                18-MAR-2024 11:04:17
Uptime                    0 days 0 hr. 12 min. 29 sec
Trace Level               off
Security                  ON: Local OS Authentication
SNMP                      OFF
Listener Parameter File   /home/oracle/app/oracle/product/11.2.0/dbhome_2/network/admin/listener.ora
Listener Log File         /home/oracle/app/oracle/diag/tnslsnr/4b4795fdc52f/listener/alert/log.xml
Listening Endpoints Summary...
  (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC1521)))
  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=4b4795fdc52f)(PORT=1521)))
Services Summary...
Service "helowin" has 1 instance(s).
  Instance "helowin", status READY, has 1 handler(s) for this service...
Service "helowinXDB" has 1 instance(s).
  Instance "helowin", status READY, has 1 handler(s) for this service...
The command completed successfully

修改字符集编码为GBK

1
2
3
4
5
6
7
8
9
10
11

connect sys/root as SYSDBA;
SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
ALTER SYSTEM ENABLE RESTRICTED SESSION;
ALTER SYSTEM SET JOB_QUEUE_PROCESSES=0;
ALTER SYSTEM SET AQ_TM_PROCESSES=0;
ALTER DATABASE OPEN;
// 跳过超子集检测
ALTER DATABASE CHARACTER SET INTERNAL_USE ZHS16GBK; 
SHUTDOWN IMMEDIATE;
STARTUP;

集成平台Oracle配置

Oracle的部署至此已经部署完毕,下述为个人项目需要配置的内容,有需要可以做参考:

1
2
3
4

docker exec -it oracle11g bash
su - oracle
#passowrd oracle
sqlplus / as sysdba

设置Process最大进程数

1
2

alter system set processes=800 scope = spfile;
alter system set processes=1600 scope = spfile;

修改账号密码修改期限

1

Alter PROFILE DEFAULT LIMIT PASSWORD_LIFE_TIME UNLIMITED;

设置参数SQLNET.EXPIRE_TIME

1
2
3
4

cd $ORACLE_HOME/network/admin/
vi sqlnet.ora
SQLNET.EXPIRE_TIME=20
# 设置完后需重启服务

设置游标数

1

alter system set open_cursors=2000;

对Oracle Users表空增加dbf文件

1
2
3
4
5
6
7
8
9

alter tablespace USERS  add datafile '/home/oracle/app/oracle/oradata/helowin/USERS02.DBF' size 500M autoextend on next 50M maxsize unlimited ;
alter tablespace USERS  add datafile '/home/oracle/app/oracle/oradata/helowin/USERS03.DBF' size 500M autoextend on next 50M maxsize unlimited ;
alter tablespace USERS  add datafile '/home/oracle/app/oracle/oradata/helowin/USERS04.DBF' size 500M autoextend on next 50M maxsize unlimited ;
alter tablespace USERS  add datafile '/home/oracle/app/oracle/oradata/helowin/USERS05.DBF' size 500M autoextend on next 50M maxsize unlimited ;
alter tablespace USERS  add datafile '/home/oracle/app/oracle/oradata/helowin/USERS06.DBF' size 500M autoextend on next 50M maxsize unlimited ;
alter tablespace USERS  add datafile '/home/oracle/app/oracle/oradata/helowin/USERS07.DBF' size 500M autoextend on next 50M maxsize unlimited ;
alter tablespace USERS  add datafile '/home/oracle/app/oracle/oradata/helowin/USERS08.DBF' size 500M autoextend on next 50M maxsize unlimited ;
alter tablespace USERS  add datafile '/home/oracle/app/oracle/oradata/helowin/USERS09.DBF' size 500M autoextend on next 50M maxsize unlimited ;
alter tablespace USERS  add datafile '/home/oracle/app/oracle/oradata/helowin/USERS10.DBF' size 500M autoextend on next 50M maxsize unlimited ;

链接Docker中Oracle服务,执行如下命令,创建用户并授予权限

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

create user datamanager  identified by data  default tablespace USERS  temporary tablespace TEMP;
create user datacenter  identified by data  default tablespace USERS  temporary tablespace TEMP;

alter system set job_queue_processes=20; 
alter system set aq_tm_processes=10; 
------------------datamanager给dataceneter授权
grant dba to datamanager;
grant connect to datamanager;
grant resource to datamanager;
grant dba to datacenter;
grant connect to datacenter;
grant resource to datacenter;
alter system set job_queue_processes=20;
grant create view to datacenter;
GRANT EXECUTE ON dbms_sql  To datacenter;
GRANT SELECT ON dba_jobs_running TO datacenter;
GRANT SELECT ON dba_jobs to datacenter;
grant execute on dbms_ddl to datacenter;
grant select on dba_users to datacenter;
GRANT EXECUTE ON dbms_sql  To datacenter;
GRANT SELECT ON dba_jobs_running TO datacenter;
GRANT SELECT ON dba_jobs to datacenter;
grant create any table to datacenter;
grant select any table to datacenter;
grant select on DBA_DATA_FILES  to datacenter;
grant alter tablespace to datacenter;
GRANT CREATE MATERIALIZED VIEW TO datacenter;
--------------导入数据后执行--------------
grant select, insert, update, delete, references, alter, index on datamanager.EAPARAM to DATACENTER;
grant select on DATACENTER.v_dept to datamanager with grant option;
grant select on DATACENTER.v_empl to datamanager with grant option;
grant select on datamanager.Eauser to datacenter;
grant select on datamanager.v_eadept to datacenter with grant option;

导入dmp数据文件

1

imp userid=DATACENTER/data file=/serms/oracle/oradata/dmp/1.dmp full=y

导入数据后处理（空表不能导出处理，在datacenter下执行）：

select ‘alter table ‘||table_name||’ allocate extent;’ from user_tables where num_rows=0

把查询结果在PLSQL中执行，以空行数据进行导出处理。

T_TERM_DETAIL

先上效果图

正片开始

下载Jetbrains产品

这里我那Idea来做演示

直接去官网下载最新版,不要犹豫,直接点下载即可, 这里只需要注意你的系统版本即可,Mac的需要对应下载Mac版本的Idea

下载破解包

点我跳转,下载 jetbra.zip文件:

破解安装

先装idea，如果之前已有idea或别的Jetbrains产品请先卸载，卸载这里我推荐使用Geek软件，谁用谁知道，装完之后不要打开

接着解压jetbra.zip，进入到 scripts文件，安装顺执行install-all-users.vbs、install-current-user.vbs两个文件

如果怕idea卸载有残留，可以先执行 uninstall

在刚刚的网站上找到你所需要破解的Jetbrains产品，点击复制密钥

打开Idea，输入密钥即可完成注册

可以看到所注册时间到2026年，其实这个时间是“假的”，而你电脑上现在的idea已经实现理论永久了，时间无需在意

拓展

其他Jetbrains产品也是类似着这样破解，温馨提示：install-all-users.vbs、install-current-user.vbs 文件只需要执行一次，如果电脑需要装多个Jetbrains的产品，那么直接再去网站上复制产品密钥进行激活即可，无需在执行文件

其次，网站上还有很多的插件密钥，大家可以去尝试激活，具体如下

• 将ES中的索引全部删除
• 添加索引： PUT hotel
• 添加几个文档

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53

PUT /hotel
{
  "mappings": {
    "properties": {
      "id":{
        "type": "keyword"
      },
      "name":{
        "type": "keyword",
        "analyzer": "ik_max_word",
        "copy_to": "all"
      },
      "address":{
        "type": "keyword",
        "index": false
      },
      "price":{
        "type": "integer"
      },
      "score":{
        "type": "integer"
      },
      "brand":{
        "type": "keyword",
        "copy_to": "all"
      },
      "city":{
        "type": "keyword"
      },
      "starName":{
        "type": "keyword"
      },
      "business":{
        "type": "keyword",
        "copy_to": "all"
      },
      "location":{
        "type": "geo_point"
      },
      "pic":{
        "type": "keyword",
        "index": false
      },
      "all":{
        "type": "keyword",
        "analyzer": "ik_max_word"
      }
    }
  }
}


GET /hotel/_search

可以注意到Hotel映射结构中：name、brand、business三个字段分别使用了copy_to属性，它允许你将一个或多个字段的原始值复制到另一个指定的字段，优势在于：合并内容、简化查询、分析一致性

高级查询

全文检索查询

• 请求方式：GET 索引名/_search
• 请求体内容

1
2
3
4
5
6
7
8
9
10

# 全文检索查询
# match对用户输入的内容进行分词然后去倒排索引库检索
GET /hotel/_search
{
  "query": {
    "match": {
      "name": "如家"
    }
  }
}

使用合并内容字段all进行查询，查询外滩如家将分词为 外滩、如家，即包含两个其中一个都命中结果

查询所有文档

• 请求方式：GET 索引名/_search
• 请求体内容

1
2
3
4
5
6

GET /hotel/_search
{
  "query": {
    "match_all": {}
  }
}

字段匹配查询:multi_match

查询的字段越多效率越慢

• multi_match 与 match 类似，不同的是它可以在多个字段中查询。
• 请求方式：GET 索引名/_search
• 请求体内容

1
2
3
4
5
6
7
8
9
10

# multi_match 多个字段搜索，参与查询字段越多，查询性能越差copy_to 
GET /hotel/_search
{
  "query": {
    "multi_match": {
      "query": "外滩如家",
      "fields": ["brand","name","business"]
    }
  }
}

单关键字精确查询:term

• term 查询，精确的关键词匹配查询，不对查询条件进行分词，即只能单关键字精确查询。
• 请求方式：GET 索引名/_search
• 请求体内容

1
2
3
4
5
6
7
8
9
10
11
12

#精确查询 一般查找KeyWord、数值、日期、Boolean
# term
GET /hotel/_search
{
  "query": {
    "term": {
      "city": {
        "value": "深圳"
      }
    }
  }
}

多关键字精确查询:terms

• terms 查询和 term 查询一样，但它允许你指定多值进行匹配。如果这个字段包含了指定值中的任何一个值，那么这个文档满足条件，类似于 mysql 的 in
• 请求方式：GET 索引名/_search
• 请求体内容

1
2
3
4
5
6
7
8
9
10
11
12

GET /hotel/_search
{
  "query": {
    "terms": {
      "name": [
        "上海",
        "深圳"
      ]
    }
  }
}

指定字段查询:_source

• 默认情况下，Elasticsearch 在搜索的结果中，会把文档中保存在 _source 的所有字段都返回。
• 如果我们只想获取其中的部分字段，我们可以添加 _source 的过滤
• 请求方式：GET 索引名/_search
• 请求体内容

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

GET /hotel/_search
{
  "_source": [
    "name",
    "price",
    "address"
  ],
  "query": {
    "terms": {
      "name": [
        "上海",
        "深圳"
      ]
    }
  }
}

过滤字段:includes&excludes

• includes：来指定想要显示的字段
• excludes：来指定不想要显示的字段
• 请求方式：GET 索引名/_search
• 请求体内容

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

GET /hotel/_search
{
  "_source": {
    "includes": [
      "name",
      "price"
    ]
  },
  "query": {
    "terms": {
      "name": [
        "上海"
      ]
    }
  }
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

GET /hotel/_search
{
  "_source": {
    "excludes": [
      "name",
      "price"
    ]
  },
  "query": {
    "terms": {
      "name": [
        "上海"
      ]
    }
  }
}

组合查询:bool

• bool 把各种其它查询通过 must（必须，类似 and）、must_not（必须不，类似 not）、should（应该 类似 or）的方式进行组合
• 请求方式：GET 索引名/_search
• 请求体内容

查询名称必须包含如家，价格不能超过400，并且在我位置10km范围内的酒店，且结果按价格高到低排序

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39

GET /hotel/_search
{
  "query": {
    "bool": {
      "must": [
        {
          "match": {
            "name": "如家"
          }
        }
      ],
      "must_not": [
        {
          "range": {
            "price": {
              "gt": 400
            }
          }
        }
      ],
      "filter": [
        {
          "geo_distance": {
            "distance": "10km",
            "location": {
              "lat": 31.21,
              "lon": 121.5
            }
          }
        }
      ]
    }
  },
  "sort": [
    {
      "price": "asc"
    }
  ]
}

范围查询:range

• range 查询找出那些落在指定区间内的数字或者时间。range 查询允许以下字符

查询价格1000-3000的酒店信息

1
2
3
4
5
6
7
8
9
10
11
12

# range 范围查询
GET /hotel/_search
{
  "query": {
    "range": {
      "price": {
        "gte": 1000,
        "lte": 3000
      }
    }
  }
}

模糊查询:fuzzy

fuzzy：返回包含与搜索字词相似的字词的文档，更多fuzzy有关解释请查看官方文档 (opens new window) -编辑距离是将一个术语转换为另一个术语所需的一个字符更改的次数。这些更改可以包括：

更改字符（box → fox）

删除字符（black → lack）

插入字符（sic → sick）

转置两个相邻字符（act → cat）

为了找到相似的术语，fuzzy 查询会在指定的编辑距离内创建一组搜索词的所有可能的变体或扩展。然后查询返回每个扩展的完全匹配。

通过 fuzziness 修改编辑距离。一般使用默认值 AUTO，根据术语的长度生成编辑距离。

请求方式：GET 索引名/_search

1
2
3
4
5
6
7
8
9
10
11

GET /hotel/_search
{
  "query": {
    "fuzzy": {
      "all": {
        "value": "乡"
      }
    }
  }
}

精确查询地理位置:geo_distance

1
2
3
4
5
6
7
8
9
10
11

# 精确查询地理位置
GET /hotel/_search
{
  "query": {
    "geo_distance":{
      "distance":"2km",
      "location":"31.21,121.5"
    }
  }
}

复合查询:function_score

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

# 复合查询
# function score 查询
GET /hotel/_search
{
  "query": {
    "function_score": {
      "query": {
        "match": {
          "all": "外滩"
        }
      },
      "functions": [
        {
          "filter": {
            "term": {
              "brand": "如家"
            }
          },
          "weight": 10
        }
      ],
      "boost_mode": "sum"
    }
  }
}

前缀查询:prefix

• 请求方式：GET 索引名/_search
• 请求体内容

1
2
3
4
5
6
7
8
9
10

GET /hotel/_search
{
  "query": {
    "prefix": {
      "name": {
        "value": "上"
      }
    }
  }
}

注意本教程基于Es7.x版本Api编写

启动Es&Kibana

1
2

docker start es
docker logs -f es

当日志中输出一推的successfully时，基本就启动成功了

1
2

docker start kibana
docker logs -f kibana

出现5601的链接地址时表明启动成功

数据格式

ES在使用时，会涉及到五个核心概念：索引（Index）、映射（Mapping）、域 （Field）、文档（Document）、倒排索引。以一张MySQL中数据表为例。

Elasticsearch 是面向文档型数据库，一条数据在这里就是一个文档。我们可以把 Elasticsearch 里存储文档数据和关系型数据库 MySQL 存储数据的概念进行一个类比。 ES 里的 Index 可以看做一个库，而 Types 相当于表，Documents 则相当于表的行。

这里 Types 的概念已经被逐渐弱化，Elasticsearch 6.X 中，一个 index 下已经只能包含一个type，Elasticsearch 7.X 中, Type 的概念已经被删除了。

索引操作

索引相当于关系型数据库中的一张表，一个index包含若干document，通过Index代表一类类似的或者相同的document。

• 打开 kibana 的 Dev Tools 菜单

创建索引-PUT

• 对比关系型数据库，创建索引就等同于创建数据库
• PUT 索引名

• 发送请求后，服务器返回了这样的响应

1
2
3
4
5

{
  "acknowledged" : true,
  "shards_acknowledged" : true,
  "index" : "test"
}

• 如果重复添加索引呢？重复添加则会返回索引已经存在的错误信息

查看全部索引-GET

GET _cat/indices?v

GET _all

_cat：表示查看的意思；

indices： 表示索引

health：当前服务器健康状态：green(集群完整)、yellow(单点正常、集群不完整)、red(单点不正常)

status：索引打开、关闭状态

index：索引名

uuid：索引统一编号

pri：主分片数量

rep：副本数量

docs.count：可用文档数量

docs.deleted：文档删除状态（逻辑删除）

store.size：主分片和副分片整体占空间大小

pri.store.size：主分片占空间大小

查看单个索引-GET

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

{
  "user"【索引名】: {
    "aliases"【别名】: {},
    "mappings"【映射】: {},
    "settings"【设置】: {
      "index"【设置 - 索引】: {
        "routing"【设置 - 索引路由】: {
          "allocation": {
            "include": {
              "_tier_preference": "data_content"
            }
          }
        },
        "number_of_shards"【设置 - 索引 - 主分片数量】: "1",
        "provided_name"【设置 - 索引 - 名称】: "user",
        "creation_date"【设置 - 索引 - 创建时间】: "1659678930693",
        "number_of_replicas"【设置 - 索引 - 副分片数量】: "1",
        "uuid"【设置 - 索引 - 唯一标识】: "P0pIpPyTSa-zS7kJCeE7Ng",
        "version"【设置 - 索引版本号】: {
          "created": "8030399"
        }
      }
    }
  }
}

查询多个索引

1
2
3

# 查询多个索引信息 GET 索引名称,索引名称
PUT person1
GET person,person1

删除索引-DELETE

数据类型

字符串

• text：会进行分词，如华为手机，会分成：华为，手机。 被分出来的每一个词，称为term（词条）
• keyword：不会进行分词，如华为手机，只有一个词条，即华为手机。

数值

• long：带符号64位整数
• integer：带符号32位整数
• short：带符号16位整数
• byte：带符号8位整数
• double：双精度64位浮点数
• float：单精度32位浮点数
• half_float：半精度16位浮点数

布尔：

• boolean

二进制：

• binary

日期：

• date

范围类型：

• integer_range
• float_range
• long_range
• double_range
• date_range

数组

对象

文档操作

创建文档-POST

先创建好一个索引，接下来我们来创建文档，并添加数据。这里的文档可以类比为关系型数据库中的表数据，添加的数据格式为JSON格式

1
2
3
4
5
6
7
8
9
10
11
12
13

{
  "_index"【索引】: "user",
  "_id"【唯一标识，支持自定义】: "C1yqbIIBJVfoW_YKu2D5",
  "_version"【版本】: 1,
  "result"【结果】: "created",#这里的 create 表示创建成功
  "_shards"【分片】: {
    "total"【分片 - 总数】: 2,
    "successful"【分片 - 成功】: 1,
    "failed"【分片 - 失败】: 0
  },
  "_seq_no": 0,
  "_primary_term": 1
}

• 自定义唯一标识：POST 索引名/_doc/(自定义ID)

查看文档-GET

• 查看文档时，需要指明文档的唯一性标识，类似于 MySQL 中数据的主键查询
• 查看指定文档：GET 索引名/_doc/(唯一标识)
• 查看所有数据：GET 索引名/_search

1
2
3
4
5
6
7
8
9
10
11
12

{
  "_index"【索引】: "user",
  "_id": "C1yqbIIBJVfoW_YKu2D5",
  "_version": 1,
  "_seq_no": 0,
  "_primary_term": 1,
  "found"【查询结果】: true,
  "_source"【文档源信息】: {
    "userName": "A佳技术",
    "age": "28"
  }
}

修改文档-POST

全局修改

POST 索引名/_doc/(唯一标识)

1
2
3
4
5
6
7
8
9
10
11
12
13

{
  "_index": "user",
  "_id": "C1yqbIIBJVfoW_YKu2D5",
  "_version": 2,
  "result"【更新操作】: "updated",
  "_shards": {
    "total": 2,
    "successful": 1,
    "failed": 0
  },
  "_seq_no": 1,
  "_primary_term": 1
}

局部修改

删除文档-DELETE

• 删除一个文档不会立即从磁盘上移除，它只是被标记成已删除（逻辑删除）

• DELETE 索引名/_doc/(唯一标识)

  

1
2
3
4
5
6
7
8
9
10
11
12
13

{
  "_index": "user",
  "_id": "C1yqbIIBJVfoW_YKu2D5",
  "_version"【版本:对数据的操作，都会更新版本】: 5,
  "result"【结果】: "deleted",# deleted 表示数据被标记为删除
  "_shards": {
    "total": 2,
    "successful": 1,
    "failed": 0
  },
  "_seq_no": 4,
  "_primary_term": 1
}

条件删除文档-POST

首先分别增加多条数据，这里我添加了3条数据

POST 索引名/_delete_by_query + 请求体条件

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

{
  "took"【耗时】: 17,
  "timed_out"【是否超时】: false,
  "total"【总数】: 1,
  "deleted"【删除数量】: 1,
  "batches": 1,
  "version_conflicts": 0,
  "noops": 0,
  "retries": {
    "bulk": 0,
    "search": 0
  },
  "throttled_millis": 0,
  "requests_per_second": -1,
  "throttled_until_millis": 0,
  "failures": []
}

查看文档数据情况，年龄20已经删除

映射基本操作

原理

有了索引库，等于有了数据库中的 database。

接下来就需要建索引库(index)中的映射了，类似于数据库(database)中的表结构(table)。创建数据库表需要设置字段名称，类型，长度，约束等；索引库也一样，需要知道这个类型下有哪些字段，每个字段有哪些约束信息，这就叫做映射(mapping)。

先创建索引-PUT

1

PUT hotel

创建映射-PUT

为已经存在的索引库添加映射

PUT 索引名/_mapping + 请求体内容

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

PUT student/_mapping
{
  "properties": {
    "name":{
      "type":"text",
      "index": true
    },
    "sex":{
      "type":"keyword",
      "index":true
    },
    "age":{
      "type":"keyword",
      "index":false
    }
  }
}

创建索引并添加映射

PUT /索引名称
{

​ “mappings”：{

​ “properties”: {}

​ }

}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50

PUT /hotel
{
  "mappings": {
    "properties": {
      "id":{
        "type": "keyword"
      },
      "name":{
        "type": "keyword",
        "analyzer": "ik_max_word",
        "copy_to": "all"
      },
      "address":{
        "type": "keyword",
        "index": false
      },
      "price":{
        "type": "integer"
      },
      "score":{
        "type": "integer"
      },
      "brand":{
        "type": "keyword",
        "copy_to": "all"
      },
      "city":{
        "type": "keyword"
      },
      "starName":{
        "type": "keyword"
      },
      "business":{
        "type": "keyword",
        "copy_to": "all"
      },
      "location":{
        "type": "geo_point"
      },
      "pic":{
        "type": "keyword",
        "index": false
      },
      "all":{
        "type": "keyword",
        "analyzer": "ik_max_word"
      }
    }
  }
}

映射数据说明：

• 字段名：任意填写
• type：类型，Elasticsearch 中支持的数据类型非常丰富，说几个关键的：
  • String类型，又分两种
    • text：可分词，支持模糊查询，支持准确查询，不支持聚合查询
    • keyword：不可分词，数据会作为完整字段进行匹配，支持模糊查询，支持准确查询，支持聚合查询。
  • Numerical：数值类型，分两类
    • 基本数据类型：long、integer、short、byte、double、float、half_float
    • 浮点数的高精度类型：scaled_float
  • Date：日期类型
  • Array：数组类型
  • Object：对象
• index：是否索引，默认为 true，也就是说你不进行任何配置，所有字段都会被索引。
  • true：字段会被索引，则可以用来进行搜索
  • false：字段不会被索引，不能用来搜索
• store：是否将数据进行独立存储，默认为 false。

原始的文本会存储在_source 里面，默认情况下其他提取出来的字段都不是独立存储的，是从_source里面提取出来的。当然你也可以独立的存储某个字段，只要设置 "store": true 即可，获取独立存储的字段要比从 _source 中解析快得多，但是也会占用更多的空间，所以要根据实际业务需求来设置。

• analyzer：分词器，这里的 ik_max_word 即使用 ik 分词器

查看映射-GET

GET /索引/_mapping

添加字段

对于映射，只能进行字段添加，不能对字段进行修改或删除，如有需要，则重新创建映射。

1
2
3
4
5
6
7
8
9
10
11
12
13
14

PUT user/_mapping
{
  "properties":{
    "name": {
        "type": "text"
      },
      "age": {
        "type": "integer"
      },
      "address":{
        "type":"text"
      }
  }
}

The Elastic Stack, 包括 Elasticsearch、Kibana、Beats 和 Logstash（也称为 ELK Stack）。能够安全可靠地获取任何来源、任何格式的数据，然后实时地对数据进行搜索、分析和可视化。Elaticsearch，简称为 ES，ES 是一个开源的高扩展的分布式全文搜索引擎，是整个 Elastic Stack 技术栈的核心。它可以近乎实时的存储、检索数据；本身扩展性很好，可以扩展到上百台服务器，处理 PB 级别的数据。

PS：elasticsearch是一款非常强大的开源搜索引擎，具备非常多强大功能，可以帮助我们从海量数据中快速找到需要的内容

全文搜索引擎

Google，百度类的网站搜索，它们都是根据网页中的关键字生成索引，我们在搜索的时候输入关键字，它们会将该关键字即索引匹配到的所有网页返回；还有常见的项目中应用日志的搜索等等。对于这些非结构化的数据文本，关系型数据库搜索不是能很好的支持。

一般传统数据库，全文检索都实现的很鸡肋，因为一般也没人用数据库存文本字段。进行全文检索需要扫描整个表，如果数据量大的话即使对 SQL 的语法优化，也收效甚微。建立了索引，但是维护起来也很麻烦，对于 insert 和 update 操作都会重新构建索引。

基于以上原因可以分析得出，在一些生产环境中，使用常规的搜索方式，性能是非常差的：

• 搜索的数据对象是大量的非结构化的文本数据。
• 文件记录量达到数十万或数百万个甚至更多。
• 支持大量基于交互式文本的查询。
• 需求非常灵活的全文搜索查询。
• 对高度相关的搜索结果的有特殊需求，但是没有可用的关系数据库可以满足。
• 对不同记录类型、非文本数据操作或安全事务处理的需求相对较少的情况。为了解决结构化数据搜索和非结构化数据搜索性能问题，我们就需要专业，健壮，强大的全文搜索引擎。

这里说到的全文搜索引擎指的是目前广泛应用的主流搜索引擎。它的工作原理是计算机索引程序通过扫描文章中的每一个词，对每一个词建立一个索引，指明该词在文章中出现的次数和位置，当用户查询时，检索程序就根据事先建立的索引进行查找，并将查找的结果反馈给用户的检索方式。这个过程类似于通过字典中的检索字表查字的过程。

elasticsearch和lucene

elasticsearch底层是基于lucene来实现的。

Lucene是一个Java语言的搜索引擎类库，是Apache公司的顶级项目，由DougCutting于1999年研发。官网地址：https://lucene.apache.org/ 。

elasticsearch的发展历史：

• 2004年Shay Banon基于Lucene开发了Compass
• 2010年Shay Banon 重写了Compass，取名为Elasticsearch。

Elasticsearch And Solr

Lucene 是 Apache 软件基金会 Jakarta 项目组的一个子项目，提供了一个简单却强大的应用程式接口，能够做全文索引和搜寻。在 Java 开发环境里 Lucene 是一个成熟的免费开源工具。就其本身而言，Lucene 是当前以及最近几年最受欢迎的免费 Java 信息检索程序库。但 Lucene 只是一个提供全文搜索功能类库的核心工具包，而真正使用它还需要一个完善的服务框架搭建起来进行应用。

目前市面上流行的搜索引擎软件，主流的就两款：Elasticsearch 和 Solr,这两款都是基于 Lucene 搭建的，可以独立部署启动的搜索引擎服务软件。由于内核相同，所以两者除了服务器安装、部署、管理、集群以外，对于数据的操作 修改、添加、保存、查询等等都十分类似。

在使用过程中，一般都会将 Elasticsearch 和 Solr 这两个软件对比，然后进行选型。这两个搜索引擎都是流行的，先进的的开源搜索引擎。它们都是围绕核心底层搜索库 - Lucene构建的 - 但它们又是不同的。像所有东西一样，每个都有其优点和缺点：

Elasticsearch Or Solr

Elasticsearch 和 Solr 都是开源搜索引擎，那么我们在使用时该如何选择呢？

• Google 搜索趋势结果表明，与 Solr 相比，Elasticsearch 具有很大的吸引力，但这并不意味着 Apache Solr 已经死亡。虽然有些人可能不这么认为，但 Solr 仍然是最受欢迎的搜索引擎之一，拥有强大的社区和开源支持。
• 与 Solr 相比，Elasticsearch 易于安装且非常轻巧。此外，你可以在几分钟内安装并运行Elasticsearch。但是，如果 Elasticsearch 管理不当，这种易于部署和使用可能会成为一个问题。基于 JSON 的配置很简单，但如果要为文件中的每个配置指定注释，那么它不适合您。总的来说，如果你的应用使用的是 JSON，那么 Elasticsearch 是一个更好的选择。否则，请使用 Solr，因为它的 schema.xml 和 solrconfig.xml 都有很好的文档记录。
• Solr 拥有更大，更成熟的用户，开发者和贡献者社区。ES 虽拥有的规模较小但活跃的 用户社区以及不断增长的贡献者社区。
• Solr 贡献者和提交者来自许多不同的组织，而 Elasticsearch 提交者来自单个公司。
• Solr 更成熟，但 ES 增长迅速，更稳定。
• Solr 是一个非常有据可查的产品，具有清晰的示例和 API 用例场景。 Elasticsearch 的文档组织良好，但它缺乏好的示例和清晰的配置说明。

ELK技术栈

elasticsearch结合kibana、Logstash、Beats，也就是elastic stack（ELK）。被广泛应用在日志数据分析、实时监控等领域：

而elasticsearch是elastic stack的核心，负责存储、搜索、分析数据。

为什么不是其他搜索技术？

目前比较知名的搜索引擎技术排名：

虽然在早期，Apache Solr是最主要的搜索引擎技术，但随着发展elasticsearch已经渐渐超越了Solr，独占鳌头：

Windows上安装ES

下载软件

ElasticSearch官方地址

ElasticSearch目前最新版本下载地址

安装软件

Windows 版的 Elasticsearch 的安装很简单，解压即安装完毕，这里我下载的目前最新版8.12.0，解压后的 Elasticsearch 的目录结构如下

解压后，我们先来修改一些配置：

• 配置启动内存，修改配置文件 config/jvm.options

  1 2 3 4 5 6 7

  ################################################################ ## IMPORTANT: JVM heap size ################################################################ ## 配置启动内存，默认是4G -Xms1g -Xmx1g ################################################################

• 暂时禁止掉再次启动时更新地图的一些数据库操作，修改 config/elasticsearch.yml 配置

  1 2	# 添加配置：暂时禁止掉再次启动时更新地图的一些数据库操作 ingest.geoip.downloader.enabled: false

• 进入 bin 文件目录，点击 elasticsearch.bat 文件启动服务 启动完成后，打开浏览器，输入：http://localhost:9200/

  

  

Windows上安装Kibana

Kibana 是一个免费且开放的用户界面，能够让你对 Elasticsearch 数据进行可视化，并 让你在 Elastic Stack 中进行导航。你可以进行各种操作，从跟踪查询负载，到理解请求如 何流经你的整个应用，都能轻松完成。

下载时尽量下载与 ElasicSearch 一致的版本。

前往官网下载 Windows 版本

下载后进行解压，目录如图：

启动kibana

• 启动 Kibana 之前要启动 Elasticsearch
• 进入 bin 目录，双击 kibana.bat 启动服务
• 启动成功后，复制控制台的地址进行访问http://localhost:5601

• 8.x版本访问时，需要先生成一个token，我们在 ES 的 bin 目录下执行以下命令生成 token

1
2
3
4

es\bin>elasticsearch-create-enrollment-token.bat --scope kibana
warning: ignoring JAVA_HOME=G:\java\java8\jdk; using bundled JDK
eyJ2ZXIiOiI4LjMuMyIsImFkciI6WyIxNzIuMjAuMTAuNDo5MjAwIl0sImZnciI6ImUzOWZlYzRmM2MyMDg2ZTEyOGIxOTU3OTAyOTVlZTc5OTlkZmI1MDlmMzM5NjNiZWE2Y2Q1ZTRjMWVhOTdlNmMiLCJrZXkiOiJfbHdsYklJQkpWZm9XX1lLNlY5NTo2czNnMFJZYVRfYXNCX19BZVZ6MDVnIn0=

• 将 token 复制到 kibana登录页中

  

修改界面语言

访问界面是英文，可修改成中文，进入根目录下的 config 目录，打开 kibana.yml 文件，在最末尾处加入以下配置，添加完成后，重新启动即可

1
2
3
4
5
6
7
8

# 默认端口
# server.port: 5601
# ES 服务器的地址，经过上一步的操作，这些会自动生成，所以不需要改动
# elasticsearch.hosts: ["https://127.0.0.1:9200"]
# 索引名：可改可不改
# kibana.index: ".kibana"
# 支持中文
i18n.locale: "zh-CN"

Docker安装Es

需提前装好Centos系统及Docker

• 因为我们还需要部署kibana容器，因此需要让es和kibana容器互联。这里先创建一个网络：

1

docker network create es-net

• 调整机器的vm.max_map_count参数至262144,调整前可以将原文件备份

1
2
3
4
5
6
7
8

// 备份文件
cp /etc/sysctl.conf /etc/sysctl.conf.bak
// 编辑文件
vim /etc/sysctl.conf
// 在文件的尾部添加以下参数
vm.max_map_count=262144
// 使修改后的文件生效
sysctl -p

• 修改虚拟内存区域大小，否则会因为过小而无法启动:

1

sysctl -w vm.max_map_count=262144

• 使用docker命令启动

1
2
3
4
5
6
7
8
9
10
11
12

docker run -d \
  --name elasticsearch \
  -e "cluster.name=elasticsearch" \
  -e "discovery.type=single-node" \
  -e "ES_JAVA_OPTS=-Xms512m -Xmx1024m" \
  -v /mydata/elasticsearch/plugins:/usr/share/elasticsearch/plugins \
  -v /mydata/elasticsearch/data:/usr/share/elasticsearch/data \
  --network es-net\ \
  --privileged \
  -p 9200:9200 \
  -p 9300:9300 \
  elasticsearch:7.17.3

• 启动时会发现/usr/share/elasticsearch/data目录没有访问权限，只需要修改/mydata/elasticsearch/data目录的权限，再重新启动。

1

chmod 777 /mydata/elasticsearch/data/

部署Kiban

1
2
3
4
5
6
7

docker run -d \
  --name kibana \
  --link elasticsearch:es \
  -e ELASTICSEARCH_HOSTS=http://es:9200 \
  --network cscz-net \
  -p 5601:5601 \
  kibana:7.17.3

查看日志

1

docker logs -f kibana

• 开启防火墙：

1

firewall-cmd --zone=public --add-port=5601/tcp --permanent firewall-cmd --reload

安装分词器

前述

为了能够更好地对中文进行搜索和查询，就需要在Elasticsearch中集成好的分词器插件， 而 IK 分词器就是用于对中文提供支持得插件。

集成IK分词器

下载

• IK分词器下载 (opens new window)
• 注意版本需要对应，目前IK分词器还没有8.3.3版本，所以就先重新下一个8.2.3版本的ES

安装

• 将下载的IK压缩包直接解压到 elasticsearch-8.2.3 的 plugins目录下，重启ES

使用 IK 分词器

IK 分词器提供了两个分词算法：

▶️ ik_smart: 会做最粗粒度的拆分，适合 Phrase 查询

▶️ Ik_max_word:会将文本做最细粒度的拆分,会穷尽各种可能的组合,适合 Term Query

• 为索引指定默认IK分词器

这样我们在索引中就不用创建每一个字段，可以通过动态字段映射，将String类型的字段映射为text类型，同时分词器指定为ik_max_word

1
2
3
4
5
6
7
8
9
10
11
12

PUT ik_index
{
  "settings": {
    "analysis": {
      "analyzer": {
        "default": {
          "type": "ik_max_word"
        }
      }
    }
  }
}

自定义分词效果

• 我们在使用 IK 分词器时会发现其实有时候分词的效果也并不是我们所期待的,有时一些特 殊得术语会被拆开，但实际上我们希望不要拆开。
• IK 插件给我们提供了自定义分词字典，我们可以添加自己想要保留得字了。

自定义分词

• 首先在 elasticsearch-analysis-ik-8.2.3的config目录下新建一个my_self.dic文件，输入自己希望不想被拆开的术语，比如分词词语
• 接下来我们修改配置文件：config/IKAnalyzer.cfg.xml

1
2
3
4
5
6
7
8
9
10
11
12
13

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE properties SYSTEM "http://java.sun.com/dtd/properties.dtd">
<properties>
<comment>IK Analyzer 扩展配置</comment>
<!--用户可以在这里配置自己的扩展字典多个文件用';'分隔开 -->
<entry key="ext_dict">my_self.dic</entry>
 <!--用户可以在这里配置自己的扩展停止词字典-->
<entry key="ext_stopwords"></entry>
<!--用户可以在这里配置远程扩展字典 -->
<!-- <entry key="remote_ext_dict">words_location</entry> -->
<!--用户可以在这里配置远程扩展停止词字典-->
<!-- <entry key="remote_ext_stopwords">words_location</entry> -->
</properties>

热更新 IK 分词使用方法

1
2
3
4

<!--用户可以在这里配置远程扩展字典 -->
<entry key="remote_ext_dict">location</entry>
<!--用户可以在这里配置远程扩展停止词字典-->
<entry key="remote_ext_stopwords">location</entry>

其中 location 是指一个 url，比如 http://yoursite.com/getCustomDict，该请求只需满足以下两点即可完成分词热更新。

• 1、该 http 请求需要返回两个头部(header)，一个是 Last-Modified，一个是 ETag，这两者都是字符串类型，只要有一个发生变化，该插件就会去抓取新的分词进而更新词库。
• 2、该 http 请求返回的内容格式是一行一个分词，换行符用 \n即可。

满足上面两点要求就可以实现热更新分词了，不需要重启 ES 实例。

可以将需自动更新的热词放在一个 UTF-8 编码的 .txt 文件里，放在 nginx 或其他简易 http server 下，当 .txt 文件修改时，http server 会在客户端请求该文件时自动返回相应的 Last-Modified 和 ETag。可以另外做一个工具来从业务系统提取相关词汇，并更新这个 .txt 文件。