面试复习-MySQL

是rick啊

已于 2023-06-02 17:53:54 修改

阅读量136

点赞数 1

文章标签： mysql 面试数据库

于 2023-04-23 01:00:00 首次发布

本文链接：https://blog.csdn.net/weixin_50166407/article/details/130233234

版权

MySQL

基础架构

连接器：身份认证和权限相关（登录MySQL的时候）。
查询缓存：执行查询语句的时候，会先查询缓存(ySQL8.0版本后移除，因为这个功能不太实用)。
分析器：没有命中缓存的话，SQL语句就会经过分析器，分析器说白了就是要先看你的SQL语句要干嘛，再检查你的SQL语句语法是否正确
优化器：按照MySQL认为最优的方案去执行。
执行器：执行语句，然后从存储引擎返回数据。执行语句之前会先判断是否有权限，如果没有权限的话，就会报错。
插件式存储引擎：主要负责数据的存储和读取，采用的是插件式架构，支持innoDB、MyISAM、Memory等多种存储引擎。

存贮引擎

下面是 MySQL 常见的存储引擎的对比表格。存储引擎是基于表的，⽽不是数据库。

存储引擎	描述	事务支持	锁机制	主键支持	外键支持	索引支持	其他特性
InnoDB	支持事务和行锁，适合于高并发场景	✓	行锁	✓	✓	✓	支持自动增长、热备份、全文索引等特性
MyISAM	不支持事务和行锁，适合于读密集型场景	✗	表锁	✓	✗	✓	支持多种压缩方式、空间函数、全文索引等特性
Memory	数据存储在内存中，速度非常快，但数据不能持久化	✗	无锁	✓	✗	✓	只适用于临时数据存储，不适用于长期存储
NDB（Cluster）	分布式数据库存储引擎，能够提供高可用和高性能	✓	行锁	✓	✓	✓	适用于大型分布式数据库存储
ARCHIVE	压缩存储引擎，适合于存储大量历史数据	✗	行锁	✗	✗	✗	只适用于不经常更新的历史记录存储
CSV	存储 CSV 数据格式的存储引擎	✗	表锁	✓	✗	✗	可以快速导入导出 CSV 格式数据
Blackhole（/dev/null）	将所有写入的数据丢弃，适用于数据流复制测试等场景	✗	不使用锁	✗	✗	✗	数据不被持久化
Federated	虚拟存储引擎，可以将多个远程 MySQL 数据库当做一个本地数据库	✗	不使用锁	✗	✓	✗	可以实现数据的远程访问和共享

InnoDB和MyISAM存储引擎在索引方面有一些不同之处。

索引结构
- InnoDB使用的是B+树索引结构，支持聚集索引，即数据行的物理顺序与其索引的逻辑顺序相同。这可以大大提高查询效率，特别是在范围查询时。
- MyISAM使用的是B树索引结构，不支持聚集索引，数据行的物理顺序与其在磁盘上的位置无关。
索引缓存
- InnoDB的索引缓存是InnoDB缓冲池的一部分，也就是说，索引和数据都会存放在缓冲池中。这样可以极大地提高IO性能。
- MyISAM的索引缓存是Key Cache。键缓存不包括表数据，它只缓存索引。这就使得MyISAM在处理大量可适应于内存的索引时具有很好的性能。
索引锁定
- InnoDB会锁定表的行而不是锁定整张表。
- MyISAM在进行写操作时，需要锁定整张表。

InnoDB存储引擎

InnoDB是MySQL的默认事务型引擎，它被设计用来处理大量的短期(short-lived)事务。可以确保事务的完整提交(Commit)和回滚(Rollback)。
除非有非常特别的原因需要使用其他的存储引擎，否则应该优先考虑InnoDB引擎。
数据文件结构：
- 表名.frm 存储表结构（MySQL8.0时，合并在表名.ibd中）
- 表名.ibd 存储数据和索引
InnoDB不仅缓存索引还要缓存真实数据，对内存要求较高，而且内存大小对性能有决定性的影响。

MyISAM存储引擎

MyISAM提供了大量的特性，包括全文索引、压缩、空间函数(GIS)等，但MyISAM不支持事务和行级锁，有一个毫无疑问的缺陷就是崩溃后无法安全恢复。
优势是访问的速度快，对事务完整性没有要求或者以SELECT、INSERT为主的应用。
数据文件结构：
- 表名.frm 存储表结构
- 表名.MYD 存储数据
- 表名.MYI 存储索引
MyISAM只缓存索引，不缓存真实数据。

索引

聚簇索引是指按照某一列或多列的排序规则，将行数据按照这个顺序存储到磁盘上，因此也被称为聚集索引。例如，在MySQL中使用InnoDB存储引擎时，每张表只能有一个聚簇索引，且默认情况下使用主键作为聚簇索引。由于数据行的物理顺序和索引顺序相同，因此对于基于聚簇索引的查询可以快速地获取到数据行，因为这些数据行在磁盘上是连续存储的。

非聚簇索引是指单独创建的、与数据行分离存储的索引。它并不影响数据行的存储方式，只是在另外的数据结构中存储了某些列的索引信息，指向实际的数据行。在MySQL中使用MyISAM存储引擎时，默认情况下使用B树作为非聚簇索引的数据结构。非聚簇索引中的B树节点包含索引值和数据地址，通过B树的搜索，可以定位到对应的数据行。因此，非聚簇索引可以避免数据行的重新排列，使得表的维护成本较低。但是，如果查询需要获取非索引列的数据时，需要通过索引值定位到对应的数据行再进行一次查找操作。

7e82826d058d7e8202d442dff4a9a3d4f08dead3.png@680w_!web-note

索引的优缺点是什么？

优点

聚簇（主键）索引：

顺序读写
范围快速查找
范围查找自带顺序

非聚簇索引：

条件查询避免全表扫描scan
范围，排序，分组查询返回行id，排序分组后，再回表查询完整数据，有可能利用顺序读写
覆盖索引不需要回表操作

索引的代价

索引是个好东西，可不能乱建，它在空间和时间上都会有消耗：

空间上的代价

每建立一个索引都要为它建立一棵B+树，每一棵B+树的每一个节点都是一个数据页，一个页默认会占用 16KB 的存储空间，一棵很大的B+树由许多数据页组成，那就是很大的一片存储空间。

时间上的代价

每次对表中的数据进行增、删、改操作时，都需要去修改各个B+树索引。而增、删、改操作可能会对节点和记录的排序造成破坏，所以存储引擎需要额外的时间进行一些记录移位、页面分裂、页面回收等操作来维护好节点和记录的排序。如果我们建了许多索引，每个索引对应的B+树都要进行相关的维护操作，会给性能拖后腿。

B 树和 B+ 树都可以作为索引的数据结构，在 MySQL 中采用的是 B+ 树。

但B树和B+树各有自己的应用场景，不能说B+树完全比B树好，反之亦然。

使用索引一定能提升效率吗？

不一定

少量数据全表扫描也很快，可以直接获取到全量数据
唯一索引会影响插入速度，但建议使用
索引过多会影响更新，插入，删除数据速度

什么是索引下推？

5.6之前的版本是没有索引下推这个优化的

如果没有索引下推(ICP),那么MySQL在存储引学层找到满足content1>'z’条件的第一条二级索引记录。主键值进行回表，返回完整的记录给server层，server层再判断其他的搜索条件是香成立。如果成立则保留该记录，否则跳过该记录，然后向存储引擎层要下一条记
如果使用了素引下推(ICP),那么MySQL在存储引擎层找到满足content.1>'z’条件的第一条二级索引记录，不着急执行查表，而是在这条记录上先判断一下所有关于索引中包含的条件是否成立，也就是contentl>‘z”AND content1LIKE’%a’是否成立，如果这些条件不成立，则直接跳过该二级索引记录，去找下一条二级索引记录；如果这些条件成立，则执行回表操作，返回完整的记录给server层.

总结：

未开启素下推：
根据筛选条件在索引树中筛选第一个条件
获得结果集后回表操作
进行其他条件等选
再次回表查询
开启索引下推：在条件查询时，当前索引树如果满足全部筛选条件，可以在当前树中完成全部筛选过滤，得到比较

有哪些情况会导致索引失效？

引失效通常指在查询中无法使用已有的索引，导致MySQL服务层需要全表扫描来获取查询结果。在如下情况下，MySQL可能无法使用已有的索引：

函数或表达式操作：在WHERE条件中使用函数或计算表达式（如SUM、MAX、MIN、CONCAT等）进行比较时，MySQL不能直接使用索引，需要先计算表达式或函数，并将结果再与索引或数据行进行比较。
隐式类型转换：如果在WHERE条件中将字符串类型与数字类型进行比较，MySQL会自动将字符串类型转换成数字类型。这样虽然可以完成比较操作，但由于隐式类型转换的影响，MySQL无法使用索引。
对索引列进行函数处理：在WHERE条件中对索引列进行函数处理时，MySQL需要先计算函数结果，并再把结果与索引进行比较。如果涉及到大量数据计算，那么这种操作可能导致索引失效。
In列表过长：当In列表中包含太多的元素时，MySQL无法使用索引，而需要全表扫描来获取结果。
范围查询和LIKE查询：如果查询条件中包含范围查询（>、<、>=、<=）或LIKE表达式，MySQL只能进行全表扫描或者使用索引的部分前缀进行过滤，不能完全使用索引。

NULL值查询：MySQL在使用B-tree索引时，无法直接搜索NULL值，因为索引中不允许NULL值的存在。如果要查询NULL值，只能使用IS NULL或者IS NOT NULL表达式。

# 未指定 
EXPLAIN select * from question_extracting where user_id BETWEEN 670 AND 990

# 显示指定
EXPLAIN select * from question_extracting force index(user_id) where user_id BETWEEN 670 AND 990

505da1335c3bdd4e733913aa900aa45e06385ae1.png@680w_!web-note

多个索引优先级是如何匹配的？

主键（唯一索引）匹配：如果查询条件中包含了主键或唯一索引列，那么MySQL会直接使用该索引进行匹配。
全值匹配（单值匹配）：如果查询条件中所有的索引列都是“=”或“IN”操作，MySQL会使用这些索引进行全值匹配，并且可以使用覆盖索引来避免回表操作。
最左前缀匹配：如果查询条件中涉及到的索引列只是复合索引的一部分，MySQL会使用最左匹配原则，也就是从复合索引左边开始进行扫描匹配。
范围匹配：如果查询条件中涉及到的索引列有“<、>、BETWEEN、LIKE、IN”等范围操作，MySQL会选择使用该索引进行范围匹配。
索扫描：如果MySQL无法使用上述匹配方式，但可以通过扫描整个索引来查找符合条件的数据行，则会进行索扫描。
全表扫描：如果MySQL无法使用任何索引进行匹配，则只能进行全表扫描来查找符合条件的数据行。

7572bde48f15923e8bb06f5be6f0d361d6af0f74.png@680w_!web-note

什么是联合索引，组合索引，复合索引？

为c2和c3列建立联合索引，如下所示：

c2，c3 - > index

c3,c2 -> index

where c3=?

全职匹配

最左前缀

复合索引创建时字段顺序不一样使用效果一样吗？

我们也可以同时以多个列的大小作为排序规则，也就是同时为多个列建立索引，比方说我们想让B+树按照 c2和c3列 的大小进行排序，这个包含两层含义：

先把各个记录和页按照c2列进行排序。
在记录的c2列相同的情况下，采用c3列进行排序
B+树叶子节点处的记录由c2列、c3列和主键c1列组成
本质上也是二级索引

create index idx_c2_c3 on user (c2,c3);

什么是唯一索引？

随表一起创建索引：

CREATE TABLE customer (
    
  id INT UNSIGNED AUTO_INCREMENT,
  customer_no VARCHAR(200),
  customer_name VARCHAR(200),
    
  PRIMARY KEY(id), -- 主键索引：列设定为主键后会自动建立索引，唯一且不能为空。
  UNIQUE INDEX uk_no (customer_no), -- 唯一索引：索引列值必须唯一，允许有NULL值，且NULL可能会出现多次。
  KEY idx_name (customer_name), -- 普通索引：既不是主键，列值也不需要唯一，单纯的为了提高查询速度而创建。
  KEY idx_no_name (customer_no,customer_name) -- 复合索引：即一个索引包含多个列。
);

单独建创索引：

CREATE TABLE customer1 (
  id INT UNSIGNED,
  customer_no VARCHAR(200),
  customer_name VARCHAR(200)
);

ALTER TABLE customer1 ADD PRIMARY KEY customer1(id); -- 主键索引
CREATE UNIQUE INDEX uk_no ON customer1(customer_no); -- 唯一索引
CREATE INDEX idx_name ON customer1(customer_name);  -- 普通索引
CREATE INDEX idx_no_name ON customer1(customer_no,customer_name); -- 复合索引

什么时候使用唯一索引？

业务需求唯一字段的时候，一般不考虑性能问题

. 【强制】业务上具有唯一特性的字段，即使是多个字段的组合，也必须建成唯一索引。说明：不要以为唯一索引影响了 insert 速度，这个速度损耗可以忽略，但提高查找速度是明显的；另外，即使在应用层做了非常完善的校验控制，只要没有唯一索引，根据墨菲定律，必然有脏数据产生。

什么时候适合创建索引，什么时候不适合创建索引？

适合创建索引

频繁作为where条件语句查询字段
关联字段需要建立索引
排序字段可以建立索引
分组字段可以建立索引(因为分组前提是排序)
统计字段可以建立索引（如.count(),max()）

不适合创建索引

频繁更新的字段不适合建立索引
where，分组，排序中用不到的字段不必要建立索引
可以确定表数据非常少不需要建立索引
参与mysql函数计算的列不适合建索引

创建索引时避免有如下极端误解：

1）宁滥勿缺。认为一个查询就需要建一个索引。

2）宁缺勿滥。认为索引会消耗空间、严重拖慢更新和新增速度。

3）抵制惟一索引。认为业务的惟一性一律需要在应用层通过“先查后插”方式解决。

锁

InnoDB 有哪⼏类⾏锁？

事务

什么是数据库事务？事务的特性是什么？

事务：

是数据库操作的最小工作单元，是作为单个逻辑工作单元执行的一系列操作；
这些操作作为一个整体一起向系统提交，要么都执行、要么都不执行；
事务是一组不可再分割的操作集合（工作逻辑单元）

事务都有 ACID 特性

什么是ACID？

1 、原子性 atomicity过程的保证

只做一个步骤

1 给钱2 去买3 交回来

事务是数据库的逻辑工作单位，事务中包含的各操作要么都做，要么都不做

2 、一致性 consistency

结果的保证

保证要吃完 刚张嘴挂了，失去一致性

事务执行的结果必须是使数据库从一个一致性状态变到另一个一致性状态。因此当数据库只包含成功事务提交的结果时，就说数据库处于一致性状态。如果数据库系统运行中发生故障，有些事务尚未完成就被迫中断，这些未完成事务对数据库所做的修改有一部分已写入物理数据库，这时数据库就处于一种不正确的状态，或者说是不一致的状态。

3 、隔离性 isolation

并发事务互相干扰

不被干扰 刚张嘴别人塞了东西

一个事务的执行不能其它事务干扰。即一个事务内部的操作及使用的数据对其它并发事务是隔离的，并发执行的各个事务之间不能互相干扰。

4 、持续性 永久性 durability

保存吃到肚子里

也称永久性，指一个事务一旦提交，它对数据库中的数据的改变就应该是永久性的。接下来的其它操作或故障不应该对其执行结果有任何影响。

并发事务会有哪些问题？

多个事务并发执行一定会产生相互争夺资源的问题

Atomicity（原子性）：MySQL通过事务锁、日志和回滚等机制来实现原子性，即在一个事务中的多个操作要么全部提交成功，要么全部失败并回滚，不会出现部分操作成功、部分操作失败的情况。
Consistency（一致性）：MySQL通过数据完整性约束、事务隔离级别等机制来保证一致性。当一个事务执行完成后，数据库中的数据必须处于一致状态，即满足所有数据完整性约束（如主键约束、外键约束等），保证数据的正确性。
Isolation（隔离性）：MySQL通过事务隔离级别和锁机制来实现隔离性，即当多个事务并发访问数据库时，它们之间相互隔离，每个事务的操作不会受到其他事务的干扰，各个事务之间保持独立性。
Durability（持久性）：MySQL通过事务日志和redo log等机制来实现持久性，即当一个事务提交后，数据修改的结果必须永久保存在磁盘上，即使系统崩溃或掉电也能够恢复数据的一致性

脏读丢失修改不可重复读幻读

脏读（Dirty read） 读已提交

是一个事务在处理过程中读取了另外一个事务未提交的数据

当一个事务正在访问数据并且对其进行了修改，但是还没提交事务，这时另外一个事务也访问了这个数据，然后使用了这个数据，因为这个数据的修改还没提交到数据库，所以另外一个事务读取的数据就是“脏数据”，这种行为就是“脏读”，依据“脏数据”所做的操作可能是会出现问题的。

修改丢失（Lost of modify） 锁

*是指一个事务读取一个数据时，另外一个数据也访问了该数据，那么在第一个事务修改了这个数据之后，第二个事务也修改了这个数据。这样第一个事务内的修改结果就被丢失，这种情况就被称为**修改丢失锁

不可重复读（Unrepeatableread） 可重复读

指在一个事务内多次读取同一数据**，在这个事务还没结束时，另外一个事务也访问了这个数据并对这个数据进行了修改，那么就可能造成第一个事务两次读取的数据不一致，这种情况就被称为**不可重复读。

幻读（Phantom read）

是指同一个事务内多次查询返回的结果集总数不一样（比如增加了或者减少了行记录）。

幻读与不可重复读类似，幻读是指一个事务读取了几行数据，这个事务还没结束，接着另外一个事务插入了一些数据，在随后的查询中，第一个事务读取到的数据就会比原本读取到的多，就好像发生了幻觉一样，所以称为幻读。

不可重复读和幻读有什么区别？

不可重复读针对的是一份数据的修改

幻读针对的是行数修改

不可重复读的重点是修改，幻读的重点在于新增或者删除。

Mysql是如何避免事务并发问题的？

避免事务并发问题是需要付出性能代价的，此时和分布式系统设计一样（CAP定理及base理论），为了保证一致性就一定会牺牲性能，要做取舍

在mysql内部通过加锁的方式实现好了解决方案可供选择，就是配置事务隔离级别

什么是事务隔离级别？

事务隔离级别                    脏读     不可重复读(被修改)    幻读（删减）
读未提交（read-uncommitted）    是        是            是
不可重复读（read-committed）    否        是            是
可重复读（repeatable-read）     否        否            是
串行化（serializable）          否        否            否

默认的级别是什么？

MySQL InnoDB存储引擎默认的事务隔离级别是可重复读（REPEATABLE-READ）

MySQL 5.7 SELECT @@tx_isolation;
MySQL 8.0 SELECT @@transaction_isolation;

如何选择事务隔离级别？

隔离级别越低，事务请求的锁越少相应性能也就越高，如没有特殊要求或有错误发生，使用默认的隔离级别即可，如果系统中有高频读写并且对一致性要求高那么就需要比较高的事务隔离级别甚至串行化。

靠缓存可以提升高事务隔离级别的性能吗？

提升事务级别的目的本质是提供更高的数据一致性，如果前置有缓存，那么缓存只能提供高效读并不能保证数据及时一致性，相反的我们还需要对缓存管理有额外的开销。

Mysql事务隔离是如何实现的？

隔离的实现主要是读写锁和MVCC

什么是一致性非锁定读和锁定读？

锁定读

使用到了读写锁

读写锁是最简单直接的的事务隔离实现方式

每次读操作需要获取一个共享(读)锁，每次写操作需要获取一个写锁。
共享锁之间不会产生互斥，共享锁和写锁之间、以及写锁与写锁之间会产生互斥。
当产生锁竞争时，需要等待其中一个操作释放锁后，另一个操作才能获取到锁。

锁机制，解决的就是多个事务同时更新数据，此时必须要有一个加锁的机制

行锁（记录锁）：解决的就是多个事务同时更新一行数据
间隙锁：解决的就是多个事务同时更新多行数据

下列操作属于锁定读

select ... lock in share mode
select ... for update
insert、update、delete

非锁定读

v10 -> age=18

v11 ->age=19

v12 ->age=15

使用mvcc 多版本控制实现

说一下MVCC内部细节

https://dev.mysql.com/doc/refman/5.7/en/innodb-multi-versioning.html

undo log有什么用途呢？

事务回滚时，保证原子性和一致性。
用于MVCC快照读。

3cb5fb7fbfb5468a81fe2521fed5634d77d619c9.png@680w_!web-note Multi-Version Concurrency Control 多版本并发控制，MVCC 是一种并发控制的方法，一般在数据库管理系统中，实现对数据库的并发访问

InnoDB是一个多版本的存储引擎。它保存有关已更改行的旧版本的信息，以支持并发和回滚等事务特性。这些信息存储在一个称为回滚段的数据结构中的系统表空间或undo表空间中。参见第14.6.3.4节“撤消表空间”。InnoDB使用回滚段中的信息来执行事务回滚所需的撤消操作。它还使用这些信息构建行的早期版本，以实现一致的读取

MVCC 的实现依赖于：隐藏字段、Read View、undo log

隐藏字段

A 6-byte DB_TRX_ID 用来标识最近一次对本行记录做修改 (insert 、update) 的事务的标识符，即最后一次修改本行记录的事务 id。如果是 delete 操作，在 InnoDB 存储引擎内部也属于一次 update 操作，即更新行中的一个特殊位，将行标识为己删除，并非真正删除。
A 7-byte DB_ROLL_PTR 回滚指针，指向该行的 undo log 。如果该行未被更新，则为空.
A 6-byte DB_ROW_ID 如果没有设置主键且该表没有唯一非空索引时，InnoDB 会使用该 id 来生成聚簇索引.

Read View

不同的事务隔离级别中，当有事物在执行过程中修改了数据（更新版本号），在并发事务时需要判断一下版本链中的哪个版本是当前事务可见的。为此InnoDB有了ReadView的概念，使用ReadView来记录和隔离不同事务并发时此记录的哪些版本是对当前访问事物可见的。

undo log

除了用来回滚数据，还可以读取可见版本的数据。以此实现非锁定读

Mysql事务一致性，原子性是如何实现的？

首先是通过锁和mvcc实现了执行过程中的一致性和原子性

其次是在灾备方面通过Redo log实现，Redo log会把事务在执行过程中对数据库所做的所有修改都记录下来，在之后系统崩溃重启后可以把事务所做的任何修改都恢复出来。

Mysql事务的持久性是如何实现的？

使用Redo log保证了事务的持久性。当事务提交时，必须先将事务的所有日志写入日志文件进行持久化，就是我们常说的WAL(write ahead log)机制，如果出现断电重启便可以从redolog中恢复，如果redolog写入失败那么也就意味着修改失败整个事务也就直接回滚了。

MySQL 的隔离级别是基于锁实现的吗？

MySQL 的隔离级别基于锁和 MVCC 机制共同实现的。

SERIALIZABLE 隔离级别，是通过锁来实现的。除了 SERIALIZABLE 隔离级别，其他的隔离级别都

是基于 MVCC 实现。不过， SERIALIZABLE 之外的其他隔离级别可能也需要⽤到锁机制，就⽐如 REPEATABLE-READ

在当前读情况下需要使⽤加锁读来保证不会出现幻读。

Redo Log、Undo Log和Binlog

是MYSQL数据库中的三种日志，在处理数据恢复、备份以及主从复制等功能时，它们分别扮演着不同的角色。

Redo Log：Redo Log是InnoDB存储引擎的一种日志机制，用于记录事务对数据库所做的修改操作。当系统发生故障或崩溃时，可以通过Redo Log来恢复事务提交后所做的修改。Redo Log是物理日志，记录的是页级别的修改操作。
Undo Log：Undo Log也是InnoDB存储引擎的一种日志机制，用于回滚事务所做的修改操作。当事务执行过程中发生错误或回滚操作时，可以通过Undo Log来撤销事务所做的修改。Undo Log是逻辑日志，记录的是行级别的修改操作。
Binlog：Binlog是Mysql服务器的一种日志机制，用于记录所有的SQL语句操作，包括对数据库表的增删改操作等。当进行数据库复制或备份时，可以使用Binlog来保证数据的完整性和一致性。Binlog是逻辑日志，记录的是SQL语句操作。

在三种日志中，Redo Log和Undo Log都属于事务日志，用于确保事务的一致性和完整性。Redo Log主要用于恢复已经提交的事务操作，而Undo Log主要用于回滚未提交的事务操作。

Binlog则是服务器级别的日志，用于记录所有对数据库表的操作。Binlog可以用来同步主从服务器之间的数据，在主服务器上记录所有的更新操作，并将记录过的Binlog传递给从服务器，从服务器根据这些Binlog来执行相应的操作。

总的来说，三种日志在MYSQL中发挥不同的作用，互相补充，共同确保了数据库的安全性和完整性。