不使用索引的情况

1. 如果 mysql 估计使用索引比全表扫描更慢，则不使用索引。
   例如：如果 key_part 1 均匀分布在 1 和 100 之间，下列查询中使用索引就不是很好：

1

SELECT * FROM table_name where key_part1 > 1 and key_part1 < 90;

2. 如果使用 heap 表并且 where 条件中不用＝索引列，其他 > 、 < 、 >= 、 <= 均不使 用索引（MyISAM 和 innodb 表使用索引）；

3. 使用 or 分割的条件，如果 or 前的条件中的列有索引，后面的列中没有索引，那么涉及到的索引都不会使用。

4. 如果创建复合索引，如果条件中使用的列不是索引列的第一部分；（不是前缀索引）

5. 如果 like 是以％开始；

6. 对 where 后边条件为字符串的一定要加引号，字符串如果为数字 mysql 会自动转 为字符串，但是不使用索引。

查看索引使用情况

如果索引正在工作， Handler_read_key 的值将很高，这个值代表了一个行被索引值读的次数，很低的值表明增加索引得到的性能改善不高，因为索引并不经常使 用。

Handler_read_rnd_next 的值高则意味着查询运行低效，并且应该建立索引补救。这个值的含义是在数据文件中读下一行的请求数。如果你正进行大量的表扫描，

该值较高。通常说明表索引不正确或写入的查询没有利用索引。

语法：

1

show status like 'Handler_read%';

索引的作用

索引的出现其实就是为了提高数据查询的效率，用于快速找出在某个列中有一特定值的行。

一、什么是平均负载

平均负载（Load Average）是指一段时间内，系统处于可运行状态和不可中断状态的平均进程数，这个一段时间一般取 1 分钟、5 分钟、15 分钟。

CPU 使用率是单位时间内 CPU 繁忙情况的统计，跟平均负载并不完全对应，平均负载不仅包括正在使用 CPU 的进程，还包括等待 CPU 和等待 I/O的进程，比如：

• CPU 密集型进程，使用大量 CPU 回导致平均负载升高
• I/O 密集型进程，等待 I/O 也会使平均负载升高，但 CPU 使用率不一定高
• 大量等待 CPU 的进程调度也会导致平均负载升高，此时 CPU 使用率也会比较高

超文本传输安全协议（英语：Hypertext Transfer Protocol Secure，缩写：HTTPS，常称为 HTTP over TLS，HTTP over SSL 或 HTTP Secure）是一种通过计算机网络进行安全通信的传输协议。

HTTPS 经由 HTTP 进行通信，但利用 SSL/TLS 协议来加密数据包。

TLS 协议位于传输层之上，应用层之下，使用了两种加密技术，分别为：对称加密和非对称加密。使用非对称密钥加密用于传输对称密钥来保证传输过程的安全性，之后使用对称密钥加密进行通信来保证通信过程的效率。

在 MongoDB 查询过程中，索引(Index) 起到非常重要的作用，如果没有索引，MongoDB将会执行全表扫描 。当然如果数据量比较少全表扫描的开销并不大，但如果集合文档数量到百万、千万甚至上亿的时候，一个查询耗费数十秒甚至几分钟都有可能,代价非常高昂。

从网上收集的一些评估网络性能的指标。

带宽

带宽，表示链路的最大传输速率，单位是 b/s（比特 / 秒）。在你为服务器选购网卡时，带宽就是最核心的参考指标。常用的带宽有 1000M、10G、40G、100G 等。

吞吐量

吞吐量，表示没有丢包时的最大数据传输速率，单位通常为 b/s （比特 / 秒）或者 B/s（字节 / 秒）。吞吐量受带宽的限制，吞吐量 / 带宽也就是该网络链路的使用率。

延时

延时，表示从网络请求发出后，一直到收到远端响应，所需要的时间延迟。这个指标在不同场景中可能会有不同的含义。它可以表示建立连接需要的时间（比如 TCP 握手延时），或者一个数据包往返所需时间（比如 RTT）。

PPS

PPS，是 Packet Per Second（包 / 秒）的缩写，表示以网络包为单位的传输速率。PPS 通常用来评估网络的转发能力，而基于 Linux 服务器的转发，很容易受到网络包大小的影响（交换机通常不会受到太大影响，即交换机可以线性转发）。

网络可用性

网络可供用户使用的时间百分比。即网络稳定不出故障的时间 / 用户总的使用时间

并发连接数

是客户端向服务器发起请求，并建立了 TCP 连接，每秒钟服务器链接的总 TCP 数量

丢包率

测试中所丢失数据包数量占所发送数据组的比率。

重传率

重新发送信息的与全部的调用信息之间的比值。

响应时间(RT)

响应时间是指系统对请求作出响应的时间。

吞吐量(Throughput)

吞吐量是指系统在单位时间内处理请求的数量。

什么是 CPU 使用率

CPU 使用率就是除了空闲时间外的其他时间占总 CPU 时间的百分比

事实上，为了计算 CPU 使用率，性能工具一般都会取间隔一段时间（比如 3 秒）的两次值，作差后，再计算出这段时间内的平均 CPU 使用率，即

需要注意的是，**>性能分析工具给出的都是间隔一段时间的平均 CPU 使用率，所以要注意间隔时间的设置**，特别是用多个工具对比分析时，你一定要保证它们用的是相同的间隔时间。

怎么查看 CPU 使用率

• top 显示了系统总体的 CPU 和内存使用情况，以及各个进程的资源使用情况。
  • 系统的 CPU 使用率(%Cpu)
• pidstat 专门分析每个进程 CPU 使用情况的工具
  • 用户态 CPU 使用率 （%usr）；
  • 内核态 CPU 使用率（%system）；
  • 运行虚拟机 CPU 使用率（%guest）；
  • 等待 CPU 使用率（%wait）；
  • 以及总的 CPU 使用率（%CPU）。
• perf 分析 CPU 性能问题
• pstree 用树状形式显示所有进程之间的关系,可以用来查找一个进程的父进程
• execsnoop 专为短时进程设计的工具

CPU 使用率过高怎么办？

• CPU 使用率是最直观和最常用的系统性能指标，更是我们在排查性能问题时，通常会关注的第一个指标。所以我们更要熟悉它的含义，尤其要弄清楚用户（%user）、Nice（%nice）、系统（%system） 、等待 I/O（%iowait） 、中断（%irq）以及软中断（%softirq）这几种不同 CPU 的使用率。比如说：

  • 用户 CPU 和 Nice CPU 高，说明用户态进程占用了较多的 CPU，所以应该着重排查进程的性能问题。
  • 系统 CPU 高，说明内核态占用了较多的 CPU，所以应该着重排查内核线程或者系统调用的性能问题。
  • I/O 等待 CPU 高，说明等待 I/O 的时间比较长，所以应该着重排查系统存储是不是出现了 I/O 问题。
  • 软中断和硬中断高，说明软中断或硬中断的处理程序占用了较多的 CPU，所以应该着重排查内核中的中断服务程序。

• 碰到 CPU 使用率升高的问题，你可以借助 top、pidstat 等工具，确认引发 CPU 性能问题的来源；再使用 perf 等工具，排查出引起性能问题的具体函数。

• 碰到常规问题无法解释的 CPU 使用率情况时，首先要想到有可能是短时应用导致的问题，比如有可能是下面这两种情况。

  • 应用里直接调用了其他二进制程序，这些程序通常运行时间比较短，通过 top 等工具也不容易发现
  • 应用本身在不停地崩溃重启，而启动过程的资源初始化，很可能会占用相当多的 CPU

什么是 CPU 上下文切换

CPU 寄存器，是 CPU 内置的容量小、但速度极快的内存。程序计数器，则是用来存储 CPU 正在执行的指令位置、或者即将执行的下一条指令位置。它们都是 CPU 在运行任何任务前，必须的依赖环境，因此也被叫做CPU 上下文。

CPU 上下文切换，就是先把前一个任务的 CPU 上下文（也就是 CPU 寄存器和程序计数器）保存起来，然后加载新任务的上下文到这些寄存器和程序计数器，最后再跳转到程序计数器所指的新位置，运行新任务。

进程上下文切换

Linux 按照特权等级，把进程的运行空间分为内核空间和用户空间。

• 内核空间（Ring 0）具有最高权限，可以直接访问所有资源。
• 用户空间（Ring 3）只能访问受限资源，不能直接访问内存等硬件设备，必须通过系统调用陷入到内核中，才能访问这些特权资源。
• 系统调用(特权模式切换):一个进程用户态与内核态的互相转变
• 上下文切换:从一个进程切换到另一个进程运行
  • 虚拟内存、栈、全局变量等用户空间的资源
  • 内核堆栈、寄存器等内核空间的状态

一次系统调用的过程，发生了两次 CPU 上下文切换。

什么时候会发生？

• 进程 CPU 时间片耗尽，被系统挂起，切换到其他正在等待 CPU 的进程
• 系统资源不足时进程被系统挂起，系统调度其他进程运行
• 进程通过睡眠函数 sleep 这样的方法将自己主动挂起
• 有优先级更高的进程运行，当前程序会被挂起
• 发生硬件中断，转而执行内核中的终端服务程序

线程上下文切换

线程与进程的区别

• 线程是调度的基本单位，而进程是资源拥有的基本单位
• 当进程只有一个线程时，可以认为进程就等于线程
• 当进程拥有多个线程时，这些线程会共享相同的虚拟内存和全局变量等资源，在上下文切换时，这些资源不需要修改
• 线程有自己的私有数据，例如栈和寄存器等，在上下文切换时需要保存

什么时候会发生

• 前后两个线程属于不同进程。此时因为资源不共享，因此等同于进程上下文切换
• 前后两个线程属于同一个进程，因为虚拟内存共享，所以只需要切换私有数据、寄存器等不共享的数据

虽然同为上下文切换，但同进程内的线程切换，要比多进程间的切换消耗更少的资源，而这，也正是多线程代替多进程的一个优势。

中断上下文切换

• 中断处理会打断进程的正常调度和执行
• 对同一个 CPU 来说，中断处理比进程拥有更高的优先级

怎么查看系统的上下文切换情况

vmstat

vmstat 是一个常用的系统性能分析工具，主要用来分析系统的内存使用情况，也常用来分析 CPU 上下文切换和中断的次数。

• 需要特别关注的四列内容：
  • cs(context switch) 表示每秒上下文切换的次数
  • in(interrupt)表示每秒中断次数
  • r(Running or Runnable)表示就绪队列的长度，也就是正在运行和等待 CPU 的进程数
  • b(Blocked)表示处于不可中断睡眠状态的进程数 #每隔 5 秒输出一组数据

pidstat

vmstat 只给出了系统总体的上下文切换情况，要想查看每个进程的详细情况，就需要使用 pidstat 了。给它加上 -w 选项，你就可以查看每个进程上下文切换的情况了。

• 需要特别关注的两列内容
  • cswch 表示每秒自愿上下文切换的次数
  • nvcswch 表示每秒非自愿上下文切换的次数

• 自愿上下文切换：进程无法获取所需资源
• 非自愿上下文切换：进程由于时间片已到等原因，被系统强制调度

• 自愿上下文切换变多了，说明进程都在等待资源，有可能发生了 IO 等其他问题
• 非自愿上下文切换变多了，说明进程都在被强制调度，即在争抢 CPU，说明 CPU 成为瓶颈
• 中断次数变多了，说明 CPU 被中断处理程序占用，还需要通过查看/proc/interrupts 文件来分析具体的中断类型

小结：

不管是哪种场景导致的上下文切换，我们应该知道：

• CPU 上下文切换，是保证 Linux 系统正常工作的核心功能之一，一般情况下不需要我们特别关注。
• 但过多的上下文切换，会把 CPU 时间消耗在寄存器、内核栈以及虚拟内存等数据的保存和恢复上，从而缩短进程真正运行的时间，导致系统的整体性能大幅下降。

碰到上下文切换次数过多的问题时，我们可以借助 vmstat 、 pidstat 和 /proc/interrupts 等工具，来辅助排查性能问题的根源。

网上收集的常见HTTP 状态码。

Json web token (JWT), 是为了在网络应用环境间传递声明而执行的一种基于 JSON 的开放标准（(RFC 7519).该 token 被设计为紧凑且安全的，特别适用于分布式站点的单点登录（SSO）场景。JWT 的声明一般被用来在身份提供者和服务提供者间传递被认证的用户身份信息，以便于从资源服务器获取资源，也可以增加一些额外的其它业务逻辑所必须的声明信息，该 token 也可直接被用于认证，也可被加密。