Java开发校招面试考点汇总第六篇：数据库及MySQL练习题

1、关系型数据库
2、什么是NoSql（非关系型数据库）
3、nosql和关系型数据库比较
4、redis
5、● 请问redis的List能在什么场景下使用？
6、redis持久化
7、● 请分别介绍一下aof和rdb都有哪些优点？以及两者有何区别？
8、● 请问，redis为什么是单线程？
9、● 简单说一说，缓存的优点是什么？
10、● 请问，为什么 redis 读写速率快、性能好？
11、● 说一说，MVC的各个部分都有那些技术来实现?如何实现?
12、事务的基本要素（ACID）
13、事务的并发问题
14、MySQL事务隔离级别
15、有哪些锁？介绍一下
16、什么是死锁？怎么解决？
17、什么是数据库连接池？
18、介绍索引
19、怎样对数据库进行优化
20、数据库索引了解吗
21、说说自己对于 MySQL 常见的两种存储引擎：MyISAM与InnoDB的理解
22、视图的作用，视图可以更改么？
23、对于大表的常见优化手段说一下
24、drop,delete与truncate的区别
25、范式
26、强一致性、弱一致性、最终一致性
27、JDBC连接数据库的步骤
28、● 请你说明一下 left join 和 right join 的区别？
29、● 请你讲讲 Statement 和 PreparedStatement 的区别？哪个性能更好？
30、● 请你谈谈JDBC的反射，以及它的作用？
31、游标
32、mysql存储过程

练习题见链接：
https://blog.csdn.net/u014138443/article/details/90294093
详细redis内容见：
https://blog.csdn.net/u014138443/article/details/90294052

1、关系型数据库
关系型数据库，是指采用了关系模型来组织数据的数据库。
简单来说，关系模型指的就是二维表格模型，而一个关系型数据库就是由二维表及其之间的联系所组成的一个数据组织。

关系型数据库的优点：
容易理解：二维表结构是非常贴近逻辑世界的一个概念，关系模型相对网状、层次等其他模型来说更容易理解
使用方便：通用的SQL语言使得操作关系型数据库非常方便
易于维护：丰富的完整性(实体完整性、参照完整性和用户定义的完整性)大大减低了数据冗余和数据不一致的概率
关系型数据库的瓶颈
1).高并发读写需求
网站的用户并发性非常高，往往达到每秒上万次读写请求，对于传统关系型数据库来说，硬盘I/O是一个很大的瓶颈
2).海量数据的高效率读写
网站每天产生的数据量是巨大的，对于关系型数据库来说，在一张包含海量数据的表中查询，效率是非常低的
3).高扩展性和可用性
在基于web的结构当中，数据库是最难进行横向扩展的，当一个应用系统的用户量和访问量与日俱增的时候，数据库却没有办法像web server和app server那样简单的通过添加更多的硬件和服务节点来扩展性能和负载能力。对于很多需要提供24小时不间断服务的网站来说，对数据库系统进行升级和扩展是非常痛苦的事情，往往需要停机维护和数据迁移。

2、什么是NoSql（非关系型数据库）
NoSql（Not Only SQL）
非关系型数据库提出另一种理念，例如,以键值对存储，且结构不固定，每一个元组可以有不一样的字段，每个元组可以根据需要增加一些自己的键值对，这样就不会局限于固定的结构，可以减少一些时间和空间的开销。使用这种方式，用户可以根据需要去添加自己需要的字段，这样，为了获取用户的不同信息，不需要像关系型数据库中，要对多表进行关联查询。仅需要根据id取出相应的value就可以完成查询。但非关系型数据库由于很少的约束，他也不能够提供像SQL所提供的where这种对于字段属性值情况的查询。并且难以体现设计的完整性。他只适合存储一些较为简单的数据，对于需要进行较复杂查询的数据，SQL数据库显的更为合适。

3、nosql和关系型数据库比较
1）成本：nosql数据库简单易部署，基本都是开源软件，不需要像使用oracle那样花费大量成本购买使用，相比关系型数据库价格便宜。
2）查询速度：nosql数据库将数据存储于缓存之中，关系型数据库将数据存储在硬盘中，自然查询速度远不及nosql数据库。
3）存储数据的格式：nosql的存储格式是key,value形式、文档形式、图片形式等等，所以可以存储基础类型以及对象或者是集合等各种格式，而数据库则只支持基础类型。
4）扩展性：关系型数据库有类似join这样的多表查询机制的限制导致扩展很艰难。
5）nosql不适合复杂查询，复杂查询需要用sql数据库

4、redis
redis是一种高级的key-value的存储系统，是一种nosql数据库
其中的key是字符串类型，尽可能满足如下几点：
1）key不要太长，最好不要操作1024个字节，这不仅会消耗内存还会降低查找 效率
2）key不要太短，如果太短会降低key的可读性
3）在项目中，key最好有一个统一的命名规范（根据企业的需求）
其中value 支持五种数据类型：
1）字符串型 string
2）字符串列表 lists
3）字符串集合 sets
4）有序字符串集合 sorted sets
5）哈希类型 hashs

5、● 请问redis的List能在什么场景下使用？
Redis 中list的数据结构实现是双向链表，所以可以非常便捷的应用于消息队列（生产者 / 消费者模型）。消息的生产者只需要通过lpush将消息放入 list，消费者便可以通过rpop取出该消息，并且可以保证消息的有序性。如果需要实现带有优先级的消息队列也可以选择sorted set。而pub/sub功能也可以用作发布者 / 订阅者模型的消息。

6、redis持久化
redis的高性能是由于其将所有数据存储在内存中，为了使redis在重启后仍能保证数据不丢失，需要将数据从内存中同步到硬盘中，这一过程就是持久化。
redis支持两种方式的持久化，一种是RDB方式，一种是AOF方式。

7、● 请分别介绍一下aof和rdb都有哪些优点？以及两者有何区别？

1、RDB持久化：
把当前内存中的数据集快照写入磁盘（快照其实就是将数据复制一份）。
RDB 的优点:

RDB 是一个非常紧凑（compact）的文件，它保存了 Redis 在某个时间点上的数据集。 这种文件非常适合用于进行备份： 比如说，你可以在最近的 24 小时内，每小时备份一次 RDB 文件，并且在每个月的每一天，也备份一个 RDB 文件。 这样的话，即使遇上问题，也可以随时将数据集还原到不同的版本。RDB 非常适用于灾难恢复（disaster recovery）：它只有一个文件，并且内容都非常紧凑，可以（在加密后）将它传送到别的数据中心，或者亚马逊 S3 中。RDB 可以最大化 Redis 的性能：父进程在保存 RDB 文件时唯一要做的就是 fork 出一个子进程，然后这个子进程就会处理接下来的所有保存工作，父进程无须执行任何磁盘 I/O 操作。RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。

即RDB 非常适用于灾难恢复，RDB的文件体积较小。

RDB 的缺点:

如果你需要尽量避免在服务器故障时丢失数据，那么 RDB 不适合你。 虽然 Redis 允许你设置不同的保存点（save point）来控制保存 RDB 文件的频率， 但是， 因为RDB 文件需要保存整个数据集的状态， 所以它并不是一个轻松的操作。 因此你可能会至少 5 分钟才保存一次 RDB 文件。 在这种情况下， 一旦发生故障停机， 你就可能会丢失好几分钟的数据。。每次保存 RDB 的时候，Redis 都要 fork() 出一个子进程，并由子进程来进行实际的持久化工作。 在数据集比较庞大时， fork() 可能会非常耗时，造成服务器在某某毫秒内停止处理客户端； 如果数据集非常巨大，并且 CPU 时间非常紧张的话，那么这种停止时间甚至可能会长达整整一秒。 虽然 AOF 重写也需要进行 fork() ，但无论 AOF 重写的执行间隔有多长，数据的耐久性都不会有任何损失。

即持久化的消耗较大，当服务器出故障可能会丢失比较多的数据

2、AOF持久化：
以日志的形式记录服务器所做的每一个写操作，在redis服务器启动之初就会读取该文件来更新数据库，以保证数据库中的数据是完整的。

AOF 的优点:
使用 AOF 持久化会让 Redis 变得非常耐久（much more durable）：你可以设置不同的 fsync 策略，比如无 fsync ，每秒钟一次 fsync ，或者每次执行写入命令时 fsync 。 AOF 的默认策略为每秒钟 fsync 一次，在这种配置下，Redis 仍然可以保持良好的性能，并且就算发生故障停机，也最多只会丢失一秒钟的数据（ fsync 会在后台线程执行，所以主线程可以继续努力地处理命令请求）。AOF 文件是一个只进行追加操作的日志文件（append only log）， 因此对 AOF 文件的写入不需要进行 seek ， 即使日志因为某些原因而包含了未写入完整的命令（比如写入时磁盘已满，写入中途停机，等等）， redis-check-aof 工具也可以轻易地修复这种问题。

Redis 可以在 AOF 文件体积变得过大时，自动地在后台对 AOF 进行重写： 重写后的新 AOF 文件包含了恢复当前数据集所需的最小命令集合。 整个重写操作是绝对安全的，因为 Redis 在创建新 AOF 文件的过程中，会继续将命令追加到现有的 AOF 文件里面，即使重写过程中发生停机，现有的 AOF 文件也不会丢失。 而一旦新 AOF 文件创建完毕，Redis 就会从旧 AOF 文件切换到新 AOF 文件，并开始对新 AOF 文件进行追加操作。AOF 文件有序地保存了对数据库执行的所有写入操作， 这些写入操作以 Redis 协议的格式保存， 因此 AOF 文件的内容非常容易被人读懂， 对文件进行分析（parse）也很轻松。 导出（export） AOF 文件也非常简单： 举个例子， 如果你不小心执行了 FLUSHALL 命令， 但只要 AOF 文件未被重写， 那么只要停止服务器， 移除 AOF 文件末尾的 FLUSHALL 命令， 并重启 Redis ， 就可以将数据集恢复到 FLUSHALL 执行之前的状态。

即持久化的消耗比较小。服务器故障产生的丢失数据较小。

AOF 的缺点:

对于相同的数据集来说，AOF 文件的体积通常要大于 RDB 文件的体积。根据所使用的 fsync 策略，AOF 的速度可能会慢于 RDB 。 在一般情况下， 每秒 fsync 的性能依然非常高， 而关闭 fsync 可以让 AOF 的速度和 RDB 一样快， 即使在高负荷之下也是如此。 不过在处理巨大的写入载入时，RDB 可以提供更有保证的最大延迟时间（latency）。AOF 在过去曾经发生过这样的 bug ： 因为个别命令的原因，导致 AOF 文件在重新载入时，无法将数据集恢复成保存时的原样。 （举个例子，阻塞命令 BRPOPLPUSH 就曾经引起过这样的 bug 。） 测试套件里为这种情况添加了测试： 它们会自动生成随机的、复杂的数据集， 并通过重新载入这些数据来确保一切正常。 虽然这种 bug 在 AOF 文件中并不常见， 但是对比来说， RDB 几乎是不可能出现这种 bug 的。

即AOF文件的体积较大

8、● 请问，redis为什么是单线程？
因为CPU不是Redis的瓶颈。Redis的瓶颈最有可能是机器内存或者网络带宽。既然单线程容易实现，而且CPU不会成为瓶颈，那就顺理成章地采用单线程的方案了。缺点：服务器其他核闲置。

9、● 简单说一说，缓存的优点是什么？
优点：1、减少了对数据库的读操作，数据库的压力降低 2、加快了响应速度

10、● 请问，为什么 redis 读写速率快、性能好？
1.Redis将数据存储在内存上，存取较快
2、Redis是单线程的，避免了上下文切换带来的消耗

11、● 说一说，MVC的各个部分都有那些技术来实现?如何实现?

MVC 是Model－View－Controller的简写

model层实现系统中的业务逻辑，通过JavaBean，EJB组件实现
view层用于与用户的交互，由JSP页面产生
controller层是model与view之间沟通的桥梁，可以分派用户的请求并选择恰当的视图以用于显示，同时它也可以解释用户的输入并将它们映射为模型层可执行的操作。一般是一个servlet。

12、事务的基本要素（ACID）
一个十元
一致性、隔离性、持久性、原子性
　1、原子性（Atomicity）：事务开始后所有操作，要么全部做完，要么全部不做，不可能停滞在中间环节。事务执行过程中出错，会回滚到事务开始前的状态，所有的操作就像没有发生一样。也就是说事务是一个不可分割的整体，就像化学中学过的原子，是物质构成的基本单位。
　　 2、一致性（Consistency）：原子性和一致性的的侧重点不同：原子性关注状态，要么全部成功，要么全部失败，不存在部分成功的状态。而一致性关注数据的可见性，中间状态的数据对外部不可见，只有最初状态和最终状态的数据对外可见
　　 3、隔离性（Isolation）：同一时间，只允许一个事务请求同一数据，不同的事务之间彼此没有任何干扰。比如A正在从一张银行卡中取钱，在A取钱的过程结束前，B不能向这张卡转账。
　　 4、持久性（Durability）：事务完成后，事务对数据库的所有更新将被保存到数据库，不能回滚。

13、事务的并发问题
1、脏读：事务A读取了事务B更新的数据，然后B回滚操作，那么A读取到的数据是脏数据
　　2、不可重复读：事务 A 多次读取同一数据，事务 B 在事务A多次读取的过程中，对数据作了更新并提交，导致事务A多次读取同一数据时，结果 不一致。
　　3、幻读：系统管理员A将数据库中所有学生的成绩从具体分数改为ABCDE等级，但是系统管理员B就在这个时候插入了一条具体分数的记录，当系统管理员A改结束后发现还有一条记录没有改过来。又例如例如有一个事务查询了几列(Row)数据，而另一个事务却在此时插入了新的几列数据，先前的事务在接下来的查询中，就会发现有几列数据是它先前所没有的。就好像发生了幻觉一样，这就叫幻读。
　　小结：不可重复读的和幻读很容易混淆，不可重复读侧重于修改，幻读侧重于新增或删除。解决不可重复读的问题只需锁住满足条件的行，解决幻读需要锁表

14、MySQL事务隔离级别

mysql默认的事务隔离级别为可重复读
补充：
1、事务隔离级别为读已提交时，写数据只会锁住相应的行
2、事务隔离级别为可重复读时，如果检索条件有索引（包括主键索引）的时候，默认加锁方式是next-key 锁；如果检索条件没有索引，更新数据时会锁住整张表。一个间隙被事务加了锁，其他事务是不能在这个间隙插入记录的，这样可以防止幻读。
3、事务隔离级别为串行化时，读写数据都会锁住整张表
4、隔离级别越高，越能保证数据的完整性和一致性，但是对并发性能的影响也越大。

15、有哪些锁？介绍一下
1、行级锁、表级锁和页级锁
可以按照锁的粒度把数据库锁分为行级锁(INNODB引擎)、表级锁(MYISAM引擎)和页级锁(BDB引擎 )。
MyISAM 发音为 “my-z[ei]m”;
InnoDB 发音为 “in-no-db”
行级锁
行级锁是Mysql中锁定粒度最细的一种锁，表示只针对当前操作的行进行加锁。行级锁能大大减少数据库操作的冲突。其加锁粒度最小，但加锁的开销也最大。行级锁分为共享锁 和 排他锁。
特点
开销大，加锁慢；会出现死锁；锁定粒度最小，发生锁冲突的概率最低，并发度也最高。
表级锁
表级锁是MySQL中锁定粒度最大的一种锁，表示对当前操作的整张表加锁，它实现简单，资源消耗较少，被大部分MySQL引擎支持。最常使用的MYISAM与INNODB都支持表级锁定。表级锁定分为表共享读锁（共享锁）与表独占写锁（排他锁）。
特点
开销小，加锁快；不会出现死锁；锁定粒度大，发出锁冲突的概率最高，并发度最低。
页级锁
页级锁是MySQL中锁定粒度介于行级锁和表级锁中间的一种锁。表级锁速度快，但冲突多，行级冲突少，但速度慢。所以取了折衷的页级，一次锁定相邻的一组记录。
特点
开销和加锁时间界于表锁和行锁之间；会出现死锁；锁定粒度界于表锁和行锁之间，并发度一般

2、悲观锁、乐观锁
悲观锁，正如其名，它指的是对数据被外界（包括本系统当前的其他事务，以及来自外部系统的事务处理）修改持保守态度，因此，在整个数据处理过程中，将数据处于锁定状态。悲观锁的实现，往往依靠数据库提供的锁机制（也只有数据库层提供的锁机制才能真正保证数据访问的排他性，否则，即使在本系统中实现了加锁机制，也无法保证外部系统不会修改数据），排它锁和共享锁属于悲观锁的具体锁。
乐观锁（ Optimistic Locking ） 相对悲观锁而言，乐观锁假设认为数据一般情况下不会造成冲突，所以在数据进行提交更新的时候，才会正式对数据的冲突与否进行检测，如果发现冲突了，则让返回用户错误的信息，让用户决定如何去做（一般是回滚事务）

3、排他锁、共享锁、更新锁。
排他锁（Exclusive Lock）
X锁，也叫写锁，表示对数据进行写操作。如果一个事务对对象加了排他锁，其他事务就不能再给它加任何锁了。（某个顾客把试衣间从里面反锁了，其他顾客想要使用这个试衣间，就只有等待锁从里面打开了。）
性质

1. 仅允许一个事务封锁此页；
2. 其他任何事务必须等到X锁被释放才能对该页进行访问；
3. X锁一直到事务结束才能被释放。

共享锁（Share Lock）
S锁，也叫读锁，用于所有的只读数据操作。共享锁是非独占的，允许多个并发事务读取其锁定的资源。
性质

1. 多个事务可封锁同一个共享页；
2. 任何事务都不能修改该页；
3. 通常是该页被读取完毕，S锁立即被释放。

更新锁
U锁，在修改操作的初始化阶段用来锁定可能要被修改的资源，这样可以避免使用共享锁造成的死锁现象。它允许其他事务读，但不允许再施加U锁或X锁。

因为当使用共享锁时，修改数据的操作分为两步：

1. 首先获得一个共享锁，读取数据，
2. 然后将共享锁升级为排他锁，再执行修改操作。
   这样如果有两个或多个事务同时对一个事务申请了共享锁，在修改数据时，这些事务都要将共享锁升级为排他锁。这时，这些事务都不会释放共享锁，而是一直等待对方释放，这样就造成了死锁。
   如果一个数据在修改前直接申请更新锁，在数据修改时再升级为排他锁，就可以避免死锁。

16、什么是死锁？怎么解决？
死锁是指两个或多个事务在同一资源上相互占用，并请求锁定对付的资源，从而导致恶性循环的现象。

产生死锁的必要条件：
1、占有请求
2、循环等待
3、不可剥夺
4、互斥条件

解决死锁的方法：
预防死锁：通过设置某些限制条件，去破坏产生死锁的四个必要条件中的一个或几个条件，来防止死锁的发生。
避免死锁：在资源的动态分配过程中，用某种方法去防止系统进入不安全状态，从而避免死锁的发生。
检测死锁：允许系统在运行过程中发生死锁，但可设置检测机构及时检测死锁的发生，并采取适当措施加以清除。
解除死锁：当检测出死锁后，便采取适当措施将进程从死锁状态中解脱出来。

预防死锁的三种方法：
1）破坏不可剥夺条件
2）破坏占有请求
3）破坏循环等待（按顺序申请资源）

17、什么是数据库连接池？
从上一个sql生命周期题目，可以看到其中的连接在里面发挥着重大作用，但频繁的创建和销毁，非常浪费系统资源。由于数据库更适合长连接，也就有个连接池，能对连接复用，维护连接对象、分配、管理、释放，也可以避免创建大量的连接对DB引发的各种问题；另外通过请求排队，也缓解对DB的冲击。

18、介绍索引
**索引是对数据库表中一列或多列的值进行排序的一种结构。**一个非常恰当的比喻就是书的目录页与书的正文内容之间的关系，为了方便查找书中的内容，通过对内容建立索引形成目录。索引是一个文件，它是要占据物理空间的。

大部分数据库系统及文件系统都采用B-Tree或其变种B+Tree作为索引结构。MySQL就使用B+Tree实现其索引结构

主键索引:
数据列不允许重复，不允许为NULL.一个表只能有一个主键。
唯一索引:
数据列不允许重复，允许为NULL值，一个表允许多个列创建唯一索引。
普通索引:
基本的索引类型，没有唯一性的限制，允许为NULL值。

19、怎样对数据库进行优化
0、选取最适用的字段大小（如邮编就不需要char（255））
1、对于查询语句，最重要的优化方式就是使用索引。
2、mysql中 in 和exists 区别
mysql中的in语句是把外表和内表作hash 连接，而exists语句是对外表作loop循环，每次loop循环再对内表进行查询。一直大家都认为exists比in语句的效率要高，这种说法其实是不准确的。这个是要区分环境的。
如果查询的两个表大小相当，那么用in和exists差别不大。
如果两个表中一个较小，一个是大表，则子查询表大的用exists，子查询表小的用in。
not in 和not exists如果查询语句使用了not in 那么内外表都进行全表扫描，没有用到索引；而not extsts的子查询依然能用到表上的索引。所以无论那个表大，用not exists都比not in要快。
3、少使用模糊查询like
关键词%yue%，由于yue前面用到了“%”，因此该查询必然走全表扫描，除非必要，否则不要在关键词前加%。
4、where和having中尽量使用where。
5、理论上，尽量使用多表连接（join）查询（避免子查询）
6、使用联合(UNION)来代替手动创建的临时表

20、数据库索引了解吗
MySQL就使用B+Tree实现其索引结构但对于主要的两种存储引擎的实现方式是不同的。
MyISAM: B+Tree叶节点的data域存放的是数据记录的地址。在索引检索的时候，首先按照B+Tree搜索算法搜索索引，如果指定的Key存在，则取出其 data 域的值，然后以 data 域的值为地址读取相应的数据记录。这被称为“非聚簇索引”。即先在索引中找出数据存储的位置，再去数据中找出数据。
InnoDB: 其数据文件本身就是索引文件。相比MyISAM，索引文件和数据文件是分离的，其表数据文件本身就是按B+Tree组织的一个索引结构，树的叶节点data域保存了完整的数据记录。这个索引的key是数据表的主键，因此InnoDB表数据文件本身就是主索引。这被称为“聚簇索引（或聚集索引）”。即数据本身就是索引，找到索引的同时就找到了数据

21、说说自己对于 MySQL 常见的两种存储引擎：MyISAM与InnoDB的理解
关于二者的对比与总结:
1、InnoDB是聚集索引，支持事务，支持行级锁；
2、MyISAM是非聚集索引，不支持事务，只支持表级锁。
3、 MyISAM 强调的是性能，每次查询具有原子性,其执行速度比InnoDB类型更快
4、 MyISAM不支持外键，而InnoDB支持外键。
5、MyISAM更适合读密集的表，而InnoDB更适合写密集的的表。

总结：一般来说，如果需要事务支持，并且有较高的并发读取频率(MyISAM的表锁的粒度太大，所以当该表写并发量较高时，要等待的查询就会很多了)，InnoDB是不错的选择。如果你的数据量很大（MyISAM支持压缩特性可以减少磁盘的空间占用），而且不需要支持事务时，MyISAM是最好的选择。

22、视图的作用，视图可以更改么？
视图是虚拟的表，与包含数据的表不一样，视图只包含使用时动态检索数据的查询；对于某些视图比如未使用联结子查询分组聚集函数Distinct Union等，是可以对其更新的，对视图的更新将对基表进行更新；但是视图主要用于简化检索，保护数据，并不用于更新，而且大部分视图都不可以更新。

23、对于大表的常见优化手段说一下

1、限定数据的范围： 务必禁止不带任何限制数据范围条件的查询语句。比如：我们当用户在查询订单历史的时候，我们可以控制在一个月的范围内。；
2、读/写分离： 经典的数据库拆分方案，主库负责写，从库负责读；
3、缓存： 使用MySQL的缓存，另外对重量级、更新少的数据可以考虑使用应用级别的缓存；
4、垂直分区：
根据数据库里面数据表的相关性进行拆分。简单来说垂直拆分是指数据表列的拆分，把一张列比较多的表拆分为多张表。
5、水平分区：
保持数据表结构不变，通过某种策略存储数据分片。这样每一片数据分散到不同的表或者库中，达到了分布式的目的。

24、drop,delete与truncate的区别
drop直接删掉表
truncate删除表中所有的数据，且不能回滚
delete删除表中数据，可以加where字句，可以回滚。

25、范式
1NF 符合1NF的关系中的每个属性都不可再分
2NF 消除部分依赖，每个非主属性都完全依赖于码
3NF 消除传递依赖，每个非主属性不部分依赖也不传递依赖于码
BCNF 每个决定因素都包含有码，即消除主属性对于码的部分与传递函数依赖
4NF 当一个表在非主属性相互独立时（BCNF），这些非主属性不应该有多值。
注意：

码就是候选码
主属性：如一个属性是构成某一个候选关键字的属性集中的一个属性，则称它为主属性。
非主属性：不包含于任何一个候选码的属性为非主属性
部分函数依赖：设X,Y是关系R的两个属性集合，存在X→Y，若X’是X的真子集，存在X’→Y，则称Y部分函数依赖于X。
传递函数依赖：设X,Y,Z是关系R中互不相同的属性集合，存在X→Y(Y !→X),Y→Z，则称Z传递函数依赖于X。举个例子：通过A得到B，通过B得到C，但是C得不到B，B得不到A，那么成C传递依赖于A
完全函数依赖：设X,Y是关系R的两个属性集合，X’是X的真子集，存在X→Y，但对每一个X’都有X’!→Y，则称Y完全函数依赖于X。举个例子：通过AB能得出C，但是AB单独得不出C，那么说C完全依赖于AB.

26、强一致性、弱一致性、最终一致性
对于关系型数据库，要求更新过的数据能被后续的访问都能看到，这是强一致性，如果能容忍后续的部分或者全部访问不到，则是弱一致性。如果经过一段时间后要求能访问到更新后的数据，则是最终一致性。

27、JDBC连接数据库的步骤
（1）加载JDBC驱动器，即将JDBC驱动复制到WEN-INF/lib下
（2）加载JDBC驱动，将其注册到DriverManager中，即Class.forName(“com.mysql.jdbc.Driver”)；
（3）建立数据库连接，取得Connection对象，即
con = DriverManager.getConnection(url,user,password)；
（4）建立statement或者preparestatement。其中preparestatement可以用？作为占位符。如stmt=con.creatStatement();或PreparedStatement ps = con. PreparedStatement(sql);
（5）执行sql语句

28、● 请你说明一下 left join 和 right join 的区别？
left join(左联接) 返回包括左表中的所有记录和右表中联结字段相等的记录
right join(右联接) 返回包括右表中的所有记录和左表中联结字段相等的记录

29、● 请你讲讲 Statement 和 PreparedStatement 的区别？哪个性能更好？
PreparedStatement可以使用占位符，是预编译的，批处理比Statement效率高

30、● 请你谈谈JDBC的反射，以及它的作用？
通过反射com.mysql.jdbc.Driver类，实例化该类的时候会执行该类内部的静态代码块，该代码块会在Java实现的DriverManager类中注册自己,DriverManager管理所有已经注册的驱动类，当调用DriverManager.geConnection方法时会遍历这些驱动类，并尝试去连接数据库，只要有一个能连接成功，就返回Connection对象，否则则报异常。

31、游标
https://blog.csdn.net/u014138443/article/details/88676612
如果想对动态检索出来的数据按照行进行读取，如得到第一行，下一行，前十行等，就需要用到游标。
32、mysql存储过程
https://blog.csdn.net/u014138443/article/details/88676463
存储过程是一组为了完成特定功能的SQL语句集，经编译后存储在数据库中，用户通过指定存储过程的名字并给定参数（如果该存储过程带有参数）来调用执行它。