数据库面试题及优化手段

1..尽量避免大事务操作，提高系统并发能力。

 

2.大事务

1.定义：运行时间比较长，操作的数据比较多的事务

2.大事务风险：

a)锁定太多的数据，造成大量的阻塞和锁超时，回滚所需要的时间比较长。

b)执行时间长，容易造成主从延迟

3.如何处理大事务

a)避免一次处理太多大数据

b)移出不必要在事务中的select操作

 

3.什么是主从复制？（引入主从复制数据会有延迟）

主从复制，是用来建立一个和主数据库完全一样的数据库环境，称为从数据库；主数据库一般是准实时的业务数据库。

 

4.主从复制的作用？

1:做数据的热备，作为后备数据库，主数据库服务器故障后，可切换从数据库继续工作，避免数据丢失。

2：架构的扩展。业务量越来越大，I/O访问频率过高，单机无法满足，此时做多库的存储，降低磁盘访问的频率，提高单个机器的性能。

3：读写分离，使数据库能支撑更大的并发。在报表中尤其重要。由于部分报表sql语句非常的慢，导致锁表，影响前台服务。如果前台使用master，报表使用slave，那么报表sql将不会造成前台锁，保证了前台速度。

4.主从复制的原理：

1.数据库有个bin-log二进制文件，记录了所有sql语句。

2.我们的目标就是把主数据库的bin-log文件的sql语句复制过来。

3.让其在从数据的relay-log重做日志文件中再执行一次这些sql语句即可。

 

5.什么是读写分离（写主，读从）

读写分离就是主从集群，一主多从，或者一主一从，就是根据数据库主机复制写入操作，从机负责读的操作，主机写入以后在同步给从机。基本原理就是将数据库的读写操作分配到不同的节点，根据主从复制集群的特性进行扩展开发。

 

6.从代码层了解实现的思路？

明确一点，那就是读的时候用从库，写的时候用主库，这一点是重中之重，这就是需求，根据这个需求去演化我们的代码，无非就是用两个或者多个数据源DataScoure，一个主的数据源DataScoure，另外一个是一个或者多个从的数据源DataScoure。

1，通过两份ORM去操作；

2，采用AOP的方式去实现

 

7.读写分离带来的问题以及我们自己的思考？(会引入程序的复杂性)

读写分离以后，我们数据库同步数据的时候，会存在延迟的问题，这个延迟是数据量的增加延迟也会越来越久，但是有些业务是要求实时，我们该如何去处理这个问题。

举个例子，就按照登录来说，假设在某个网站上注册一个账号，该网站注册这个业务采用的是读写分离的设计，这个时候我们在注册完成后，需要立即登录，这个时候登录不上，因为这个时候做登录的时候访问不到该注册信息，就会提示用户不存在，延迟在2-3之间。

处理方式：如果业务没有要求必须实时，一般提倡忽略这种问题，避免带来程序的复杂性，如果提了可以从两个方面来处理。

后端读取方面 || 用户体验感方面

1，数据库层面：数据库层面可以采用暴力读取也就是一次读取主机的方法，什么是读取主机，比如说我们的登录操作，如果从从库读取不到，我们再次读取主机看该数据是否存在，这样主机压力很大，可能导致主机崩溃，因为库里有海量数据的用户，就会增加频繁的DB读写。

2，从界面层面：还是以登录为例，我们在很多网站注册完成后，会出现这样的情况，比如等待几秒跳转或者阅读下什么规则，这个时候我们考虑下为什么他要这么做，当然一部分可能是真的规定，但有时候等待几秒的跳转的动画，这个时候主从已经完成了同步。

 

注*：读写分离不是银弹，并不是一有性能问题就上读写分离，而是应该先优化，例如优化慢查询，调整不合理的业务逻辑，引入缓存查询等只有确定系统没有优化空间后才考虑读写分离集群！（数据库的架构方面--先是主从复制 → 读写分离（写从读主） → 分库分表（对读的一方进行分表策略）在这些基础上一路慢慢的建立扩展起来）

 

8.数据库索引失效的场景；

1，like未使用最左前缀，where A like '%China'；

2，搜索一个索引而在另一个索引上做order by，where A=a order by B，只使用A上的索引，因为查询只使用一个索引

3，or会使索引失效。如果查询字段相同，也可以使用索引。例如where A=a1 or A=a2（生效），where A=a or B=b（失效）。

4，在索引列上的操作，函数（upper()等）、or、！=(<>)、not in等

5，对索引列进行运算导致索引失效，我所指的对索引进行运算包括

6，不要将空的变量值直接与比较运算符（符号）比较。

7, delete