Redis

说一下 Redis以及Redis 使用场景

答：Redis 是一种基于内存的数据库，对数据的读写操作都是在内存中完成，因此读写速度非常快，常用于缓存，消息队列、分布式锁等场景。

Redis 设置过期时间的命令

# 设置 key 在 60 秒后过期（该方法是针对已经存在的key设置过期时间）一般不常用
expire key 60
# setex key 时间 value--设置key = name value = lisi ，60秒过期
setex name 60 lisi 
set name lisi ex 60

分布式锁

答：Redis中可以用setnx设计分布式锁，为什么呢？因为setnx key value 只有当key不存在时候才会建立。但是在实际中常常如下命令创建分布式锁。

set key value nx ex 时间

为什么是这样呢？

• 我们想一下，nx表示当键不存在时候才会创建，如果有线程1已经创建了锁，那么线程2，或者线程3执行这个命令就会失败。因此会获得不到锁对象。
• 设置锁过期时间是防止锁没有及时释放，其他线程或系统获取不到锁。

设计锁时要注意一些问题：

第一这个value是全局唯一的。是为了防止误删现象。

• 假如有线程1，获取了锁对象，在执行业务时被阻塞了，此时锁的时间过期了。
• 那么线程2 就可以获取锁对象，此时，线程1完成业务，（如果value不是全局唯一）那么线程1直接将锁释放，后来线程3，线程4。。就可以并发执行出现并发安全问题。
• 因此，我们设置全局唯一value值，在释放锁时要判断value值是不是自己的然后才进行释放。

第二锁释放要设置为原子性操作。为什么要这样呢？

如下图代码所示：判断value值是否是自己的，然后才进行锁释放操作。

public void unlock() {// 获取线程标示String threadId = ID_PREFIX + Thread.currentThread().getId();// 获取锁中的标示String id = stringRedisTemplate.opsForValue().get(KEY_PREFIX + name);// 判断标示是否一致if(threadId.equals(id)) {// 释放锁stringRedisTemplate.delete(KEY_PREFIX + name);}

 因此要采用Lua脚本实现原子操作。

-- 这里的 KEYS[1] 就是锁的key，这里的ARGV[1] 就是当前线程标示
-- 获取锁中的标示，判断是否与当前线程标示一致
if (redis.call('GET', KEYS[1]) == ARGV[1]) then-- 一致，则删除锁return redis.call('DEL', KEYS[1])
end
-- 不一致，则直接返回
return 0

具体请看黑马点评项目Redis实现分布式锁_兜兜转转m的博客-CSDN博客

业务里 redis 的过期策略设置

你的 redis 的使用场景

dis 的淘汰策略

你的使用场景 redis 宕机了怎么办

MySQL

Mysql 查询（出生日期，性别）在表（id，性别，年龄，出生日期）中怎么设置索引。

mysql 索引怎么选择？索引的优缺点？还有什么缺点 或者讲一下索引的你的理解

索引失效的场景、场景题的索引设计

这两个题是一个类型题，我就一起说了。

出生日期是非唯一索引，性别只有：男，女，其区分度不高，因此我们最不好不对其建立索引。

答：一般常用在where, orderby, group by字段进行索引设置，我们常见的索引一般是，主键索引，唯一索引和普通索引，其优点在于提升数据库对数据的查询速度，缺点是占用存储空间，而且会影响insert，update，delete的速度。但是索引并不是简简单单设置一下就好了，它也有相应的使用规则，否则其失效。

• 要遵循最左前缀法则，否则会索引会失效
• 在条件判断时索引字段不能作为函数的参数
• 索引字段不能进行类型转换。
• 使用<>查询是后面索引会失效。
• 当索引列模糊查询进行模糊头查询时。
• 在联合索引下，遵循最左前缀准则，而且不能跳过，如果跳过会引起部分索引失效。
• or连接条件：用or分割开的条件， 如果or前的条件中的列有索引，而后面的列中没有索引，那么涉及的索引都不会 被用到
• 数据查询分布不均匀时

具体参考MySQL进阶-索引生效和设计的原则总结_兜兜转转m的博客-CSDN博客​​​​​​​

sql 事务的特性？什么是持久性

答：事务的特性主要有4个，也是我们常说的ACID，对应的是原子性，一致性，隔离性和持久性。

持久性：表示在某个事务的执行过程中，对数据所作的所有改动都必须在事务成功结束前保存至某种物理存储设备。

持久性的实现主要是通过redo log保证的。

redo log是Innodb引擎特有的，其主要分为日志缓存区和日志文件两部分组成，前部分是在于内存中后部分在于磁盘中。它记录的是一条更新操作所做的修改，其修改的数据都会存放在日志缓存区中，当事务提交时将redolog中的数据刷入磁盘中。

MyISAM 与 InnoDB 的区别

数据库隔离级别

答：MySQL的隔离级别主要有4个，读未提交，读已提交，可重复读，串行读等。

读已提交可以解决脏读问题，可重复读可以解决不可重复读问题，串行读可以解决幻读问题。

• “脏读”指读到了未提交的数据，然后基于这个数据做了一些事情，结果做完发现数据被回滚了。
• 不可重复读问题是，首先我们读取一条数据，然后我们再次读取这条数据时发现改数据已经被修改了(侧重点在修改)。
• 幻读：当某个事务在读取某个范围内的记录时，另一个事务又在该记录插入了新数据，当前事务再次读取这个范围的记录，会产生幻读行。

oss 数据库与 mysql 数据库不一致怎么解决

同一条 sql，不同规模数据会走同一条索引吗

答：不会，因为索引的失效原因有一条是：数据查询分布不均匀会导致索引失效。

为何会这样呢？因为MySQL优化器会评估使用索引的效率与走全表扫描的效率，如果走全表扫描更快，则放弃索引，走全表扫描。

索引是用来索引少量数据的，如果通过索引查询返回大批量的数据，则还不 如走全表扫描来的快，此时索引就会失效。

select * from tb_user where phone >= '17799990005';
select * from tb_user where phone >= '17799990015';

mySQL 死锁怎么解决？mySQL 不能解决死锁的原因

死锁如何发生呢？

假设这时有两事务，一个事务要插入订单 1007 ，另外一个事务要插入订单 1008，因为需要对订单做幂等性校验，所以两个事务先要查询该订单是否存在，不存在才插入记录，过程如下：

两个临键锁相互锁住了对方，都在等对方释放。可以看到，两个事务都陷入了等待状态（前提没有打开死锁检测），也就是发生了死锁，因为都在相互等待对方释放锁。

 因为当我们执行以下插入语句时，会在插入间隙上获取插入意向写锁，而插入意向锁与间隙锁是冲突的，所以当其它事务持有该间隙的间隙锁时，需要等待其它事务释放间隙锁之后，才能获取到插入意向锁。而间隙锁与间隙锁之间是兼容的，所以所以两个事务中 select ... for update 语句并不会相互影响。

如何避免死锁？

死锁的四个必要条件：互斥、占有且等待、不可强占用、循环等待。只要系统发生死锁，这些条件必然成立，但是只要破坏任意一个条件就死锁就不会成立。

• 设置事务等待锁的超时时间：一个事务的等待时间超过该值后，就对这个事务进行回滚，于是锁就释放了，另一个事务就可以继续执行了
• 开启主动死锁检测。主动死锁检测在发现死锁后，主动回滚死锁链条中的某一个事务，让其他事务得以继续执行。将参数 innodb_deadlock_detect 设置为 on，表示开启这个逻辑，默认就开启

参考：

MySQL 死锁了，怎么办？ | 小林coding

慢 sql 优化

1、先检测出慢sql。

2、分析因为什么慢

具体：针对insert，order by，limit，update，conut，group by

MySQL进阶-SQL优化_兜兜转转m的博客-CSDN博客 

综合问题

如何保证数据库和Redis的一致性问题。