Java面试题笔笔记之数据库

初出茅庐,Java小白寻求Offer序列

事务

事务四大特征?

原子性,一致性,隔离性和持久性(ACID)

  1. 原子性(Atomicity)

    一个原子事务要么完整执行,要么干脆不执行。这意味着,工作单元中的每项任务都必须正确执行。如果有任一任务执行失败,则整个工作单元或事务就会被终止。即此前对数据所作的任何修改都将被撤销。如果所有任务都被成功执行,事务就会被提交,即对数据所作的修改将会是永久性的。

  2. 一致性(Consistency)

    一致性代表了底层数据存储的完整性。它必须由事务系统和应用开发人员共同来保证。事务系统通过保证事务的原子性,隔离性和持久性来满足这一要求; 应用开发人员则需要保证数据库有适当的约束(主键,引用完整性等),并且工作单元中所实现的业务逻辑不会导致数据的不一致(即,数据预期所表达的现实业务情况不相一致)。

  3. 隔离性(Isolation)

    隔离性意味着事务必须在不干扰其他进程或事务的前提下独立执行。换言之,在事务或工作单元执行完毕之前,其所访问的数据不能受系统其他部分的影响。

  4. 持久性(Durability)

    持久性表示在某个事务的执行过程中,对数据所作的所有改动都必须在事务成功结束前保存至某种物理存储设备。这样可以保证,所作的修改在任何系统瘫痪时不至于丢失。

Mysql的事物隔离级别?

Mysql的事物隔离级别其实跟 Spring的事物隔离级别一样,都是

  • Read Uncommitted(读取未提交内容),也就是脏读 ,读取未提交事务的执行结果。
  • Read Committed(读取提交内容),大多数数据库系统的默认隔离级别(但不是MySQL默认的)。
  • Repeatable Read(可重读),这是MySQL的默认事务隔离级别,它确保同一事务的多个实例在并发读取数据时,会看到同样的数据行。重点是行数。
  • Serializable(可串行化),这是最高的隔离级别,它通过强制事务排序,使之不可能相互冲突,从而解决幻读问题。简言之,它是在每个读的数据行上加上共享锁。在这个级别,可能导致大量的超时现象和锁竞争。

脏读:读取未事务提交的数据,也被称之为脏读(Dirty Read)。

不可重复读:在一个事务的两次查询之中数据不一致,这可能是两次查询过程中间插入了一个事务更新的原有的数据。

幻读:指当用户读取某一范围的数据行时,另一个事务又在该范围内插入了新行,当用户再读取该范围的数据行时,会发现有新的“幻影” 行。

范式

第一范式:具有原子性

第二范式:主键列与非主键列遵循完全函数依赖关系

第三范式:非主键列之间没有传递函数依赖关系

  • 第一范式(确保每列保持原子性)

    第一范式是最基本的范式。如果数据库表中的所有字段值都是不可分解的原子值,就说明该数据库表满足了第一范式。

    所谓第一范式(1NF)是指数据库表的每一列都是不可分割的基本数据项,同一列中不能有多个值,即实体中的某个属性不能有多个值或者不能有重复的属性。如果出现重复的属性,就可能需要定义一个新的实体,新的实体由重复的属性构成,新实体与原实体之间为一对多关系。

  • 第二范式(确保表中的每列都和主键相关)

    第二范式在第一范式的基础之上更进一层。第二范式需要确保数据库表中的每一列都和主键相关,而不能只与主键的某一部分相关(主要针对联合主键而言)。也就是说在一个数据库表中,一个表中只能保存一种数据,不可以把多种数据保存在同一张数据库表中。

  • 第三范式(确保数据表中的每一列数据都和主键直接相关,而不能间接相关)

    比如在设计一个订单数据表的时候,可以将客户编号作为一个外键和订单表建立相应的关系。而不可以在订单表中添加关于客户其它信息(比如姓名、所属公司等)的字段。如下面这两个表所示的设计就是一个满足第三范式的数据库表。

一分钟教你知道乐观锁和悲观锁的区别

悲观锁(Pessimistic Lock), 顾名思义,就是很悲观,每次去拿数据的时候都认为别人会修改,所以每次在拿数据的时候都会上锁,这样别人想拿这个数据就会block直到它拿到锁。传统的关系型数据库里边就用到了很多这种锁机制,比如行锁,表锁等,读锁,写锁等,都是在做操作之前先上锁。

乐观锁(Optimistic Lock), 顾名思义,就是很乐观,每次去拿数据的时候都认为别人不会修改,所以不会上锁,但是在更新的时候会判断一下在此期间别人有没有去更新这个数据,可以使用版本号等机制。乐观锁适用于多读的应用类型,这样可以提高吞吐量,像数据库如果提供类似于write_condition机制的其实都是提供的乐观锁。

两种锁各有优缺点,不可认为一种好于另一种,像乐观锁适用于写比较少的情况下,即冲突真的很少发生的时候,这样可以省去了锁的开销,加大了系统的整个吞吐量。但如果经常产生冲突,上层应用会不断的进行retry,这样反倒是降低了性能,所以这种情况下用悲观锁就比较合适。

有哪些锁,select时怎么加?

  • 排它锁
  • 乐观锁,自己实现,通过版本号
  • 悲观锁:共享锁,多个事务,只能读不能写,加 lock in share mode
  • 排它锁,一个事务,只能写,for update
  • 行锁
  • 表锁

    死锁怎么解决 ?

找到进程号,kill 进程

优化

一条sql执行过长的时间,你如何优化,从哪些方面?

  • 查看sql是否涉及多表的联表或者子查询,如果有,看是否能进行业务拆分,相关字段冗余或者合并成临时表(业务和算法的优化)
  • 涉及连表的查询,是否能进行分表查询,单表查询之后的结果进行字段整合
  • 如果以上两种都不能操作,非要连表查询,那么考虑对相对应的查询条件做索引,加快查询速度。
  • 针对数量大的表进行历史表分离(如交易流水表)
  • 数据库主从分离,读写分离,降低读写针对同一表同时的压力,至于主从同步,mysql有自带的binlog实现主从同步。
  • explain分析sql语句,查看执行计划,分析索引是否用上,分析扫描行数等等。
  • 查看mysql执行日志,看看是否有其他方面的问题

感谢

整理本文时参考了以下文章,非常感谢大佬们的分享: