发表于

以下介绍五种-不同的方法去除 Java 中ArrayList中的重复数据

1.使用LinkedHashSet删除arraylist中的重复数据

LinkedHashSet是在一个ArrayList删除重复数据的最佳方法。LinkedHashSet在内部完成两件事：

  • 删除重复数据
  • 保持添加到其中的数据的顺序

Java示例使用LinkedHashSet删除arraylist中的重复项。在给定的示例中，numbersList是包含整数的arraylist，其中一些是重复的数字，例如1,3和5.我们将列表添加到LinkedHashSet，然后将内容返回到列表中。结果arraylist没有重复的整数。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
java复制代码import java.util.ArrayList;
import java.util.Arrays;
import java.util.LinkedHashSet;

public class ArrayListExample
{
    public static void main(String[] args)
    
    {

        ArrayList<Integer> numbersList = new ArrayList<>(Arrays.asList(1, 1, 2, 3, 3, 3, 4, 5, 6, 6, 6, 7, 8));

        System.out.println(numbersList);

        LinkedHashSet<Integer> hashSet = new LinkedHashSet<>(numbersList);

        ArrayList<Integer> listWithoutDuplicates = new ArrayList<>(hashSet);

        System.out.println(listWithoutDuplicates);

    }

}

输出结果

1
2
3
csharp复制代码[1, 1, 2, 3, 3, 3, 4, 5, 6, 6, 6, 7, 8]

[1, 2, 3, 4, 5, 6, 7, 8]

2.使用java8新特性stream进行List去重

要从arraylist中删除重复项，我们也可以使用java 8 stream api。使用steam的distinct()方法返回一个由不同数据组成的流，通过对象的equals（） 方法进行比较。

收集所有区域数据List使用Collectors.toList()。

Java程序，用于在不使用Set的情况下从java中的arraylist中删除重复项。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
java复制代码import java.util.ArrayList;
import java.util.Arrays;
import java.util.List;
import java.util.stream.Collectors;

public class ArrayListExample
{
    public static void main(String[] args)
    
    {
    
        ArrayList<Integer> numbersList = new ArrayList<>(Arrays.asList(1, 1, 2, 3, 3, 3, 4, 5, 6, 6, 6, 7, 8));

        System.out.println(numbersList);

        List<Integer> listWithoutDuplicates = numbersList.stream().distinct().collect(Collectors.toList());

        System.out.println(listWithoutDuplicates);
        
    }
    
}

输出结果

1
2
3
csharp复制代码[1, 1, 2, 3, 3, 3, 4, 5, 6, 6, 6, 7, 8]

[1, 2, 3, 4, 5, 6, 7, 8]

3.利用HashSet不能添加重复数据的特性 由于HashSet不能保证添加顺序，所以只能作为判断条件保证顺序：

1
2
3
4
5
6
7
8
9
10
11
arduino复制代码private static void removeDuplicate(List<String> list) {
    HashSet<String> set = new HashSet<String>(list.size());
    List<String> result = new ArrayList<String>(list.size());
    for (String str : list) {
        if (set.add(str)) {
            result.add(str);
        }
    }
    list.clear();
    list.addAll(result);
}

4.利用List的contains方法循环遍历,重新排序,只添加一次数据,避免重复：

1
2
3
4
5
6
7
8
9
10
typescript复制代码private static void removeDuplicate(List<String> list) {
    List<String> result = new ArrayList<String>(list.size());
    for (String str : list) {
       if (!result.contains(str)) {
           result.add(str);
        }
    }
    list.clear();
    list.addAll(result);
}

5.双重for循环去重

1
2
3
4
5
6
ini复制代码for (int i = 0; i < list.size(); i++) { 
for (int j = 0; j < list.size(); j++) { 
if(i!=j&&list.get(i)==list.get(j)) { 
list.remove(list.get(j)); 
 } 
}

作者 | 多纤果冻
来源 | csdn.net/qq_37939251/article/details/90713643

本文转载自: 掘金

开发者博客 – 和开发相关的 这里全都有

发表于

使用过jpa就会知道，我们借住@Query注解进行查询操作时，如果单表查询返回的是一个字段或者一个实体类时，很容易接收查询的结果；但是如果我们进行多表关联查询，查询的字段并不一定都在一个表中，所以就不能用实体类接收了，对于这样查询结果又一下三种方式处理。

用Object[]接收
这种方式显得水平好矬，取值的时候还要通过数组索引去取值，太low了，一堆代码看起来也不好看。如果仅是做一些统计类的查询勉强可以接收。

  1. 用Map<String, Object>接收

这种方式相对来说要比Object[]好，因为map的key就是我们查询的字段名，再取值的时候直接通过get方法取值就行，比较方便，当是相比直接用一个pojo来接收结果，使用起来还是要差一些。如何才能将结果转成自定义的对象呢，网上有一些文章是这样处理的：先有map来接收，再讲map转成json，最后将json解析成自定义得pojo(参见JPA自定义对象接收查询结果集_klayer_cong的博客-CSDN博客)。这样看起来处理过程有点麻烦，但是比较容易理解，确实也转成了自定义的pojo，如果只是一条查询结果这样实现还说的过去，如果查询出的数量很大，将会大大影响性能，这个时候就不太好了。

  1. 用@NamedNativeQuery+@SqlResultSetMapping处理

具体实现如下：

（1）pojo

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
java复制代码@NamedNativeQuery(
        name = "querySummary",
        query = " select t2.city_cd as cityCd,t2.city_name as cityName,DATE_FORMAT(t1.create_time,'%Y-%m-%d') as createDate,t1.sale_type as saleType " +
                " from tb_project_sale t2 " +
                " left join tb_project_sale_core t1 on t2.id = t1.id " +
                " where t1.sale_type is not null ",
        resultClass = SummaryDto.class,
        resultSetMapping = "summaryMapping")
@MappedSuperclass
@SqlResultSetMapping(
        name = "summaryMapping",
        classes = @ConstructorResult(
                targetClass = SummaryDto.class,
                columns = {
                        @ColumnResult(name = "cityCd", type = String.class),
                        @ColumnResult(name = "cityName", type = String.class),
                        @ColumnResult(name = "createDate", type = String.class),
                        @ColumnResult(name = "saleType", type = String.class),
                }
        )
)
@AllArgsConstructor
@NoArgsConstructor
@Setter
@Getter
public class SummaryDto {

    private String cityCd;

    private String cityName;

    private String createDate;

    private String saleType;

}

（2）repository

1
2
3
4
5
6
7
8
9
10
11
12
13
java复制代码@Repository
@Transactional
public class SummaryRpt {

    @PersistenceContext
    private EntityManager entityManager;

    public List<SummaryDto> getSummary() {
        return entityManager.createNamedQuery("querySummary")
                .getResultList();
    }

}

（3）测试类

1
2
3
4
5
6
7
8
9
10
11
12
13
14
java复制代码@RunWith(SpringRunner.class
@SpringBootTest
public class SummaryServiceImplTest {

    @Autowired
    private SummaryRpt summaryRpt;

    @Test
    public void test() {
        List<SummaryDto> list = summaryRpt.getSummary();
        return;
    }

}

注意：上文中pojo中的注解都是有用的，不要随意删减

本文参考: my.oschina.net/joryqiao/bl…

本文转载自: 掘金

开发者博客 – 和开发相关的 这里全都有

发表于

一. spring cache

对于缓存，可以使用的框架太多，如reids,caffeine,ehcache等等，各有各自的优势。如果我们要想使用缓存，就得与这些框架耦合，为了避免这种情况，spring cache就利用AOP，实现基于注解的缓存功能，并进行合理的抽象，使业务代码不用担心底层使用了什么缓存框架。

二. 编码

1. maven依赖

1
2
3
4
5
6
7
8
9
10
11
12
13
14
xml复制代码<dependencies>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
        </dependency>
        <dependency>
            <groupId>org.projectlombok</groupId>
            <artifactId>lombok</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-data-redis</artifactId>
        </dependency>
</dependencies>

2. application.yml配置文件

1
2
3
4
5
6
7
8
9
10
yaml复制代码spring:
  redis:
    lettuce:
      pool:
        max-active: 8 # 连接池最大连接数
        max-idle: 8 # 连接池最大空闲连接数
        min-idle: 0 # 连接池最小空闲连接数
        max-wait: -1ms # 连接池最大阻塞等待时间，负值表示没有限制
    host: localhost
    port: 6379

3. CacheConfig配置类

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
java复制代码/**
 * @Description: 缓存配置
 * @Author: songrenwei
 * @Date: 2020/12/11/00:00
 */
@Configuration
@EnableCaching
public class CacheConfig {

    @Bean
    public CacheManager cacheManager(RedisConnectionFactory connectionFactory) {
        RedisSerializer<String> stringRedisSerializer = new StringRedisSerializer();
        //default信息缓存配置
        RedisCacheConfiguration default1h = RedisCacheConfiguration.defaultCacheConfig()
                        // 设置过期时间
                        .entryTtl(Duration.ofHours(1))
                        // String的方式序列化key
                        .serializeKeysWith(RedisSerializationContext.SerializationPair.fromSerializer(stringRedisSerializer))
                        // jackson的方式序列化value
                        .serializeValuesWith(RedisSerializationContext.SerializationPair.fromSerializer(jsonSerializer()))
                        // 空值不缓存
                        .disableCachingNullValues()
                        // 设置缓存名称前缀
                        .prefixCacheNameWith("default_1h:");
        RedisCacheConfiguration m30 = RedisCacheConfiguration.defaultCacheConfig().entryTtl(Duration.ofMinutes(30)).serializeKeysWith(RedisSerializationContext.SerializationPair.fromSerializer(stringRedisSerializer)).serializeValuesWith(RedisSerializationContext.SerializationPair.fromSerializer(jsonSerializer())).disableCachingNullValues().prefixCacheNameWith("srw_");
        RedisCacheConfiguration d30 = RedisCacheConfiguration.defaultCacheConfig().entryTtl(Duration.ofDays(30)).serializeKeysWith(RedisSerializationContext.SerializationPair.fromSerializer(stringRedisSerializer)).serializeValuesWith(RedisSerializationContext.SerializationPair.fromSerializer(jsonSerializer())).disableCachingNullValues().prefixCacheNameWith("srw_");
        RedisCacheConfiguration h24 = RedisCacheConfiguration.defaultCacheConfig().entryTtl(Duration.ofHours(24)).serializeKeysWith(RedisSerializationContext.SerializationPair.fromSerializer(stringRedisSerializer)).serializeValuesWith(RedisSerializationContext.SerializationPair.fromSerializer(jsonSerializer())).disableCachingNullValues().prefixCacheNameWith("srw_");
        RedisCacheConfiguration s60 = RedisCacheConfiguration.defaultCacheConfig().entryTtl(Duration.ofSeconds(60)).serializeKeysWith(RedisSerializationContext.SerializationPair.fromSerializer(stringRedisSerializer)).serializeValuesWith(RedisSerializationContext.SerializationPair.fromSerializer(jsonSerializer())).disableCachingNullValues().prefixCacheNameWith("srw_");

        Map<String, RedisCacheConfiguration> redisCacheConfigurationMap = new LinkedHashMap<String, RedisCacheConfiguration>(8) {
            private static final long serialVersionUID = 2474073019770319870L;
            {
                put("60s", s60);
                put("30m", m30);
                put("24h", h24);
                put("30d", d30);
                put("default", default1h);
            }
        };

        return new RedisCacheManager(RedisCacheWriter.nonLockingRedisCacheWriter(connectionFactory), default1h, redisCacheConfigurationMap);
    }

    @Bean
    public RedisTemplate<String, Object> redisTemplate(RedisConnectionFactory connectionFactory) {
        RedisTemplate<String, Object> template = new RedisTemplate<>();
        template.setConnectionFactory(connectionFactory);
        RedisSerializer<Object> jackson2JsonRedisSerializer = jsonSerializer();
        StringRedisSerializer stringRedisSerializer = new StringRedisSerializer();
        // key采用String的序列化方式
        template.setKeySerializer(stringRedisSerializer);
        // hash的key也采用String的序列化方式
        template.setHashKeySerializer(stringRedisSerializer);
        // value序列化方式采用jackson
        template.setValueSerializer(jackson2JsonRedisSerializer);
        // hash的value序列化方式采用jackson
        template.setHashValueSerializer(jackson2JsonRedisSerializer);
        template.afterPropertiesSet();
        return template;
    }

    private RedisSerializer<Object> jsonSerializer() {
        Jackson2JsonRedisSerializer<Object> jackson2JsonRedisSerializer = new Jackson2JsonRedisSerializer<>(Object.class);


        // 解决查询缓存转换异常的问题
        ObjectMapper om = new ObjectMapper();
        om.setVisibility(PropertyAccessor.ALL, JsonAutoDetect.Visibility.ANY);
        om.activateDefaultTyping(LaissezFaireSubTypeValidator.instance , ObjectMapper.DefaultTyping.NON_FINAL, JsonTypeInfo.As.PROPERTY);
        jackson2JsonRedisSerializer.setObjectMapper(om);
        return jackson2JsonRedisSerializer;
    }

}

4. 测试

4.1 controller

1
2
3
4
5
6
7
8
9
10
11
12
13
java复制代码@Slf4j
@RestController
@RequestMapping("/user")
@RequiredArgsConstructor
public class UserController {

    private final UserService userService;

    @GetMapping("/query/{id}")
    public JsonResult<?> query(@PathVariable("id") Long id) {
        return JsonResult.successResponse(userService.query(id));
    }
}

4.2 service

1
2
3
4
5
6
7
8
9
10
11
12
13
java复制代码@Slf4j
@Service
@RequiredArgsConstructor
public class UserServiceImpl implements UserService {

    private final UserMapper userMapper;

    @Cacheable(value = "30m", key = "#id", unless = "#result == null")
    @Override
    public User query(Long id) {
        return userMapper.selectById(id);
    }
}

4.3 测试结果

调用前先刷新下redis, 如下没有对应的key
在这里插入图片描述
postman调用接口
在这里插入图片描述
成功响应，查看日志
在这里插入图片描述
刷新redis
在这里插入图片描述
redis中已经存储了key, 以及缓存有效期
再调下接口，查看日志，未显示日志，说明已经走了redis。

本文转载自: 掘金

开发者博客 – 和开发相关的 这里全都有

发表于

趁热打铁再来一个递归调用，也是前后端对接的需求，前端页面可以展开table里的某一行，需满足多层级关系，因此解决该问题，以递归的方式处理更为方便，页面需求如下：
展开前：
在这里插入图片描述

展开后：
在这里插入图片描述

蓝色圈出的部分可视为子table，即子节点，子节点也可以展开，以此类推。。。可以无限递归下去。

代码：

实体类
在这里插入图片描述

持久层用的是jpa，实现自关联比较方便。

  1. 服务类

（1）DTO
在这里插入图片描述

（2）查询记录
在这里插入图片描述

直接查询父级节点，因为自关联时子节点已经挂在父级下面。

（3）遍历
在这里插入图片描述

buildApiParamDTO（）方法为实体类与DTO的转化。

（4）递归
在这里插入图片描述

apiParamDTOList为最为层的list，apiParamDTO为遍历到的当前节点，apiParamDTOs为apiParamDTO的子节点。
在这里插入图片描述

递归子节点，用到递归最重要的一点就是要有一个退出递归的条件。因此，我们这里首先要判断子节点是否存在，不存在则直接退出，不要递归，否则继续；因为子节点也是集合合，具体逻辑如下：

第一步：遍历子节点，我这里用了java8的stream流更方面的实现；

第二步：映射，在转换的时候，首先要获取当前节点childApiParamDTO，当前节点childApiParamDTO也可能是父节点，然后对当前节点进行递归调用，获取转换后的childApiParamDTOs，childApiParamDTOs是childApiParamDTO的子节点，调用setChildApiParamDTOs（）方法。

第三部：将转换后的Set返回到外层，调用set方法。

效果：

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
xml复制代码"list":[
                    {
                        "type":"REQ_PARAM",
                        "param_name":"userName",
                        "param_type":"String",
                        "required":true,
                        "max_length":64,
                        "param_desc":"用户名16",
                        "sample_value":"张三",
                        "child_params":[
                            {
                                "type":"REQ_PARAM",
                                "param_name":"age",
                                "param_type":"int",
                                "required":true,
                                "max_length":0,
                                "param_desc":"年龄44",
                                "sample_value":"26",
                                "child_params":[
                                    {
                                        "type":"REQ_PARAM",
                                        "param_name":"age",
                                        "param_type":"int",
                                        "required":true,
                                        "max_length":0,
                                        "param_desc":"年龄48",
                                        "sample_value":"26"
                                    },
                                    {
                                        "type":"REQ_PARAM",
                                        "param_name":"age",
                                        "param_type":"int",
                                        "required":true,
                                        "max_length":0,
                                        "param_desc":"年龄49",
                                        "sample_value":"26"
                                    }
                                ]
                            },
                            {
                                "type":"REQ_PARAM",
                                "param_name":"age",
                                "param_type":"int",
                                "required":true,
                                "max_length":0,
                                "param_desc":"年龄17",
                                "sample_value":"26"
                            }
                        ]
                    },
                    {
                        "type":"REQ_PARAM",
                        "param_name":"userName",
                        "param_type":"String",
                        "required":true,
                        "max_length":64,
                        "param_desc":"用户名45",
                        "sample_value":"张三"
                    }
                ]

本文转载自: 掘金

开发者博客 – 和开发相关的 这里全都有

发表于

递归作为一种算法在程序设计语言中广泛应用。 一个过程或函数在其定义或说明中有直接或间接调用自身的一种方法，它通常把一个大型复杂的问题层层转化为一个与原问题相似的规模较小的问题来求解，递归策略只需少量的程序就可描述出解题过程所需要的多次重复计算，大大地减少了程序的代码量。接下来就工作中的一个例子简单练习下：

  1. 创建一个pojo
1
2
3
4
5
6
7
8
java复制代码@Data
Class Directory {
    // 目录标签
    private String label;

    // 子目录
    private List<Directory> children;
}
  1. 具体实现类
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
java复制代码@Component
public class FileDirectory {

    private static Directory root = new Directory();

    private static String ROOT_LABEL = "fabcar";

    public static Directory fileList(File file, String rootName, List<Directory> child) {
        if (file.isFile() || 0 == file.listFiles().length) {
            return null;
        } else {
            // 绑定到根部录下
            if (ROOT_LABEL.equals(rootName)) {
                root.setLabel(rootName);
                root.setChildren(child);
            }

            // 遍历目录
            File[] files = file.listFiles();
            for(File f : files) {
                if (f.isFile()) {
                    // 如果是文件
                    Directory content = new Directory();
                    content.setLabel(f.getName());
                    child.add(content);
                } else if (f.isDirectory()) {
                    // 如果是目录
                    List<Directory> children = new ArrayList<>(); // 生成子目录用于存放递归目录
                    Directory content = new Directory();
                    content.setLabel(f.getName());
                    content.setChildren(children);
                    child.add(content);

                    // 递归目录
                    fileList(f, f.getName(), children);
                }
            }
        }

        return root;
    }

}
  1. 运行main方法
1
2
3
4
5
6
7
java复制代码public static void main(String[] args) {
        File file = new File("E:\path\tmp\src\fabcar");
        List<Directory> childList = new ArrayList<>();
        Directory directory = fileList(file, ROOT_LABEL, childList);

        System.out.println(JSONUtil.toJsonStr(directory));
    }
  1. 运行结果
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
json复制代码{
    "children":[
        {
            "lable":"fabcar.go"
        },
        {
            "lable":"go.sum"
        },
        {
            "children":[
                {
                    "lable":"moudles.txt"
                }
            ],
            "lable":"fabcar.go"
        }
    ],
    "lable":"fabcar"
}
1
复制代码

本文转载自: 掘金

开发者博客 – 和开发相关的 这里全都有

发表于
  1. 确认前置条件
1. linux kernel devel 和header package已经安装
kernel-devel-(uname−r)kernel−headers−(uname -r) kernel-headers-(uname−r)kernel−headers−(uname -r)
2. gcc 版本
gcc --version
如果没有gcc需要安装
3. nouveau没有被加载
lsmod |grep -i nouveau
  1. 卸载之前安装的版本
    /usr/bin/nvidia-uninstall
    /usr/local/cuda/bin/cuda-uninstall
  2. 将系统切换到runlevel 3
    who -r (runlevel)
    sudo systemctl isolate multi-user.target
  3. 安装
    sudo sh cuda-xxx.run
  4. 排错
    当cuda driver安装失败时，查看/var/log/cuda-installer.log
    如果有错误，如到/var/log/nvidia-installer.log文件去查看详细的日志

本文转载自: 掘金

开发者博客 – 和开发相关的 这里全都有

发表于

一、抛出问题

关于如何计算并发线程数，一般分两派，来自两本书，且都是好书，到底哪个是对的？问题追踪后，整理如下：

第一派：《Java Concurrency in Practice》即《java并发编程实践》，如下图：

如上图，在《Java Concurrency in Practice》一书中，给出了估算线程池大小的公式：

Nthreads=Ncpu*Ucpu*(1+w/c)，其中

Ncpu=CPU核心数

Ucpu=cpu使用率，0~1

W/C=等待时间与计算时间的比率

第二派：《Programming Concurrency on the JVM Mastering》即《Java 虚拟机并发编程》

线程数=Ncpu/（1-阻塞系数）

二.分析

对于派系一，假设cpu100%运转，即撇开CPU使用率这个因素，线程数=Ncpu*(1+w/c)。

现在假设将派系二的公式等于派系一公式，即Ncpu/（1-阻塞系数）=Ncpu*(1+w/c),===》阻塞系数=w/(w+c)，即阻塞系数=阻塞时间/（阻塞时间+计算时间），这个结论在派系二后续中得到应征，如下图：

由此可见，派系一和派系二其实是一个公式……这样我就放心了……

三、实际应用

那么实际使用中并发线程数如何设置呢？分析如下（我们以派系一公式为例）：

Nthreads=Ncpu*(1+w/c)，w是阻塞时间，c是计算时间，Ncpu是cpu核数（可用处理器数目）

IO密集型：一般情况下，如果存在IO，那么肯定w/c>1（阻塞耗时一般都是计算耗时的很多倍）,但是需要考虑系统内存有限（每开启一个线程都需要内存空间），这里需要上服务器测试具体多少个线程数适合（CPU占比、线程数、总耗时、内存消耗）。如果不想去测试，保守点取1即，Nthreads=Ncpu*(1+1)=2Ncpu。这样设置一般都OK。

计算密集型：假设没有等待w=0，则W/C=0. Nthreads=Ncpu。

至此结论就是：

IO密集型=2Ncpu（可以测试后自己控制大小，2Ncpu一般没问题）（常出现于线程中：数据库数据交互、文件上传下载、网络数据传输等等）

计算密集型=Ncpu（常出现于线程中：复杂算法）

java中：Ncpu=Runtime.getRuntime().availableProcessors()

end

本文转载自: 掘金

开发者博客 – 和开发相关的 这里全都有

发表于

主要思路：相同key值的消息写入同一个partition（partition内的消息是有序的），一个partition的消息只会被一个消费者消费。

如果一个消费者是多个线程消费，则需要把pull来的消息按照key值写入不同的内存队列中，相同key值的消息写入同一个内存队列（内存队列内的消息是有序的），然后一个线程消费一个内存队列。

1、rabbitMq

问题分析：

imagepng

如图，data1 和 data2 是有顺序的，必须 data1 先执行，data2 后执行；这两个数据被不同的消费者消费到了，可能 data2 先执行，data1 后执行，这样原来的顺序就错乱了。

解决方案：

imagepng

如图，在 MQ 里面创建多个 queue，同一规则的数据（对唯一标识进行 hash），有顺序的放入 MQ 的 queue 里面，消费者只取一个 queue 里面获取数据消费，这样执行的顺序是有序的。或者还是只有一个 queue 但是对应一个消费者，然后这个消费者内部用内存队列做排队，然后分发给底层不同的 worker 来处理。

2、kafka

问题分析：

imagepng

如图，在 kafka 中，你对数据指定某个 key，那么这些数据会到同一个 partition 里面，在 partition 里面这些数据是有顺序的。从这里看没啥问题，插入到数据库的数据都是有序的。

但是，我们在消费端可能会使用多线程来处理，因为单线程的处理速度慢，为了加快处理时间和吞吐量，会使用 thread 来处理。在消费端加入线程之后，就会出现顺序不一致的情况。

imagepng

如图，就是使用了多线程之后，数据顺序不一致情况。

在使用了多线程之后，如何来解决数据顺序问题？

imagepng

如图，在消费端使用内存队列，队列里的数据使用 hash 进行分发，每个线程对应一个队列，这样可以保证数据的顺序。

3、rocketMq

imagepng

如图，生产者中把 orderId 进行取模，把相同模的数据放到 messagequeue 里面，消费者消费同一个 messagequeue，只要消费者这边有序消费，那么可以保证数据被顺序消费。

4、activeMq

imagepng

如图，activeMq 里面有 messageGroups 属性，可以指定 JMSXGroupID，消费者会消费指定的 JMSXGroupID。即保证了顺序性，又解决负载均衡的问题。

end

本文转载自: 掘金

开发者博客 – 和开发相关的 这里全都有

发表于

随着业务的快速发展、业务复杂度越来越高，几乎每个公司的系统都会从单体走向分布式，特别是转向微服务架构。随之而来就必然遇到分布式事务这个难题，这篇文章总结了分布式事务最经典的解决方案，分享给大家。

基础理论

在讲解具体方案之前，我们先了解一下分布式事务所涉及到的基础理论知识。

我们拿转账作为例子，A需要转100元给B，那么需要给A的余额-100元，给B的余额+100元，整个转账要保证，A-100和B+100同时成功，或者同时失败。看看在各种场景下，是如何解决这个问题的。

事务

把多条语句作为一个整体进行操作的功能，被称为数据库事务。数据库事务可以确保该事务范围内的所有操作都可以全部成功或者全部失败。

事务具有 4 个属性：原子性、一致性、隔离性、持久性。这四个属性通常称为 ACID 特性。

  • Atomicity（原子性）：一个事务中的所有操作，要么全部完成，要么全部不完成，不会结束在中间某个环节。事务在执行过程中发生错误，会被恢复到事务开始前的状态，就像这个事务从来没有执行过一样。
  • Consistency（一致性）：在事务开始之前和事务结束以后，数据库的完整性没有被破坏。完整性包括外键约束、应用定义的等约束不会被破坏。
  • Isolation（隔离性）：数据库允许多个并发事务同时对其数据进行读写和修改的能力，隔离性可以防止多个事务并发执行时由于交叉执行而导致数据的不一致。
  • Durability（持久性）：事务处理结束后，对数据的修改就是永久的，即便系统故障也不会丢失。

分布式事务

银行跨行转账业务是一个典型分布式事务场景，假设A需要跨行转账给B，那么就涉及两个银行的数据，无法通过一个数据库的本地事务保证转账的ACID，只能够通过分布式事务来解决。

分布式事务就是指事务的发起者、资源及资源管理器和事务协调者分别位于分布式系统的不同节点之上。在上述转账的业务中，用户A-100操作和用户B+100操作不是位于同一个节点上。本质上来说，分布式事务就是为了保证在分布式场景下，数据操作的正确执行。

分布式事务在分布式环境下，为了满足可用性、性能与降级服务的需要，降低一致性与隔离性的要求，一方面遵循 BASE 理论（BASE相关理论，涉及内容非常多，感兴趣的同学，可以参考BASE理论）：

基本业务可用性（Basic Availability）
柔性状态（Soft state）
最终一致性（Eventual consistency）
同样的，分布式事务也部分遵循 ACID 规范：

原子性：严格遵循
一致性：事务完成后的一致性严格遵循；事务中的一致性可适当放宽
隔离性：并行事务间不可影响；事务中间结果可见性允许安全放宽
持久性：严格遵循

分布式事务的解决方案

两阶段提交/XA

XA是由X/Open组织提出的分布式事务的规范，XA规范主要定义了(全局)事务管理器(TM)和(局部)资源管理器(RM)之间的接口。本地的数据库如mysql在XA中扮演的是RM角色

XA一共分为两阶段：

第一阶段（prepare）：即所有的参与者RM准备执行事务并锁住需要的资源。参与者ready时，向TM报告已准备就绪。
第二阶段 (commit/rollback)：当事务管理者(TM)确认所有参与者(RM)都ready后，向所有参与者发送commit命令。
目前主流的数据库基本都支持XA事务，包括mysql、oracle、sqlserver、postgre

XA 事务由一个或多个资源管理器（RM）、一个事务管理器（TM）和一个应用程序（ApplicationProgram）组成。

把上面的转账作为例子，一个成功完成的XA事务时序图如下：

image.png

如果有任何一个参与者prepare失败，那么TM会通知所有完成prepare的参与者进行回滚。

XA事务的特点是：

  • 简单易理解，开发较容易
  • 对资源进行了长时间的锁定，并发度低

如果读者想要进一步研究XA，go语言可参考DTM，java语言可参考seata

SAGA

Saga是这一篇数据库论文saga提到的一个方案。其核心思想是将长事务拆分为多个本地短事务，由Saga事务协调器协调，如果正常结束那就正常完成，如果某个步骤失败，则根据相反顺序一次调用补偿操作。

把上面的转账作为例子，一个成功完成的SAGA事务时序图如下：

image.png

SAGA事务的特点：

  • 并发度高，不用像XA事务那样长期锁定资源
  • 需要定义正常操作以及补偿操作，开发量比XA大
  • 一致性较弱，对于转账，可能发生A用户已扣款，最后转账又失败的情况

论文里面的SAGA内容较多，包括两种恢复策略，包括分支事务并发执行，我们这里的讨论，仅包括最简单的SAGA

SAGA适用的场景较多，长事务适用，对中间结果不敏感的业务场景适用

如果读者想要进一步研究SAGA，go语言可参考DTM，java语言可参考seata

TCC

关于 TCC（Try-Confirm-Cancel）的概念，最早是由 Pat Helland 于 2007 年发表的一篇名为《Life beyond Distributed Transactions:an Apostate’s Opinion》的论文提出。

TCC分为3个阶段

  • Try 阶段：尝试执行，完成所有业务检查（一致性）, 预留必须业务资源（准隔离性）
  • Confirm 阶段：确认执行真正执行业务，不作任何业务检查，只使用 Try 阶段预留的业务资源，Confirm 操作要求具备幂等设计，Confirm 失败后需要进行重试。
  • Cancel 阶段：取消执行，释放 Try 阶段预留的业务资源。Cancel 阶段的异常和 Confirm 阶段异常处理方案基本上一致，要求满足幂等设计。

把上面的转账作为例子，通常会在Try里面冻结金额，但不扣款，Confirm里面扣款，Cancel里面解冻金额，一个成功完成的TCC事务时序图如下：

image.png

TCC特点如下：

  • 并发度较高，无长期资源锁定。
  • 开发量较大，需要提供Try/Confirm/Cancel接口。
  • 一致性较好，不会发生SAGA已扣款最后又转账失败的情况
  • TCC适用于订单类业务，对中间状态有约束的业务

如果读者想要进一步研究TCC，go语言可参考DTM，java语言可参考seata

本地消息表

本地消息表这个方案最初是 ebay 架构师 Dan Pritchett 在 2008 年发表给 ACM 的文章。设计核心是将需要分布式处理的任务通过消息的方式来异步确保执行。

大致流程如下：

image.png

写本地消息和业务操作放在一个事务里，保证了业务和发消息的原子性，要么他们全都成功，要么全都失败。

容错机制：

  • 扣减余额事务 失败时，事务直接回滚，无后续步骤
  • 轮序生产消息失败， 增加余额事务失败都会进行重试

本地消息表的特点：

  • 长事务仅需要分拆成多个任务，使用简单
  • 生产者需要额外的创建消息表
  • 每个本地消息表都需要进行轮询
  • 消费者的逻辑如果无法通过重试成功，那么还需要更多的机制，来回滚操作

适用于可异步执行的业务，且后续操作无需回滚的业务

事务消息

在上述的本地消息表方案中，生产者需要额外创建消息表，还需要对本地消息表进行轮询，业务负担较重。阿里开源的RocketMQ 4.3之后的版本正式支持事务消息，该事务消息本质上是把本地消息表放到RocketMQ上，解决生产端的消息发送与本地事务执行的原子性问题。

事务消息发送及提交：

  • 发送消息（half消息）
  • 服务端存储消息，并响应消息的写入结果
  • 根据发送结果执行本地事务（如果写入失败，此时half消息对业务不可见，本地逻辑不执行）
  • 根据本地事务状态执行Commit或者Rollback（Commit操作发布消息，消息对消费者可见）

正常发送的流程图如下：

image.png

补偿流程：

对没有Commit/Rollback的事务消息（pending状态的消息），从服务端发起一次“回查”
Producer收到回查消息，返回消息对应的本地事务的状态，为Commit或者Rollback
事务消息方案与本地消息表机制非常类似，区别主要在于原先相关的本地表操作替换成了一个反查接口

事务消息特点如下：

  • 长事务仅需要分拆成多个任务，并提供一个反查接口，使用简单
  • 消费者的逻辑如果无法通过重试成功，那么还需要更多的机制，来回滚操作

适用于可异步执行的业务，且后续操作无需回滚的业务

如果读者想要进一步研究事务消息，可参考rocketmq，为了方便大家学习事务消息，DTM也提供了简单实现

最大努力通知

发起通知方通过一定的机制最大努力将业务处理结果通知到接收方。具体包括：

有一定的消息重复通知机制。因为接收通知方可能没有接收到通知，此时要有一定的机制对消息重复通知。
消息校对机制。如果尽最大努力也没有通知到接收方，或者接收方消费消息后要再次消费，此时可由接收方主动向通知方查询消息信息来满足需求。
前面介绍的的本地消息表和事务消息都属于可靠消息，与这里介绍的最大努力通知有什么不同？

可靠消息一致性，发起通知方需要保证将消息发出去，并且将消息发到接收通知方，消息的可靠性关键由发起通知方来保证。

最大努力通知，发起通知方尽最大的努力将业务处理结果通知为接收通知方，但是可能消息接收不到，此时需要接收通知方主动调用发起通知方的接口查询业务处理结果，通知的可靠性关键在接收通知方。

解决方案上，最大努力通知需要：

  • 提供接口，让接受通知放能够通过接口查询业务处理结果
  • 消息队列ACK机制，消息队列按照间隔1min、5min、10min、30min、1h、2h、5h、10h的方式，逐步拉大通知间隔 ，直到达到通知要求的时间窗口上限。之后不再通知

最大努力通知适用于业务通知类型，例如微信交易的结果，就是通过最大努力通知方式通知各个商户，既有回调通知，也有交易查询接口

AT事务模式

这是阿里开源项目seata中的一种事务模式，在蚂蚁金服也被称为FMT。优点是该事务模式使用方式，类似XA模式，业务无需编写各类补偿操作，回滚由框架自动完成，缺点也类似AT，存在较长时间的锁，不满足高并发的场景。有兴趣的同学可以参考seata-AT

分布式事务中的异常处理

在分布式事务的各个环节都有可能出现网络以及业务故障等问题，这些问题需要分布式事务的业务方做到防空回滚，幂等，防悬挂三个特性

异常情况

下面以TCC事务说明这些异常情况：

空回滚：

　　在没有调用 TCC 资源 Try 方法的情况下，调用了二阶段的 Cancel 方法，Cancel 方法需要识别出这是一个空回滚，然后直接返回成功。

　　出现原因是当一个分支事务所在服务宕机或网络异常，分支事务调用记录为失败，这个时候其实是没有执行Try阶段，当故障恢复后，分布式事务进行回滚则会调用二阶段的Cancel方法，从而形成空回滚。

幂等：

　　由于任何一个请求都可能出现网络异常，出现重复请求，所以所有的分布式事务分支，都需要保证幂等性

悬挂：

　　悬挂就是对于一个分布式事务，其二阶段 Cancel 接口比 Try 接口先执行。

　　出现原因是在 RPC 调用分支事务try时，先注册分支事务，再执行RPC调用，如果此时 RPC 调用的网络发生拥堵，RPC 超时以后，TM就会通知RM回滚该分布式事务，可能回滚完成后，RPC 请求才到达参与者真正执行。

下面看一个网络异常的时序图，更好的理解上述几种问题

image.png

业务处理请求4的时候，Cancel在Try之前执行，需要处理空回滚
业务处理请求6的时候，Cancel重复执行，需要幂等
业务处理请求8的时候，Try在Cancel后执行，需要处理悬挂

面对上述复杂的网络异常情况，目前看到各家建议的方案都是业务方通过唯一键，去查询相关联的操作是否已完成，如果已完成则直接返回成功。相关的判断逻辑较复杂，易出错，业务负担重。

子事务屏障

在项目DTM中，出现了一种子事务屏障技术，使用该技术，能够达到这个效果，看示意图：

image.png

所有这些请求，到了子事务屏障后：不正常的请求，会被过滤；正常请求，通过屏障。开发者使用子事务屏障之后，前面所说的各种异常全部被妥善处理，业务开发人员只需要关注实际的业务逻辑，负担大大降低。
子事务屏障提供了方法ThroughBarrierCall，方法的原型为：

1
go复制代码func ThroughBarrierCall(db *sql.DB, transInfo *TransInfo, busiCall BusiFunc)

业务开发人员，在busiCall里面编写自己的相关逻辑，调用该函数。ThroughBarrierCall保证，在空回滚、悬挂等场景下，busiCall不会被调用；在业务被重复调用时，有幂等控制，保证只被提交一次。

子事务屏障会管理TCC、SAGA、XA、事务消息等，也可以扩展到其他领域

子事务屏障原理

子事务屏障技术的原理是，在本地数据库，建立分支事务状态表sub_trans_barrier，唯一键为全局事务id-子事务id-子事务分支名称（try|confirm|cancel）

  • 开启事务
  • 如果是Try分支，则那么insert ignore插入gid-branchid-try，如果成功插入，则调用屏障内逻辑
  • 如果是Confirm分支，那么insert ignore插入gid-branchid-confirm，如果成功插入，则调用屏障内逻辑
  • 如果是Cancel分支，那么insert ignore插入gid-branchid-try，再插入gid-branchid-cancel，如果try未插入并且cancel插入成功，则调用屏障内逻辑
  • 屏障内逻辑返回成功，提交事务，返回成功
  • 屏障内逻辑返回错误，回滚事务，返回错误

在此机制下，解决了网络异常相关的问题

  • 空补偿控制–如果Try没有执行，直接执行了Cancel，那么Cancel插入gid-branchid-try会成功，不走屏障内的逻辑，保证了空补偿控制
  • 幂等控制–任何一个分支都无法重复插入唯一键，保证了不会重复执行
  • 防悬挂控制–Try在Cancel之后执行，那么插入的gid-branchid-try不成功，就不执行，保证了防悬挂控制

对于SAGA事务，也是类似的机制。

子事务屏障小结

子事务屏障技术，为DTM首创，它的意义在于设计简单易实现的算法，提供了简单易用的接口，在首创，它的意义在于设计简单易实现的算法，提供了简单易用的接口，在这两项的帮助下，开发人员彻底的从网络异常的处理中解放出来。

该技术目前需要搭配DTM事务管理器，目前SDK已经提供给go语言的开发者。其他语言的sdk正在规划中。对于其他的分布式事务框架，只要提供了合适的分布式事务信息，能够按照上述原理，快速实现该技术。

总结

本文介绍了分布式事务的一些基础理论，并对常用的分布式事务方案进行了讲解，在文章的后半部分还给出了事务异常的原因、分类以及优雅的解决方案。

dtm支持了TCC、XA、SAGA、事务消息、最大努力通知（使用事务消息实现），提供了简洁易用的接入。欢迎大家访问dtm项目，给颗星星支持！

本文转载自: 掘金

开发者博客 – 和开发相关的 这里全都有

发表于

依托于互联网的发达，我们可以随时随地利用一些等车或坐地铁的碎片时间学习以及了解资讯。同时发达的互联网也方便人们能够快速分享自己的知识，与相同爱好和需求的朋友们一起共同讨论。

但是过于方便的分享也让知识变得五花八门，很容易让人接收到错误的信息。这些错误最多的都是因为技术发展迅速，而且没有空闲时间去及时更新已经发布的内容所导致。为了避免给后面学习的人造成误解，我们今天来看一看 MySQL 设计规范中几个常见的错误例子。

主键的设计

错误的设计规范：主键建议使用自增 ID 值，不要使用 UUID，MD5，HASH，字符串作为主键

这个设计规范在很多文章中都能看到，自增主键的优点有占用空间小，有序，使用起来简单等优点。

下面先来看看自增主键的缺点：

  • 自增值由于在服务器端产生，需要有一把自增的 AI 锁保护，若这时有大量的插入请求，就可能存在自增引起的性能瓶颈，所以存在并发性能问题；
  • 自增值做主键，只能在当前实例中保证唯一，不能保证全局唯一，这就导致无法在分布式架构中使用；
  • 公开数据值，容易引发安全问题，如果我们的商品 ID 是自增主键的话，用户可以通过修改 ID 值来获取商品，严重的情况下可以知道我们数据库中一共存了多少商品。
  • MGR（MySQL Group Replication） 可能引起的性能问题；

因为自增值是在 MySQL 服务端产生的值，需要有一把自增的 AI 锁保护，若这时有大量的插入请求，就可能存在自增引起的性能瓶颈。比如在 MySQL 数据库中，参数 innodb_autoinc_lock_mode 用于控制自增锁持有的时间。虽然，我们可以调整参数 innodb_autoinc_lock_mode 获得自增的最大性能，但是由于其还存在其它问题。因此，在并发场景中，更推荐 UUID 做主键或业务自定义生成主键。

我们可以直接在 MySQ L使用 UUID() 函数来获取 UUID 的值。

1
2
3
4
5
6
7
sql复制代码MySQL> select UUID();
+--------------------------------------+
| UUID()                               |
+--------------------------------------+
| 23ebaa88-ce89-11eb-b431-0242ac110002 |
+--------------------------------------+
1 row in set (0.00 sec)

需要特别注意的是，在存储时间时，UUID 是根据时间位逆序存储， 也就是低时间低位存放在最前面，高时间位在最后，即 UUID 的前 4 个字节会随着时间的变化而不断“随机”变化，并非单调递增。而非随机值在插入时会产生离散 IO，从而产生性能瓶颈。这也是 UUID 对比自增值最大的弊端。

为了解决这个问题，MySQL 8.0 推出了函数 UUID_TO_BIN，它可以把 UUID 字符串：

  • 通过参数将时间高位放在最前，解决了 UUID 插入时乱序问题；
  • 去掉了无用的字符串”-“，精简存储空间；
  • 将字符串其转换为二进制值存储，空间最终从之前的 36 个字节缩短为了 16 字节。

下面我们将之前的 UUID 字符串 23ebaa88-ce89-11eb-b431-0242ac110002 通过函数 UUID_TO_BIN 进行转换，得到二进制值如下所示：

1
2
3
4
5
6
7
sql复制代码MySQL> SELECT UUID_TO_BIN('23ebaa88-ce89-11eb-b431-0242ac110002',TRUE) as UUID_BIN;
+------------------------------------+
| UUID_BIN                           |
+------------------------------------+
| 0x11EBCE8923EBAA88B4310242AC110002 |
+------------------------------------+
1 row in set (0.01 sec)

除此之外，MySQL 8.0 也提供了函数 BIN_TO_UUID，支持将二进制值反转为 UUID 字符串。

虽然 MySQL 8.0 版本之前没有函数 UUID_TO_BIN/BIN_TO_UUID，还是可以通过自定义函数的方式解决。应用层的话可以根据自己的编程语言编写相应的函数。

当然，很多同学也担心 UUID 的性能和存储占用的空间问题，这里我也做了相关的插入性能测试，结果如下表所示：

可以看到，MySQL 8.0 提供的排序 UUID 性能最好，甚至比自增 ID 还要好。此外，由于 UUID_TO_BIN 转换为的结果是16 字节，仅比自增 ID 增加 8 个字节，最后存储占用的空间也仅比自增大了 3G。

而且由于 UUID 能保证全局唯一，因此使用 UUID 的收益远远大于自增 ID。可能你已经习惯了用自增做主键，但是在并发场景下，更推荐 UUID 这样的全局唯一值做主键。

当然了，UUID虽好，但是在分布式场景下，主键还需要加入一些额外的信息，这样才能保证后续二级索引的查询效率，推荐根据业务自定义生成主键。但是在并发量和数据量没那么大的情况下，还是推荐使用自增 UUID 的。大家更不要以为 UUID 不能当主键了。

金融字段的设计

错误的设计规范：同财务相关的金额类数据必须使用 decimal 类型 由于 float 和 double 都是非精准的浮点数类型，而 decimal 是精准的浮点数类型。所以一般在设计用户余额，商品价格等金融类字段一般都是使用 decimal 类型，可以精确到分。

但是在海量互联网业务的设计标准中，并不推荐用 DECIMAL 类型，而是更推荐将 DECIMAL 转化为整型类型。 也就是说，金融类型更推荐使用用分单位存储，而不是用元单位存储。如1元在数据库中用整型类型 100 存储。

下面是 bigint 类型的优点：

  • decimal 是通过二进制实现的一种编码方式，计算效率不如 bigint
  • 使用 bigint 的话，字段是定长字段，存储高效，而 decimal 根据定义的宽度决定，在数据设计中，定长存储性能更好
  • 使用 bigint 存储分为单位的金额，也可以存储千兆级别的金额，完全够用

枚举字段的使用

错误的设计规范：避免使用 ENUM 类型

在以前开发项目中，遇到用户性别，商品是否上架，评论是否隐藏等字段的时候，都是简单的将字段设计为 tinyint，然后在字段里备注 0 为什么状态，1 为什么状态。

这样设计的问题也比较明显：

  • 表达不清：这个表可能是其他同事设计的，你印象不是特别深的话，每次都需要去看字段注释，甚至有时候在编码的时候需要去数据库确认字段含义
  • 脏数据：虽然在应用层可以通过代码限制插入的数值，但是还是可以通过sql和可视化工具修改值

这种固定选项值的字段，推荐使用 ENUM 枚举字符串类型，外加 SQL_MODE 的严格模式

在MySQL 8.0.16 以后的版本，可以直接使用check约束机制，不需要使用enum枚举字段类型

而且我们一般在定义枚举值的时候使用”Y”,”N”等单个字符，并不会占用很多空间。但是如果选项值不固定的情况，随着业务发展可能会增加，才不推荐使用枚举字段。

索引个数限制

错误的设计规范：限制每张表上的索引数量，一张表的索引不能超过 5 个

MySQL 单表的索引没有个数限制，业务查询有具体需要，创建即可，不要迷信个数限制

子查询的使用

错误的设计规范：避免使用子查询

其实这个规范对老版本的 MySQL 来说是对的，因为之前版本的 MySQL 数据库对子查询优化有限，所以很多 OLTP 业务场合下，我们都要求在线业务尽可能不用子查询。

然而，MySQL 8.0 版本中，子查询的优化得到大幅提升，所以在新版本的MySQL中可以放心的使用子查询。

子查询相比 JOIN 更易于人类理解，比如我们现在想查看2020年没有发过文章的同学的数量

1
2
3
4
5
6
7
sql复制代码SELECT COUNT(*)
FROM user
WHERE id not in (
    SELECT user_id
    from blog
    where publish_time >= "2020-01-01" AND  publish_time <= "2020-12-31"
)

可以看到，子查询的逻辑非常清晰：通过 not IN 查询文章表的用户有哪些。

如果用 left join 写

1
2
3
4
sql复制代码SELECT count(*)
FROM user LEFT JOIN blog
ON user.id = blog.user_id and blog.publish_time >= "2020-01-01" and blog.publish_time <= "2020-12-31"
where blog.user_id is NULL;

可以发现，虽然 LEFT JOIN 也能完成上述需求，但不容易理解。

我们使用 explain查看两条 sql 的执行计划，发现都是一样的

通过上图可以很明显看到，不论是子查询还是 LEFT JOIN，最终都被转换成了left hash Join，所以上述两条 SQL 的执行时间是一样的。即，在 MySQL 8.0 中，优化器会自动地将 IN 子查询优化，优化为最佳的 JOIN 执行计划，这样一来，会显著的提升性能。

总结

阅读完前面的内容相信大家对 MySQL 已经有了新的认知，这些常见的错误可以总结为以下几点：

  • UUID 也可以当主键，自增 UUID 比自增主键性能更好，多占用的空间也可忽略不计
  • 金融字段除了 decimal，也可以试试 bigint，存储分为单位的数据
  • 对于固定选项值的字段，MySQL8 以前推荐使用枚举字段，MySQL8 以后使用check函数约束，不要使用 0，1，2 表示
  • 一张表的索引个数并没有限制不能超过5个，可以根据业务情况添加和删除
  • MySQL8 对子查询有了优化，可以放心使用。

推荐阅读

实操笔记：为 NSQ 配置监控服务的心路历程

go-zero：开箱即用的微服务框架

本文转载自: 掘金

开发者博客 – 和开发相关的 这里全都有

0%