数据厍运行中可能产生的故障有哪几类？
事务故障、系统故障和介质故障影响事务的正常执行；介质故障和计算机病毒破坏数据厍数据。
4．什么是日志文件？为什么要设立日志文件？
答案：
（1）日志文件是用来记录事务对数据厍的更新操作的文件。
（2）设立日志文件的目的是：进行事务故障恢复；进行系统故障恢复；协助后备副本进行介质故障恢复
8．登记日志文件时为什么必须先写日志文件，后写数据库？
答案：
把对数据的修改写到数据库中和把表示这个修改的日志记录写到日志文件中是两个不同的操作。有可能在这两个操作之间发生故障，即这两个写操作只完成了一个。
如果先写了数据厍修改，而在运行记录中没有登记这个修改，则以后就无法恢复这个修改了。
如果先写日志，但没有修改数据厍，在恢复时只不过是多执行一次UNDO操作，并不会影响数据厍的正确性。所以一定要先写日志文件，即首先把日志记录写到日志文件中，然后写数据库的修改。
11，数据厍恢复的基本技术有哪些？
答案：
数据转储和登录日志文件是数据厍恢复的基本技术。
当系统运行过程中发生故障，利用转储的数据厍后备副本和日志文件就可以将数据厍恢复到故障前的某个一致性状态。
转储即DBA定期地将数据厍复制到磁带或另一个磁盘上保存起来的过程。
静态转储：在系统中无运行事务时进行的转储操作。静态转储简单，但必须等待正运行的用户事务结束才能进行。同样，新的事务必须等待转储结束才能执行。显然，这会降低数据库的可用性。
动态转储：指转储期间允许对数据厍进行存取或修改。动态转储可克服静态转储的缺点，它不用等待正在运行的用户事务结束，也不会影响新事务的运行。但是，转储结束时后援副本上的数据并不能保证正确有效。因为转储期间运行的事务可能修改了某些数据，使得后援副本上的数据不是数据厍的一致版本。
为此，必须把转储期间各事务对数据库的修改活动登记下来，建立日志文件(logfile).这样，后援副本加上日志文件就能得到数据厍某一时刻的正确状态。
转储还可以分为海量转储和增量转储两种方式。
海量转储是指每次转储全部数据厍。增量转储则指每次只转储上一次转储后更新过的数据。
从恢复角度看，使用海量转储得到的后备副本进行恢复一般说来更简单些。但如果数据厍很大，事务处理又十分频繁，则增量转储方式更实用更有效。
12．数据厍设计中的规划阶段的主要任务：
答案：是进行建立数据厍的必要性及可行性分析，确定数据厍系统在组织中和信息系统中的地位，以及各个数据厍之间的联系
5 超键 候选键 主键 外键 区别
超键在关系中能唯一标识元组的属性集称为关系模式的超键，一个或多个属性组合在一起作为超键。
候选键 最下超键，没有冗余元素的超键
主键 数据库中表中唯一和完整标识的数据列或属性集合。
外键 在一个表中存在另外一个表的主键叫做外键
幻读
事务在插入已经检查过不存在的记录时，惊奇的发现这些数据已经存在了
例子：
在事务1中，查询User表id为1的是用户否存在，如果不存在则插入一条id为1的数据。
在事务1查询结束后，事务2往User表中插入了一条id为1的数据。
此时，由于事务1查询到id为1的用户不存在，因此插入1条id为1的数据。
但是由于事务2已经插入了1条id为1的数据，因此此时会报主键冲突，对于事务1 的业务来说是执行失败的，这里事务1 就是发生了幻读，因为事务1读取的数据状态并不能支持他的下一步的业务
不可重复读
在一个事务中前后两次读取的结果并不致，导致了不可重复读。
不可重复读和幻读比较：
两者有些相似，但是前者针对的是update或delete，后者针对的insert。
Oracle默认的隔离级别为Read Committed，因此可能出现不可重复度和幻读。
MySql默认的隔离级别为Repeatable Read，因此只会出现幻读的情况。
7.数据库事务的四个特性及含义
数据库事务transanction正确执行的四个基本要素。ACID,原子性(Atomicity)、一致性(Correspondence)、隔离性(Isolation)、持久性(Durability)。
原子性:整个事务中的所有操作，要么全部完成，要么全部不完成，不可能停滞在中间某个环节。事务在执行过程中发生错误，会被回滚(Rollback)到事务开始前的状态，就像这个事务从来没有执行过一样。
一致性:在事务开始之前和事务结束以后，数据库的完整性约束没有被破坏。
隔离性:隔离状态执行事务，使它们好像是系统在给定时间内执行的唯一操作。如果有两个事务，运行在相同的时间内，执行 相同的功能，事务的隔离性将确保每一事务在系统中认为只有该事务在使用系统。这种属性有时称为串行化，为了防止事务操作间的混淆，必须串行化或序列化请求，使得在同一时间仅有一个请求用于同一数据。
持久性:在事务完成以后，该事务所对数据库所作的更改便持久的保存在数据库之中，并不会被回滚。
8.视图的作用，视图可以更改么?
视图是虚拟的表，与包含数据的表不一样，视图只包含使用时动态检索数据的查询;不包含任何列或数据。使用视图可以简化复杂的sql操作，隐藏具体的细节，保护数据;视图创建后，可以使用与表相同的方式利用它们。
视图不能被索引，也不能有关联的触发器或默认值，如果视图本身内有order by 则对视图再次order by将被覆盖。
创建视图：create view XXX as XXXXXXXXXXXXXX;
对于某些视图比如未使用联结子查询分组聚集函数Distinct Union等，是可以对其更新的，对视图的更新将对基表进行更新;但是视图主要用于简化检索，保护数据，并不用于更新，而且大部分视图都不可以更新。
9.drop,delete与truncate的区别
drop直接删掉表 truncate删除表中数据，再插入时自增长id又从1开始 delete删除表中数据，可以加where字句。
(1) DELETE语句执行删除的过程是每次从表中删除一行，并且同时将该行的删除操作作为事务记录在日志中保存以便进行进行回滚操作。TRUNCATE TABLE 则一次性地从表中删除所有的数据并不把单独的删除操作记录记入日志保存，删除行是不能恢复的。并且在删除的过程中不会激活与表有关的删除触发器。执行速度快。
(2) 表和索引所占空间。当表被TRUNCATE 后，这个表和索引所占用的空间会恢复到初始大小，而DELETE操作不会减少表或索引所占用的空间。drop语句将表所占用的空间全释放掉。
(3) 一般而言，drop > truncate > delete
(4) 应用范围。TRUNCATE 只能对TABLE;DELETE可以是table和view
(5) TRUNCATE 和DELETE只删除数据，而DROP则删除整个表(结构和数据)。
(6) truncate与不带where的delete ：只删除数据，而不删除表的结构(定义)drop语句将删除表的结构被依赖的约束(constrain),触发器(trigger)索引(index);依赖于该表的存储过程/函数将被保留，但其状态会变为：invalid。
(7) delete语句为DML(data maintain Language),这个操作会被放到 rollback segment中,事务提交后才生效。如果有相应的 tigger,执行的时候将被触发。
(8) truncate、drop是DLL(data define language),操作立即生效，原数据不放到 rollback segment中，不能回滚
(9) 在没有备份情况下，谨慎使用 drop 与 truncate。要删除部分数据行采用delete且注意结合where来约束影响范围。回滚段要足够大。要删除表用drop;若想保留表而将表中数据删除，如果于事务无关，用truncate即可实现。如果和事务有关，或老师想触发trigger,还是用delete。
(10) Truncate table 表名 速度快,而且效率高,因为:
truncate table 在功能上与不带 WHERE 子句的 DELETE 语句相同：二者均删除表中的全部行。但 TRUNCATE TABLE 比 DELETE 速度快，且使用的系统和事务日志资源少。DELETE 语句每次删除一行，并在事务日志中为所删除的每行记录一项。TRUNCATE TABLE 通过释放存储表数据所用的数据页来删除数据，并且只在事务日志中记录页的释放。
(11) TRUNCATE TABLE 删除表中的所有行，但表结构及其列、约束、索引等保持不变。新行标识所用的计数值重置为该列的种子。如果想保留标识计数值，请改用 DELETE。如果要删除表定义及其数据，请使用 DROP TABLE 语句。
(12) 对于由 FOREIGN KEY 约束引用的表，不能使用 TRUNCATE TABLE，而应使用不带 WHERE 子句的 DELETE 语句。由于 TRUNCATE TABLE 不记录在日志中，所以它不能激活触发器。
索引的优缺点
为什么要创建索引呢？这是因为，创建索引可以大大提高系统的性能。
第一，通过创建唯一性索引，可以保证数据库表中每一行数据的唯一性。
第二，可以大大加快数据的检索速度，这也是创建索引的最主要的原因。
第三，可以加速表和表之间的连接，特别是在实现数据的参考完整性方面特别有意义。
第四，在使用分组和排序子句进行数据检索时，同样可以显著减少查询中分组和排序的时间。
第五，通过使用索引，可以在查询的过程中，使用优化隐藏器，提高系统的性能。
增加索引也有许多不利的一个方面。
第一，创建索引和维护索引要耗费时间，这种时间随着数据量的增加而增加。
第二，索引需要占物理空间，除了数据表占数据空间之外，每一个索引还要占一定的物理空间，如果要建立聚簇索引，那么需要的空间就会更大。
第三，当对表中的数据进行增加、删除和修改的时候，索引也要动态的维护，这样就降低了数据的维护速度。
索引是什么
索引是对数据库中一或多个列值的排序，帮助数据库高效获取数据的数据结构
假如我们用类比的方法，数据库中的索引就相当于书籍中的目录一样。
几个基本的索引类型 普通索引 唯一索引主键索引 全文索引
索引优点
· 加快检索速度
· 唯一索引确保每行数据的唯一性
· 在使用索引的过程可以优化隐藏器，提高系统性能
索引缺点
· 插入删除 修改 维护速度下降
· 占用物理和数据空间
约束的种类与目的
-- 约束的目的 确保表中数据的完整性
-- 行完整性（实体完整性）：主键约束与唯一约束
-- 列完整性（域完整性） ：检查约束、默认约束与非空约束
-- 参照完整性 ：外键约束
什么叫做覆盖索引？
解释一： 就是select的数据列只用从索引中就能够取得，不必从数据表中读取，换句话说查询列要被所使用的索引覆盖。
MySQL用户权限表
MySQL的认证是“用户”加“主机”而权限是访问资源对象，MySQL服务器通过权限表来控制用户对数据库的访问，权限表存放在mysql数据库中，由 mysql_install_db 脚本初始化。存储账户权限信息表主要有：user,db,tables_priv,columns_priv,procs_priv 这五张表（5.6之前还有host表，现在已经把host内容整合进user表），五张表其含义分别是：
user表
user表时MySQL中最重要的一个权限表，记录允许连接到服务器的账号信息，里面的权限是全局级的。例如：一个用户在user表中被授予了DELETE权限，则该用户可以删除MySQL服务器上所有数据库的任何记录。
db表
db表存储了用户对某个数据库的操作权限，决定用户能从哪个主机存储哪个数据库。User表中存储了某个主机对数据库的操作权限，配置和db权限表对给定主机上数据库级操作权限做更细致的控制。
tables_priv and columns_priv表
table_priv表示对表的操作权限包括、select、insert、update、delete、create、drop、grant、references、index和alter。
column_priv字段表示对表中的列的操作权限，包括select、insert、update和references。
procs_priv表
存储过程和存储函数相关的权限
MySQL访问控制两阶段
阶段1：客户端连接核实阶段
阶段2：客户端操作核实阶段
客户端连接核实阶段，当连接MySQL服务器时，服务器基于用户的身份以及用户是否能通过正确的密码身份验证，来接受或拒绝连接。即客户端用户连接请求中会提供用户名称、主机地址和密码，MySQL使用user表中的三个字段（Host、User、Password）执行身份检查。
接下来就可以进入操作核实阶段，MySQL首先检查user表，如果指定的权限没有在user表中被授权；MySQL将检查db表，db表时下一安全层级，其中的权限限定于数据库层级，在该层级的SELECT权限允许用户查看指定数据库的所有表中的数据；如果在该层级没有找到限定的权限，则MySQL继续检查tables_priv表以及columns_priv表，如果所有权限表都检查完毕，但还是没有找到允许的权限操作，MySQL将返回错误信息，用户请求的操作不能执行，操作失败。
经典权限系统表设计
设计基础：用户、角色、权限三大核心表，加上用户角色、角色权限两个映射表(用于给用户表联系上权限表)。这样就可以通过登录的用户来获取权限列表，或判断是否拥有某个权限。
大致用到５张表：用户表（UserInfo）、角色表（RoleInfo）、菜单表（MenuInfo）、用户角色表（UserRole）、角色菜单表（RoleMenu）。
各表的大体表结构如下：
１、用户表（UserInfo）：Id、UserName、UserPwd
２、角色表（RoleInfo）：Id、RoleName
３、菜单表（MenuInfo）：Id、MenuName
４、用户角色表（UserRole）：Id、UserId、RoleId
５、角色菜单表（RoleMenu）：Id、RoleId、MenuId
最关键的地方是，某个用户登录时，如何查找该用户的菜单权限？其实一条语句即可搞定：
假如用户的用户名为Arthur，则他的菜单权限查询如下：
Select m.Id,m.MenuName from MenuInfo m ,UserInfo u, UserRole ur, RoleMenu rm Where m.Id = rm.MenuId and ur.RoleId = rm.RoleId and ur.UserId = u.Id and u.UserName = 'Arthur'
当单表的数据量达到1000W以后，即使添加从库、优化索引，做很多操作时性能仍下降严重。此时就要考虑对其进行切分，就是将数据分散存储到多个数据库中，使得单一数据库中的数据量变小，通过扩充主机的数量缓解单一数据库的性能问题，从而达到提升性能的目的。
数据切分根据其切分类型，可以分为两种方式：垂直（纵向）切分和水平（横向）切分
1、垂直（纵向）切分
垂直切分常见有垂直分库和垂直分表两种。
垂直分库就是根据业务耦合性，将关联度低的不同表存储在不同的数据库。做法与大系统拆分为多个小系统类似，按业务分类进行独立划分。与"微服务治理"的做法相似，每个微服务使用单独的一个数据库。
垂直分表是基于数据库中的"列"进行，某个表字段较多，可以新建一张扩展表，将不经常用或字段长度较大的字段拆分出去到扩展表中。
优点：
解决业务系统层面的耦合，业务清晰
与微服务的治理类似，也能对不同业务的数据进行分级管理、维护、监控、扩展等
高并发场景下，垂直切分一定程度的提升IO、数据库连接数、单机硬件资源的瓶颈
缺点：
部分表无法join，只能通过接口聚合方式解决，提升了开发的复杂度
分布式事务处理复杂
依然存在单表数据量过大的问题（需要水平切分）
2、水平（横向）切分
当一个应用难以再细粒度的垂直切分，或切分后数据量行数巨大，存在单库读写、存储性能瓶颈，这时候就需要进行水平切分了。
水平切分分为库内分表和分库分表，是根据表内数据内在的逻辑关系，将同一个表按不同的条件分散到多个数据库或多个表中，每个表中只包含一部分数据，从而使得单个表的数据量变小，达到分布式的效果。
几种典型的数据分片规则为：
1、根据数值范围
按照时间区间或ID区间来切分。例如：按日期将不同月甚至是日的数据分散到不同的库中；
某些系统中使用的"冷热数据分离"，将一些使用较少的历史数据迁移到其他库中，业务功能上只提供热点数据的查询
2、根据数值取模
一般采用hash取模mod的切分方式，例如：将 Customer 表根据 cusno 字段切分到4个库中，余数为0的放到第一个库，余数为1的放到第二个库，以此类推。
水平切分的优点：
不存在单库数据量过大、高并发的性能瓶颈，提升系统稳定性和负载能力
应用端改造较小，不需要拆分业务模块
缺点：
跨分片的事务一致性难以保证
跨库的join关联查询性能较差
数据多次扩展难度和维护量极大
分库分表后带来的问题
分库分表能有效的环节单机和单库带来的性能瓶颈和压力，突破网络IO、硬件资源、连接数的瓶颈，同时也带来了一些问题。
1、事务一致性问题
2、跨节点关联查询 join 问题
3、跨节点分页、排序、函数问题
4、全局主键避重问题
5、数据迁移、扩容问题