xxx
This commit is contained in:
27
src/content/posts/Redis大Key问题.md
Normal file
27
src/content/posts/Redis大Key问题.md
Normal file
@@ -0,0 +1,27 @@
|
|||||||
|
---
|
||||||
|
title: Redis大Key问题
|
||||||
|
published: 2025-09-15
|
||||||
|
description: ''
|
||||||
|
image: ''
|
||||||
|
tags: ['中间件','Redis','大Key']
|
||||||
|
category: '中间件 > Redis'
|
||||||
|
draft: false
|
||||||
|
lang: ''
|
||||||
|
---
|
||||||
|
Redis中的 big key指一个内存空间占用比较大的键,它有什么危害?
|
||||||
|
- 内存分布不均,集群模式下,不同slot分配到不同实例中,如果大key被映射到同一个实例,那么分布不均,查询效率也会受到影响。
|
||||||
|
- Redis单线程执行命令,操作大Key的时候耗时比较长,会导致Redis出现其他命令 阻塞的问题。
|
||||||
|
- 大key对资源占用很大,在进行网络I/O传输的时候,导致获取过程中产生的网络流量较大,从而产生网络传输时间延长甚至网络传输发生阻塞现象。
|
||||||
|
- 客户端超时,因为操作大key时的时耗比较长,所以可能导致客户端超时。
|
||||||
|
|
||||||
|
|
||||||
|
如何解决大Key问题?
|
||||||
|
- 开发方面,对要存储的数据进行压缩,压缩之后再存储。
|
||||||
|
- 大化小,大对象拆分成小对象。把一个大Key拆分成若干小key,降低单个Key的内存大小。
|
||||||
|
- 使用合适的数据结构进行存储,比如一些用String存储的场景,可以考虑用Hash,Set等结构进行优化
|
||||||
|
|
||||||
|
业务层面:
|
||||||
|
根据实际情况,调整存储策略,不要把不必要的信息存储到里面
|
||||||
|
|
||||||
|
数据分布方面
|
||||||
|
- 采用Redis集群方式进行Redis的部署,然后把大Key拆分散落到不同的服务器上面,加快响应速度。
|
||||||
30
src/content/posts/中间件/MySQL/MySQL联合索引失效情况.md
Normal file
30
src/content/posts/中间件/MySQL/MySQL联合索引失效情况.md
Normal file
@@ -0,0 +1,30 @@
|
|||||||
|
---
|
||||||
|
title: MySQL联合索引失效情况
|
||||||
|
published: 2025-09-15
|
||||||
|
description: ''
|
||||||
|
image: ''
|
||||||
|
tags: ['MySQL','联合索引']
|
||||||
|
category: '中间件 > MySQL'
|
||||||
|
draft: false
|
||||||
|
lang: ''
|
||||||
|
---
|
||||||
|
|
||||||
|
# MySQL联合索引失效情况
|
||||||
|
|
||||||
|
|
||||||
|
## 1. 不满足最左匹配原则
|
||||||
|
|
||||||
|
## 2. 在索引上使用函数或者运算
|
||||||
|
|
||||||
|
## 3. 索引列参与隐式类型转换
|
||||||
|
|
||||||
|
## 4. 使用NOT IN,!=,<>等否定操作符
|
||||||
|
|
||||||
|
## 5. 模糊匹配 like %xxx%
|
||||||
|
|
||||||
|
## 6.OR操作符
|
||||||
|
如果在Where子句中使用了OR操作符,并且OR前的条件列是索引列,OR后的不是索引列,那么索引可能会失效。
|
||||||
|
|
||||||
|
## 7. 使用 not exists关键字,索引也会失效(本质上是Where查询范围太大)
|
||||||
|
|
||||||
|
## 8. 使用Order By 注意最左匹配,要加limit或者Where关键字,否则索引会失效
|
||||||
Reference in New Issue
Block a user