IT评测·应用市场-qidao123.com

标题: 记载些Spring+题集（12） [打印本页]
作者: 兜兜零元    时间: 2024-7-22 01:15
标题: 记载些Spring+题集（12）
11种API性能优化方法

一、索引优化

接口性能优化时，大家第一个想到的通常是：优化索引，优化索引的本钱是最小的。
你可以通过查看线上日志或监控陈诉，发现某个接口使用的某条SQL语句耗时较长。
   这条SQL语句是否已经加了索引？
加的索引是否收效了？
MySQL是否选择了错误的索引？
  1.1 没加索引

在SQL语句中，忘记为WHERE条件的关键字段或ORDER BY后的排序字段加索引是项目中常见的题目。在项目初期，由于表中的数据量较小，加不加索引对SQL查询性能影响不大。然而，随着业务的发展，表中的数据量不断增加，这时就必须加索引了。
可以通过以下下令查看/添加索引：
  1. show index from `table_name`
  2. CREATE INDEX index_name ON table_name (column_name);
复制代码
这种方式能够明显进步查询性能，尤其是在数据量庞大的环境下。
1.2 索引充公效

通过上述下令我们已经确认索引是存在的，但它是否收效呢？
   那么，如何查看索引是否收效呢？
  可以使用 EXPLAIN 下令，查看 MySQL 的执行筹划，它会表现索引的使用环境。
  1. EXPLAIN SELECT * FROM `order` WHERE code='002';
复制代码
效果：

这个下令将表现查询的执行筹划，包罗使用了哪些索引。如果索引收效，你会在输出效果中看到相干的信息。通过这几列可以判断索引使用环境，执行筹划包含列的寄义如下图所示：

说真话，SQL语句没有使用索引，除去没有建索引的环境外，最大的大概性是索引失效了。
以下是索引失效的常见缘故原由：

相识这些缘故原由，可以帮助你在查询优化时制止索引失效的题目，确保数据库查询性能保持最佳。
1.3 选错索引

此外，你是否遇到过这样一种环境：明显是同一条SQL语句，只是入参不同。有时候使用的是索引A，有时候却使用索引B？
   没错，有时候MySQL会选错索引。
  须要时可以使用 FORCE INDEX 来欺压查询SQL使用某个索引。
比方：
  1. SELECT * FROM `order` FORCE INDEX (index_name) WHERE code='002';
复制代码
至于为什么MySQL会选错索引，缘故原由大概有以下几点：

相识这些缘故原由，可以帮助你更好地理解和控制MySQL的索引选择行为，确保查询性能的稳固性。
二、SQL优化

如果优化了索引之后效果不明显，接下来可以实验优化一下SQL语句，由于相对于修改Java代码来说，改造SQL语句的本钱要小得多。以下是SQL优化的15个小技巧：

三、远程调用

多时候，我们需要在一个接口中调用其他服务的接口。
在用户信息查询接口中需要返回以下信息：用户名称、性别、等级、头像、积分和发展值。此中，用户名称、性别、等级和头像存储在用户服务中，积分存储在积分服务中，发展值存储在发展值服务中。为了将这些数据同一返回，我们需要提供一个额外的对外接口服务。因此，用户信息查询接口需要调用用户查询接口、积分查询接口和发展值查询接口，然后将数据汇总并同一返回。
调用过程如下图所示：

调用远程接口总耗时 530ms = 200ms + 150ms + 180ms
显然这种串行调用远程接口性能黑白常不好的，调用远程接口总的耗时为所有的远程接口耗时之和。
   那么如何优化远程接口性能呢？
  3.1 串行改并行

上面说到，既然串行调用多个远程接口性能很差，为什么不改成并行呢？调用远程接口的总耗时为200ms，这即是耗时最长的那次远程接口调用时间。
在Java 8之前，可以通过实现Callable接口来获取线程的返回效果。在Java 8之后，可以通过CompletableFuture类来实现这一功能。
以下是一个使用CompletableFuture的示例：
  1. public class RemoteServiceExample {
  2.     public static void main(String[] args) throws ExecutionException, InterruptedException {
  3.         // 调用用户服务接口
  4.         CompletableFuture<String> userFuture = CompletableFuture.supplyAsync(() -> {
  5.             // 模拟远程调用
  6.             simulateDelay(200);
  7.             return "User Info";
  8.         });
  9.         // 调用积分服务接口
  10.         CompletableFuture<String> pointsFuture = CompletableFuture.supplyAsync(() -> {
  11.             // 模拟远程调用
  12.             simulateDelay(150);
  13.             return "Points Info";
  14.         });
  15.         // 调用成长值服务接口
  16.         CompletableFuture<String> growthFuture = CompletableFuture.supplyAsync(() -> {
  17.             // 模拟远程调用
  18.             simulateDelay(100);
  19.             return "Growth Info";
  20.         });
  21.         // 汇总结果
  22.         CompletableFuture<Void> allOf = CompletableFuture.allOf(userFuture, pointsFuture, growthFuture);
  23.         // 等待所有异步操作完成
  24.         allOf.join();
  25.         // 获取结果
  26.         String userInfo = userFuture.get();
  27.         String pointsInfo = pointsFuture.get();
  28.         String growthInfo = growthFuture.get();
  29.     }
  30. }
复制代码
3.2 数据异构

为了提升接口性能，尤其在高并发场景下，可以考虑数据冗余，将用户信息、积分和发展值的数据同一存储在一个地方，比如Redis。
这样，通过用户ID可以直接从Redis中查询所需的数据，从而制止远程接口调用

但需要注意的是，如果使用了数据异构方案，就大概会出现数据一致性题目。用户信息、积分和发展值有更新的话，大部门环境下，会先更新到数据库，然后同步到redis。但这种跨库的操纵，大概会导致双方数据不一致的环境产生。
   那如何解决数据一致性题目呢？
  《亿级电商流量，高并发下Redis与MySQL的数据一致性如何保证》
四、重复调用

在我们的一样平常工作代码中，重复调用非常常见，但如果没有控制好，会严重影响接口的性能。
4.1 循环查数据库 有时候，我们需要从指定的用户聚会合查询出哪些用户已经存在于数据库中。
  1. public List<User> findExistingUsers(List<String> userIds) {
  2.     List<User> existingUsers = new ArrayList<>();
  3.     for (String userId : userIds) {
  4.         User user = userRepository.findById(userId);
  5.         if (user != null) {
  6.             existingUsers.add(user);
  7.         }
  8.     }
  9.     return existingUsers;
  10. }
复制代码
上述代码会对每个用户ID执行一次数据库查询，这在用户聚集较大时会导致性能题目。
   那么，我们如何优化呢？
  我们可以通过批量查询来优化性能，镌汰数据库的查询次数。
  1. public List<User> findExistingUsers(List<String> userIds) {
  2.     // 批量查询数据库
  3.     List<User> users = userRepository.findByIds(userIds);
  4.     return users;
  5. }
复制代码
  这里有个需要注意的地方是：id聚集的巨细要做限制，最好一次不要哀求太多的数据。要根据现实环境而定，发起控制每次哀求的记载条数在500以内。
  五、异步处置处罚

在进行接口性能优化时，有时候需要重新梳理业务逻辑，查抄是否存在设计不公道的地方。假设有一个用户哀求接口，需要执行以下操纵：

这个接口表面上看起来没有题目，但如果你仔细梳理一下业务逻辑，会发现只有业务操纵才是核心逻辑，其他的功能都黑白核心逻辑。在这里有个原则就是：
   核心逻辑可以同步执行，同步写库。非核心逻辑，可以异步执行，异步写库。
  上面这个例子中，发站内关照和用户操纵日志功能，对实时性要求不高，即使晚点写库，用户无非是晚点收到站内关照，或者运营晚点看到用户操纵日志，对业务影响不大，所以完全可以异步处置处罚。
   异步处置处罚通常有两种主要方式：多线程和消息队列（MQ）
  5.1 线程池异步优化

使用线程池改造之后，接口逻辑如下

5.2 MQ异步

使用线程池有个小题目就是：如果服务器重启了，或者是需要被执行的功能出现异常了，无法重试，会丢数据。
为了制止使用线程池处置处罚异步任务时出现数据丢失的题目，可以考虑使用更加结实和可靠的异步处置处罚方案，如消息队列（MQ）。消息队列不仅可以异步处置处罚任务，还能够保证消息的持久化和可靠性，支持重试机制。
使用mq改造之后，接口逻辑如下：

六、制止大事务

使用@Transactional注解这种声明式事务的方式提供事务功能，确实能少写许多代码，提升开发效率。但也容易造成大事务，引发性能的题目。

   那么我们该如何优化大事务呢？
  为了制止大事务引发的题目，可以考虑以下优化发起：
七、锁粒度

在一些业务场景中，为了制止多个线程并发修改同一共享数据而引发数据异常，通常我们会使用加锁的方式来解决这个题目。然而，如果锁的设计不当，导致锁的粒度过粗，也会对接口性能产生明显的负面影响。
7.1 synchronized

在Java中，我们可以使用synchronized关键字来为代码加锁。
通常有两种写法：在方法上加锁和在代码块上加锁。
1. 方法上加锁
  1. public synchronized void doSave(String fileUrl) {
  2.     mkdir();
  3.     uploadFile(fileUrl);
  4.     sendMessage(fileUrl);
  5. }
复制代码
在方法上加锁的目的是为了防止并发环境下创建相同的目次，制止第二次创建失败而影响业务功能。但这种直接在方法上加锁的方式，锁的粒度较粗。
由于doSave方法中的文件上传和消息发送并不需要加锁，只有创建目次的方法需要加锁。我们知道，文件上传操纵非常耗时，如果将整个方法加锁，那么需要比及整个方法执行完之后才气开释锁。显然，这会导致该方法的性能降落，得不偿失。
2. 代码块上加锁我们可以将加锁改在代码块上，从而缩小锁的粒度， 如下：
  1. public void doSave(String path, String fileUrl) {
  2.     synchronized(this) {
  3.         if (!exists(path)) {
  4.             mkdir(path);
  5.         }
  6.     }
  7.     uploadFile(fileUrl);
  8.     sendMessage(fileUrl);
  9. }
复制代码
这样改造后，锁的粒度变小了，只有并发创建目次时才加锁。创建目次是一个非常快的操纵，即使加锁对接口性能的影响也不大。最重要的是，其他的文件上传和消息发送功能仍然可以并发执行。
多节点环境中的题目 在单机版服务中，这种做法没有题目。但在生产环境中，为了保证服务的稳固性，同一个服务通常会摆设在多个节点上。如果某个节点挂掉，其他节点的服务仍然可用。
多节点摆设制止了某个节点挂掉导致服务不可用的环境，同时也能分摊整个体系的流量，制止体系压力过大。
但这种摆设方式也带来了新的题目：synchronized只能保证一个节点加锁有效。
   如果有多个节点，如何加锁呢？
  7.2 Redis分布式锁

在分布式体系中，由于Redis分布式锁的实现相对简单且高效，因此它在许多现实业务场景中被广泛采取。
使用Redis分布式锁的伪代码如下：
  1. public boolean doSave(String path, String fileUrl) {
  2.     try {
  3.         String result = jedis.set(lockKey, requestId, "NX", "PX", expireTime);
  4.         if ("OK".equals(result)) {
  5.             if (!exists(path)) {
  6.                 mkdir(path);
  7.                 uploadFile(fileUrl);
  8.                 sendMessage(fileUrl);
  9.             }
  10.             return true;
  11.         }
  12.     } finally {
  13.         unlock(lockKey, requestId);
  14.     }
  15.     return false;
  16. }
复制代码
与之前使用synchronized关键字加锁时一样，这里的锁的范围也太大了，换句话说，锁的粒度太粗。这会导致整个方法的执行效率很低。
现实上，只有在创建目次时才需要加分布式锁，别的代码不需要加锁。于是，我们需要优化代码：
  1. public void doSave(String path, String fileUrl) {
  2.     if (tryLock()) {
  3.         try {
  4.             if (!exists(path)) {
  5.                 mkdir(path);
  6.             }
  7.         } finally {
  8.             unlock(lockKey, requestId);
  9.         }
  10.     }
  11.     uploadFile(fileUrl);
  12.     sendMessage(fileUrl);
  13. }
  15. private boolean tryLock() {
  16.     String result = jedis.set(lockKey, requestId, "NX", "PX", expireTime);
  17.     return "OK".equals(result);
  18. }
  20. private void unlock(String lockKey, String requestId) {
  21.     // 解锁逻辑
  22. }
复制代码
上面的代码将加锁的范围缩小了，只有在创建目次时才加锁。这样的简单优化后，接口性能可以得到明显提升。
7.3 数据库锁

MySQL数据库中的三种锁
锁与并发度
并发度越高，接口性能越好。因此，数据库锁的优化方向是：
八、分页处置处罚

有时候，我需要调用某个接口来批量查询数据，比方，通过用户ID批量查询用户信息，然后为这些用户赠予积分。但是，如果一次性查询的用户数目太多，比方一次查询2000个用户的数据，传入2000个用户的ID进行远程调用时，用户查询接口经常会出现超时的环境。
调用代码如下：
  1. List<User> users = remoteCallUser(ids);
复制代码
众所周知，调用接口从数据库获取数据需要经过网络传输。如果数据量过大，无论是数据获取速率还是网络传输速率都会受到带宽限制，从而导致耗时较长。
   那么，这种环境下该如何优化呢？
  答案是：分页处置处罚。
将一次性获取所有数据的哀求，改为分多次获取，每次只获取一部门用户的数据，末了进行合并和汇总。其实，处置处罚这个题目可以分为两种场景：同步调用和异步调用。
8.1 同步调用

如果在job中需要获取2000个用户的信息，它要求只要能正确获取到数据即可，对获取数据的总耗时要求不高。但对每一次远程接口调用的耗时有要求，不能大于500ms，否则会有邮件预警。这时，我们可以同步分页调用批量查询用户信息接口。
具体示例代码如下：
  1. List<List<Long>> allIds = Lists.partition(ids, 200);
  3. for (List<Long> batchIds : allIds) {
  4.     List<User> users = remoteCallUser(batchIds);
  5. }
复制代码
代码中我使用了Google Guava工具中的Lists.partition方法，用它来做分页简直太好用了，不然要写一大堆分页的代码。 8.2 异步调用 如果是在某个接口中需要获取2000个用户的信息，需要考虑的因素更多。
除了远程调用接口的耗时，还需要考虑该接口本身的总耗时，也不能超过500ms。这时，使用上面的同步分页哀求远程接口的方法肯定是行不通的。那么，只能使用异步调用了。
代码如下：
  1. List<List<Long>> allIds = Lists.partition(ids, 200);
  3. final List<User> result = Lists.newArrayList();
  4. allIds.stream().forEach(batchIds -> {
  5.     CompletableFuture.supplyAsync(() -> {
  6.         result.addAll(remoteCallUser(batchIds));
  7.         return Boolean.TRUE;
  8.     }, executor);
  9. });
复制代码
使用CompletableFuture类，通过多个线程异步调用远程接口，末了汇总效果同一返回。
九、加缓存

通常环境下，我们最常用的缓存是：Redis和Memcached。但对于Java应用来说，绝大多数环境下使用的是Redis，所以接下来我们以Redis为例。
在关系型数据库（比方：MySQL）中，菜单通常有上下级关系。某个四级分类是某个三级分类的子分类，三级分类是某个二级分类的子分类，而二级分类又是某个一级分类的子分类。
这种存储结构决定了，想一次性查出整个分类树并非易事。这需要使用程序递归查询，而如果分类许多，这个递归操纵会非常耗时。因此，如果每次都直接从数据库中查询分类树的数据，会是一个非常耗时的操纵。
这时我们可以使用缓存。在大多数环境下，接口直接从缓存中获取数据。操纵Redis可以使用成熟的框架，比如：Jedis和Redisson等。 使用Jedis的伪代码如下：
  1. String json = jedis.get(key);
  2. if (StringUtils.isNotEmpty(json)) {
  3.     CategoryTree categoryTree = JsonUtil.toObject(json);
  4.     return categoryTree;
  5. }
  6. return queryCategoryTreeFromDb();
复制代码
  注意引入缓存之后，我们的体系复杂度就上升了，这时候就会存在数据不一致的题目
  《亿级电商流量，高并发下Redis与MySQL的数据一致性如何保证》
十、分库分表

有时候，接口性能受限的并不是其他方面，而是数据库。
当体系发展到一定阶段，用户并发量增加，会有大量的数据库哀求，这不仅需要占用大量的数据库连接，还会带来磁盘IO的性能瓶颈题目。此外，随着用户数目的不断增加，产生的数据量也越来越大，一张表大概无法存储所有数据。由于数据量太大，即使SQL语句使用了索引，查询数据时也会非常耗时。那么，这种环境下该怎么办呢？
答案是：需要进行分库分表。
如下图所示：

图中将用户库拆分成了三个库，每个库都包含了四张用户表。如果有用户哀求过来，先根据用户ID路由到此中一个用户库，然后再定位到某张表。路由的算法有许多：
1. 垂直分库分表
垂直分库分表（即业务方向）更简单，将不同的业务数据存储在不同的库或表中。
比方，将用户数据和订单数据存储在不同的库中。
2. 程度分库分表
程度分库分表（即数据方向）上，分库和分表的作用有区别，不能混为一谈。
分库


分表


分库分表


业务场景中的应用

十一、监控功能

优化接口性能题目，除了上面提到的这些常用方法之外，还需要配合使用一些辅助功能，由于它们真的可以帮我们提升查找题目的效率。
11.1 开启慢查询日志

通常环境下，为了定位SQL的性能瓶颈，我们需要开启MySQL的慢查询日志。把超过指定时间的SQL语句单独记载下来，方便以后分析和定位题目。
开启慢查询日志需要重点关注三个参数：

通过MySQL的SET下令可以设置：
  1. SET GLOBAL slow_query_log = 'ON';
  2. SET GLOBAL slow_query_log_file = '/usr/local/mysql/data/slow.log';
  3. SET GLOBAL long_query_time = 2;
复制代码
设置完之后，如果某条SQL的执行时间超过了2秒，会被自动记载到slow.log文件中。
固然，也可以直接修改配置文件my.cnf：
  1. [mysqld]
  2. slow_query_log = ON
  3. slow_query_log_file = /usr/local/mysql/data/slow.log
  4. long_query_time = 2
复制代码
但这种方式需要重启MySQL服务。
许多公司每天早上都会发一封慢查询日志的邮件，开发人员根据这些信息优化SQL。
11.2 加监控

为了在出现SQL题目时能够实时发现，我们需要对体系做监控。目前业界使用比较多的开源监控体系是：Prometheus。它提供了监控和预警的功能。
架构图如下：

我们可以用它监控如下信息：

它的界面大概长这样子：

可以看到MySQL的当前QPS、活跃线程数、连接数、缓存池的巨细等信息。如果发现连接池占用的数据量太多，肯定会对接口性能造成影响。这时大概是由于代码中开启了连接却忘记关闭，或者并发量太大导致的，需要进一步排查和体系优化
链路跟踪
有时候，一个接口涉及的逻辑非常复杂，比方查询数据库、查询Redis、远程调用接口、发送MQ消息以及执行业务代码等等。这种环境下，接口的一次哀求会涉及到非常长的调用链路。如果逐一排查这些题目，会泯灭大量时间，此时我们已经无法用传统的方法来定位题目。
有没有办法解决这个题目呢？
答案是使用分布式链路跟踪体系：SkyWalking。
SkyWalking的架构图如下：


在SkyWalking中，可以通过traceId（全局唯一的ID）来串联一个接口哀求的完整链路。你可以看到整个接口的耗时、调用的远程服务的耗时、访问数据库或者Redis的耗时等，功能非常强大。
之前没有这个功能时，为了定位线上接口性能题目，我们需要在代码中加日志，手动打印出链路中各个环节的耗时环境，然后再逐一排查。这种方法不仅费时费力，而且容易遗漏细节。
如果你用过SkyWalking来排查接口性能题目，你会不自觉地爱上它的功能。如果你想相识更多功能，可以访问SkyWalking的官网：skywalking.apache.org。
CPU飙升到100%，GC频繁，故障排查

发现题目

下面是线上呆板的cpu使用率，可以看到从4月8日开始，随着时间cpu使用率在逐步增高，终极使用率达到100%导致线上服务不可用，后面重启了呆板后恢复。

排查思绪

简单分析下大概出题目的地方，分为5个方向：
初步定位题目

1.查看日志，没有发现会合的错误日志，初步排除代码逻辑处置处罚错误。
2.首先接洽了内部下游体系观察了他们的监控，发现一起正常。可以排除下游体系故障对我们的影响。
3.查看provider接口的调用量，对比7天没有突增，排除业务方调用量的题目。
4.查看tcp监控，TCP状态正常，可以排除是http哀求第三方超时带来的题目。
5.查看呆板监控，6台呆板cpu都在上升，每个呆板环境一样。排除单点呆板故障题目。
即通过上述方法没有直接定位到题目。
定位CPU题目

1.重启了6台中题目比较严重的5台呆板，先恢复业务。保留一台现场，用来分析题目。
2.查看当前的tomcat线程pid。

3.查看该pid下线程对应的体系占用环境。
  1. top -Hp 384
复制代码

4.发现pid 4430 4431 4432 4433 线程分别占用了约40%的cpu。

5.将这几个pid转为16进制，分别为114e 114f 1150 1151
6.下载当前的java线程栈 sudo -u tomcat jstack -l 384>/1.txt
7.查询5中对应的线程环境，发现都是gc线程导致的

8.dump java堆数据 sudo -u tomcat jmap -dump:live,format=b,file=/dump201612271310.dat 384 9.使用MAT加载堆文件，可以看到javax.crypto.JceSecurity对象占用了95%的内存空间，初步定位到题目。MAT下载地址：http://www.eclipse.org/mat/

10.查看类的引用树，看到BouncyCastleProvider对象持有过多。即我们代码中对该对象的处置处罚方式是错误的，定位到题目。

代码分析

我们代码中有一块是这样写的

这是加解密的功能，每次运行加解密都会new一个BouncyCastleProvider对象,放倒Cipher.getInstance()方法中。看下Cipher.getInstance()的实现，这是jdk的底层代码实现，追踪到JceSecurity类中

verifyingProviders每次put后都会remove,verificationResults只会put，不会remove.

看到verificationResults是一个static的map，即属于JceSecurity类的。所以每次运行到加解密都会向这个map put一个对象，而这个map属于类的维度，所以不会被GC回收。这就导致了大量的new的对象不被回收。
代码改进

将有题目的对象置为static，每个类持有一个，不会多次新建对象。

本文总结

遇到线上CPU升高题目不要慌，首先确认排查题目的思绪：
高并发下数据读写的安全性

3.1、元数据锁（Meta Data Lock）

Meta Data Lock元数据锁，也被简称为MDL锁，这是基于表的元数据加锁，表锁是基于整张表加锁，行锁是基于一条数据加锁，那这个表的元数据是什么？所有存储引擎的表都会存在一个.frm文件，这个文件中主要存储表的结构（DDL语句），而MDL锁就是基于.frm文件中的元数据加锁的。
   对于这种锁是在MySQL5.5版本后再开始支持的，这个锁主要是用于：更改表结构时使用，比如你要向一张表创建/删除一个索引、修改一个字段的名称/数据范例、增加/删除一个表字段等这类环境。
  由于毕竟当你的表结构正在发生更改，假设此时有其他事务来对表做CRUD操纵，天然就会出现题目，比如我刚删了一个表字段，效果另一个事务中又按原来的表结构插入了一条数据，这显然会存在风险，因此MDL锁在加锁后，整张表不允许其他事务做任何操纵。
3.2、自增锁（AUTO-INC Lock）

自增锁，这个是专门为了提升自增ID的并发插入性能而设计的，通常环境下咱们在建表时，都会对一张表的主键设置自增特性，如下：
  1. CREATE TABLE `table_name` (
  2.     `xx_id` NOT NULL AUTO_INCREMENT,
  3.     .....
  4. ) ENGINE = InnoDB;
复制代码
当对一个字段设置AUTO_INCREMENT自增后，意味着后续插入数据时无需为其赋值，体系会自动赋上顺序自增的值。比如目前表中最大的ID=88，如果两个并发事务一起对表执行插入语句，由于是并发执行的缘故原由，所以有大概会导致插入两条ID=89的数据。因此这里必须要加上一个排他锁，确保并发插入时的安全性，但也由于锁的缘故原由，插入的效率也就因此降低了，毕竟将所有写操纵串行化了。
   为了改善插入数据时的性能，自增锁诞生了，自增锁也是一种特殊的表锁，但它仅为具备AUTO_INCREMENT自增字段的表服务，同时自增锁也分成了不同的级别，可以通过innodb_autoinc_lock_mode参数控制。
  
固然，这三种模式又是什么寄义呢？得先弄明白MySQL中大概出现的三种插入范例：

自增锁主要负责维护并发事务下自增列的顺序，也就是说，每当一个事务想向表中插入数据时，都要先获取自增锁先分配一个自增的顺序值，但不同模式下的自增锁也会有些许不同。
   传统模式：事务T1获取自增锁插入数据，事务T2也要插入数据，此时事务T2只能阻塞等待，也就是传统模式下的自增锁，同时只允许一条线程执行，这种形式显然性能较低。
    连续模式：这个模式主要是由于传统模式存在性能短板而研发的，在这种模式中，对于能够提前确定数目的插入语句，则不会再获取自增锁，啥意思呢？也就是对于“普通插入范例”的语句，由于在插入之前就已经确定了要插入多少条数据，由于会直接分配范围自增值。好比目前事务T1要通过INSERT INTO...语句插入十条数据，目前表中存在的最大ID=88，那在连续模式下，MySQL会直接将89~98这十个自增值分配给T1，因此T1无需再获取自增锁，但不获取自增锁不代表不获取锁了，而是改为使用一种轻量级锁Mutex-Lock来防止自增值重复分配。
  
  对于普通插入范例的操纵，由于可以提前确定插入的数据量，因此可以采取“预分配”思想，但如若对于批量插入范例的操纵，由于批量插入的数据是基于SELECT语句查询出来的，所以在执行之前也无法确定究竟要插入多少条，所以仍旧会获取自增锁执行。也包罗对于混合插入范例的操纵，有一部门指定了自增值，但有一部门需要MySQL分配，因此“预分配”的思想也用不上，因此也要获取自增锁执行。
    交错模式：在交错插入模式中，对于INSERT、REPLACE、INSERT…SELECT、REPLACE…SELECT、LOAD DATA等一系列插入语句，都不会再使用表级别的自增锁，而是全都使用Mutex-Lock来确保安全性，为什么在这个模式中，批量插入也可以不获取自增锁呢？这跟它的名字有关，目前这个模式叫做交错插入模式，也就是不同事务之间插入数据时，自增列的值是交错插入的。
  
  好比事务T1、T2都要执行批量插入的操纵，由于不确定各自要插入多少条数据，所以之前那种“连续预分配”的思想用不了了，但虽然无法做“连续的预分配”，那能不能交错预分配呢？好比给T1分配{1、3、5、7、9....}，给T2分配{2、4、6、8、10.....}，然后两个事务交错插入，这样岂不是做到了自增值即不重复，也能支持并发批量插入？答案是Yes，但由于两个事务执行的都是批量插入的操纵，因此事先不确定插入行数，所以有大概导致“交错预分配”的顺序值，有大概不会使用，比如T1只插入了四条数据，只用了1、3、5、7，T2插入了五条数据，因此表中的自增值有大概出现清闲，即{1、2、3、4、5、6、8、10}，此中9就并未使用。
  3.3、全局锁

全局锁其实是一种尤为特殊的表锁，其实将它称之为库锁也许更符合，由于全局锁是基于整个数据库来加锁的，加上全局锁之后，整个数据库只能允许读，不允许做任何写操纵，一样平常全局锁是在对整库做数据备份时使用。
  1. -- 获取全局锁的命令
  2. FLUSH TABLES WITH READ LOCK;
  4. -- 释放全局锁的命令
  5. UNLOCK TABLES;
复制代码
从上述的下令也可以看出，为何将其归纳到表锁范围，由于获取锁以及开释锁的下令都是表锁的下令。
   PS：表中横向（行）表示已经持有锁的事务，纵向（列）表示正在哀求锁的事务。
  
行级锁对比共享临键锁排他临键锁间隙锁插入意向锁
共享临键锁兼容辩论兼容辩论
排他临键锁辩论辩论兼容辩论
间隙锁兼容兼容兼容辩论
插入意向锁辩论辩论辩论兼容
由于临建锁也会锁定相应的行数据，因此上表中也不再重复赘述记载锁，临建锁兼容的 记载锁都兼容，同理，辩论的记载锁也会辩论，再来看看标记别的锁对比：
表级锁对比共享意向锁排他意向锁元数据锁自增锁全局锁
共享意向锁兼容辩论辩论辩论辩论
排他意向锁辩论辩论辩论辩论辩论
元数据锁辩论辩论辩论辩论辩论
自增锁辩论辩论辩论辩论辩论
全局锁兼容辩论辩论辩论辩论
会发现表级别的锁，会有许多许多辩论，由于锁的粒度比较大，因此许多时候都会出现辩论，但对于表级锁，咱们只需要关注共享意向锁和共享排他锁即可，其他的大多数为MySQL的隐式锁（在这里，共享意向锁和排他意向锁，也可以理解为MyISAM中的表读锁和表写锁）。
   末了再简单的说一下，表中的辩论和兼容究竟是啥意思？辩论的意思是当一个事务T1持有某个锁时，另一个事务T2来哀求相同的锁，T2会由于锁排斥会陷入阻塞等待状态。反之同理，兼容的意思是指允许多个事务一同获取同一个锁。
  MySQL5.7 共享排他锁

在MySQL5.7之前的版本中，数据库中仅存在两种范例的锁，即共享锁与排他锁，但是在MySQL5.7.2版本中引入了一种新的锁，被称之为(SX)共享排他锁，这种锁是共享锁与排他锁的杂交范例，至于为何引入这种锁呢？
   SMO题目（Split-Merge Overflow）通常出现在数据库管理体系中，特别是在B+Tree索引结构的操纵过程中。以下是对SMO题目的表明：
**B+Tree**：
B+Tree是一种自平衡的树数据结构，通常用于数据库和操纵体系的索引。在数据库中，B+Tree用于快速检索记载，由于它们允许对数据进行排序并支持对数时间复杂度的搜刮、顺序访问、插入和删除操纵。
**SMO题目**：
1. **Split（分裂）**：当向B+Tree中的一个页（通常是磁盘上的一个块）插入一个新的键，而这个页已经满了时，就会发生分裂。这时，页中的键和指针会被分成两个部门，一部门保留在原页，另一部门被移动到一个新的页中。这种操纵大概导致树的其他部门也发生分裂，以保持B+Tree的性质。
2. **Merge（合并）**：删除操纵大概导致页中的键的数目镌汰，如果某个页中的键的数目低于某个阈值，这个页大概需要与它的兄弟页合并，以保持B+Tree的效率。
**Overflow（溢出）**：
SMO题目中的“Overflow”指的是在分裂或合并操纵中，由于页分裂或合并导致的额外开销和处置处罚，大概会引起体系性能的降落。特别是在高并发的数据库环境中，这种开销大概会更加明显。
**减小锁定的B+Tree粒度**：
在多用户并发访问数据库时，锁定是用于保持数据一致性的机制。减小锁定粒度意味着锁定的范围更小，比方，不是锁定整个B+Tree页，而是只锁定页中的某个部门。这样做可以镌汰并发操纵中的锁争用，从而进步体系的并发性能。具体到SMO题目，减小粒度可以帮助镌汰因分裂或合并操纵而需要锁定的大量资源，从而减轻性能降落的题目。
  
总结来说，SMO题目是数据库中B+Tree索引结构在维护其平衡和效率时，因分裂和合并操纵导致的一系列性能挑衅。通过优化锁定策略，可以镌汰SMO题目对数据库性能的影响。
    在SQL执行期间一旦更新操纵触发B+Tree叶子节点分裂，那么就会对整棵B+Tree加排它锁，这不但阻塞了后续这张表上的所有的更新操纵，同时也制止了所有试图在B+Tree上的读操纵，也就是会导致所有的读写操纵都被阻塞，其影响巨大。因此，这种大粒度的排它锁成为了InnoDB支持高并发访问的主要瓶颈，而这也是MySQL 5.7版本中引入SX锁要解决的题目。
  那想一下该如何解决这个题目呢？最简单的方式就是减小SMO题目发生时，锁定的B+Tree粒度，当发生SMO题目时，就只锁定B+Tree的某个分支，而并不是锁定整颗B+树，从而做到不影响其他分支上的读写操纵。
   那MySQL5.7中引入共享排他锁后，究竟是如何实现的这点呢？首先要弄清楚SX锁的特性，它不会阻塞S锁，但是会阻塞X、SX锁。
  在聊之前首先得搞清楚SQL执行时的几个概念：

在MySQL5.6版本中，一旦有操纵导致了树结构发生变化，就会对整棵树加上排他锁，阻塞所有的读写操纵，而MySQL5.7版本中，为相识决该题目，对于不同的SQL执行，流程就做了调整。
MySQL5.7中读操纵的执行流程


MySQL5.7中乐观写入的执行流程


MySQL5.7中悲观写入的执行流程


如果需要修改多个数据时，会在遍历查找的过程中，记载下所有要修改的目标节点。
MySQL5.7中并发事务辩论分析

观察上述讲到的三种执行环境，对于读操纵、乐观写入操纵而言，并不会加SX锁，共享排他锁仅针对于悲观写入操纵会加，由于读操纵、乐观写入执行前对整颗树加的是S锁，因此悲观写入时加的SX锁并不会阻塞乐观写入和读操纵，但当另一个事务实验执行SMO操纵变动树结构时，也需要先对树加上一个SX锁，这时两个悲观写入的并发事务就会出现辩论，新来的事务会被阻塞。
   但是要注意：当第一个事务寻找到要修改的节点后，会对其分支加上X锁，紧接着会开释B+Tree上的SX锁，这时另外一个执行SMO操纵的事务就能获取SX锁啦！
  其实从上述中大概得知一点：MySQL5.7版本引入共享排他锁之后，解决了5.6版本发生SMO操纵时阻塞统统读写操纵的题目，这样能够在一定程度上提升了InnoDB表的并发性能。
   末了要注意：虽然一个执行悲观写入的事务，找到了要更新/插入数据的节点后会开释SX锁，但是会对其上级的叶节点（叶分支）加上排他锁，因此正在发生SMO操纵的叶分支，仍旧是会阻塞所有的读写行为！
  当一个要读取的数据，位于正在执行SMO操纵的叶分支中时，仍旧会被阻塞。

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。



欢迎光临 IT评测·应用市场-qidao123.com (https://dis.qidao123.com/) Powered by Discuz! X3.4