技术交流QQ群:1027579432,欢迎你的加入!

  • 1.事务故障可以通过运行日志进行恢复;
  • 2.检查点是DBMS强制使内存DB Buffer中的内容与介质DB中的内容保持一致的时刻点。
  • 3.为了提高数据的查询效率,需要在数据库中建立索引,则下列设计索引的原则是:
    • 表的某个字段值得离散度越高,该字段越适合选作索引的关键字。主键字段以及唯一性约束字段适合选作索引的关键字,原因就是这些字段的值非常离散。
    • 占用存储空间少的字段更适合选作索引的关键字。例如,与字符串相比,整数字段占用的存储空间较少,因此,较为适合选作索引关键字。
    • 存储空间固定的字段更适合选作索引的关键字。与text类型的字段相比,char类型的字段较为适合选作索引关键字。
    • where子句中经常使用的字段应该创建索引,分组字段或者排序字段应该创建索引,两个表的连接字段应该创建索引。
    • 更新频繁的字段不适合创建索引,不会出现在where子句中的字段不应该创建索引。
    • 最左前缀原则。
    • 尽量使用前缀索引。
  • 4.如果数据库表的存储引擎是MyISAM,那么创建主键的约束的同时,MySQL会自动创建主键索引。如果数据库表的存储引擎是InnoDB,那么创建主键约束的同时,MySQL会自动创建聚簇索引。
  • 5.数据库系统的核心是数据库管理系统DBMS。数据库系统一般由数据库、数据库管理系统(DBMS)、应用系统、数据库管理员和用户构成。

一.InnoDB和MylSAM存储引擎对比

  • MyISAM是MySQL的默认数据库引擎(5.5版之前),由早期的ISAM(Indexed Sequential Access Method:有索引的顺序访问方法)所改良。虽然性能极佳,但却有一个缺点:不支持事务处理(transaction)。不过,在这几年的发展下,MySQL也导入了InnoDB(另一种数据库引擎),以强化参考完整性与并发违规处理机制,后来就逐渐取代MyISAM。
  • InnoDB,是MySQL的数据库引擎之一,为MySQL AB发布binary的标准之一。InnoDB由Innobase Oy公司所开发,2006年五月时由甲骨文公司并购。与传统的ISAM与MyISAM相比,InnoDB的最大特色就是支持了ACID兼容的事务(Transaction)功能,类似于PostgreSQL。目前InnoDB采用双轨制授权,一是GPL授权,另一是专有软件授权。
  • MyISAM和InnoDB两者之间有着明显区别:
    • a.事务支持:MyISAM不支持事务,而InnoDB支持。InnoDB的AUTOCOMMIT默认是打开的,即每条SQL语句会默认被封装成一个事务,自动提交,这样会影响速度,所以最好是把多条SQL语句显示放在begin和commit之间,组成一个事务去提交;MyISAM是非事务安全型的,而InnoDB是事务安全型的,默认开启自动提交,宜合并事务,一同提交,减小数据库多次提交导致的开销,大大提高性能。
    • b.存储结构:MyISAM:每个MyISAM在磁盘上存储成三个文件。第一个文件的名字以表的名字开始,扩展名指出文件类型。.frm文件存储表定义。数据文件的扩展名为.MYD (MYData)。索引文件的扩展名是.MYI (MYIndex);InnoDB:所有的表都保存在同一个数据文件中(也可能是多个文件,或者是独立的表空间文件),InnoDB表的大小只受限于操作系统文件的大小,一般为2GB。
    • c.存储空间:MyISAM:可被压缩,存储空间较小。支持三种不同的存储格式:静态表(默认,但是注意数据末尾不能有空格,会被去掉)、动态表、压缩表;InnoDB:需要更多的内存和存储,它会在主内存中建立其专用的缓冲池用于高速缓冲数据和索引。
    • d.可移植性、备份及恢复:MyISAM:数据是以文件的形式存储,所以在跨平台的数据转移中会很方便。在备份和恢复时可单独针对某个表进行操作;InnoDB:免费的方案可以是拷贝数据文件、备份 binlog,或者用mysqldump,在数据量达到几十G的时候就相对痛苦了。
    • e.事务支持:MyISAM:强调的是性能,每次查询具有原子性,其执行数度比InnoDB类型更快,但是不提供事务支持;InnoDB:提供事务支持事务,外部键等高级数据库功能。具有事务(commit)、回滚(rollback)和崩溃修复能力(crash recovery capabilities)的事务安全(transaction-safe (ACID compliant))型表。
    • f.AUTO_INCREMENT:MyISAM:可以和其他字段一起建立联合索引。引擎的自动增长列必须是索引,如果是组合索引,自动增长可以不是第一列,他可以根据前面几列进行排序后递增;InnoDB:InnoDB中必须包含只有该字段的索引。引擎的自动增长列必须是索引,如果是组合索引也必须是组合索引的第一列。
    • g.表锁差异:MyISAM:只支持表级锁,用户在操作myisam表时,select,update,delete,insert语句都会给表自动加锁,如果加锁以后的表满足insert并发的情况下,可以在表的尾部插入新的数据;InnoDB:支持事务和行级锁,是innodb的最大特色。行锁大幅度提高了多用户并发操作的新能。但是InnoDB的行锁,只是在WHERE的主键是有效的,非主键的WHERE都会锁全表的。MyISAM锁的粒度是表级,而InnoDB支持行级锁定。简单来说就是, InnoDB支持数据行锁定,而MyISAM不支持行锁定,只支持锁定整个表。即MyISAM同一个表上的读锁和写锁是互斥的,MyISAM并发读写时如果等待队列中既有读请求又有写请求,默认写请求的优先级高,即使读请求先到,所以MyISAM不适合于有大量查询和修改并存的情况,那样查询进程会长时间阻塞。因为MyISAM是锁表,所以某项读操作比较耗时会使其他写进程饿死。
    • h.全文索引:MyISAM:支持(FULLTEXT类型的)全文索引;InnoDB:不支持(FULLTEXT类型的)全文索引,但是innodb可以使用sphinx插件支持全文索引,并且效果更好。全文索引是指对char、varchar和text中的每个词(停用词除外)建立倒排序索引。MyISAM的全文索引其实没啥用,因为它不支持中文分词,必须由使用者分词后加入空格再写到数据表里,而且少于4个汉字的词会和停用词一样被忽略掉。另外,MyIsam索引和数据分离,InnoDB在一起,MyIsam天生非聚簇索引,最多有一个unique的性质,InnoDB的数据文件本身就是主键索引文件,这样的索引被称为“聚簇索引”。
    • i.表主键:MyISAM:允许没有任何索引和主键的表存在,索引都是保存行的地址;InnoDB:如果没有设定主键或者非空唯一索引,就会自动生成一个6字节的主键(用户不可见),数据是主索引的一部分,附加索引保存的是主索引的值。InnoDB的主键范围更大,最大是MyISAM的2倍。
    • j.表的具体行数:MyISAM:保存有表的总行数,如果select count(*) from table;会直接取出出该值;InnoDB:没有保存表的总行数(只能遍历),如果使用select count(*) from table;就会遍历整个表,消耗相当大,但是在加了wehre条件后,myisam和innodb处理的方式都一样。
    • k.CURD操作:MyISAM:如果执行大量的SELECT,MyISAM是更好的选择;InnoDB:如果你的数据执行大量的INSERT或UPDATE,出于性能方面的考虑,应该使用InnoDB表。DELETE 从性能上InnoDB更优,但DELETE FROM table时,InnoDB不会重新建立表,而是一行一行的删除,在innodb上如果要清空保存有大量数据的表,最好使用truncate table这个命令。
    • l.外键:MyISAM:不支持;InnoDB:支持
    • m.查询效率:没有where的count(*)使用MyISAM要比InnoDB快得多。因为MyISAM内置了一个计数器,count(*)时它直接从计数器中读,而InnoDB必须扫描全表。所以在InnoDB上执行count(*)时一般要伴随where,且where中要包含主键以外的索引列。为什么这里特别强调“主键以外”?因为InnoDB中primary index是和raw data存放在一起的,而secondary index则是单独存放,然后有个指针指向primary key。所以只是count(*)的话使用secondary index扫描更快,而primary key则主要在扫描索引同时要返回raw data时的作用较大。MyISAM相对简单,所以在效率上要优于InnoDB,小型应用可以考虑使用MyISAM。
  • 总结:通过上述的分析,基本上可以考虑使用InnoDB来替代MyISAM引擎了,原因是InnoDB自身很多良好的特点,比如事务支持、存储 过程、视图、行级锁定等等,在并发很多的情况下,相信InnoDB的表现肯定要比MyISAM强很多。另外,任何一种表都不是万能的,只用恰当的针对业务类型来选择合适的表类型,才能最大的发挥MySQL的性能优势。如果不是很复杂的Web应用,非关键应用,还是可以继续考虑MyISAM的,这个具体情况可以自己斟酌。
  • MyISAM和InnoDB两者的应用场景:
    • a.MyISAM管理非事务表。它提供高速存储和检索,以及全文搜索能力。如果应用中需要执行大量的SELECT查询,那么MyISAM是更好的选择。
    • b.InnoDB用于事务处理应用程序,具有众多特性,包括ACID事务支持。如果应用中需要执行大量的INSERT或UPDATE操作,则应该使用InnoDB,这样可以提高多用户并发操作的性能。

2.数据库中的范式定义

  • 第一范式(1NF):强调的是列的原子性,即列不能够再分成其他几列。
  • 第二范式(2NF):首先是 1NF,另外包含两部分内容,一是表必须有一个主键;二是没有包含在主键中的列必须完全依赖于主键,而不能只依赖于主键的一部分。
  • 第三范式(3NF):首先是 2NF,另外非主键列必须直接依赖于主键,不能存在传递依赖。即不能存在:非主键列 A 依赖于非主键列 B,非主键列 B 依赖于主键的情况。

3.数据库中的模式介绍

  • 三级模式结构:外模式、模式和内模式
  • 模式:也称逻辑模式,是数据库中全体数据的逻辑结构和特征的描述,是所有用户的公共数据视图。
  • 外模式:也称子模式(Subschema)或用户模式,是数据库用户(包括应用程序员和最终用户)能够看见和使用的局部数据的逻辑结构和特征的描述,是数据库用户的数据视图,是与某一应用有关的数据的逻辑表示。
  • 内模式:也称存储模式(Storage Schema),它是数据物理结构和存储方式的描述,是数据在数据库内部的表示方式(例如,记录的存储方式是顺序存储、按照B树结构存储还是按hash方法存储;索引按照什么方式组织;数据是否压缩存储,是否加密;数据的存储记录结构有何规定)。一个数据库只有一个内模式!

4.数据库保护

  • 数据库保护又叫做数据库控制,是通过四方面实现的,即安全性控制,完整性控制,并发性控制和数据恢复。

5.SQL语言分类

  • DDL:数据库模式定义语言,关键字:create
  • DML:数据操作语言,关键字:Insert、delete、update
  • DCL:数据库控制语言 ,关键字:grant、remove
  • DQL:数据库查询语言,关键字:select

6.在视图上使用INSERT语句添加数据时,要符合以下规则:

  • 使用INSERT语句向数据表中插入数据时,用户必须有插入数据的权利。
  • 由于视图只引用表中的部分字段,所以通过视图插入数据时只能明确指定视图中引用的字段的取值。而那些表中并未引用的字段,必须知道在没有指定取值的情况下如何填充数据,因此视图中未引用的字段必须具备下列条件之一
    • 该字段允许空值。
    • 该字段设有默认值。
    • 该字段是标识字段,可根据标识种子和标识增量自动填充数据。
  • 该字段的数据类型为timestamp或uniqueidentifier。
  • 视图中不能包含多个字段值的组合,或者包含使用统计函数的结果。
  • 视图中不能包含DISTINCT或GROUP BY子句
  • 如果视图中使用了WITH CHECK OPTION,那么该子句将检查插入的数据是否符合视图定义中SELECT语句所设置的条件。如果插入的数据不符合该条件,SQL Server会拒绝插入数据。
  • 不能在一个语句中对多个基础表使用数据修改语句。因此,如果要向一个引用了多个数据表的视图添加数据时,必须使用多个INSERT语句进行添加。

7.关系的约束条件也称为关系的数据完整性规则。它是对关系的一些限制和规定。它包括实体完整性、参照完整性和用户定义完整性。

  • 实体完整性:这条规定的现实意义是,关系模型对应的是现实世界的数据实体,而关键字是实体惟一性的表现,没有关键字就没有实体.所有关键字不能是空值。这是实体存在的最基本的前提,所以称之为实体完整性。
  • 参照完整性:参照完整性规则也可称为引用完整性规则。这条规则是对关系外部关键字的规定,要求外部关键字的取值必须是客观存在的,即不允许在一个关系中引用另一个关系不存在的元组。
  • 用户定义完整性:由用户根据实际情况,对数据库中数据的内容所作的规定称为用户定义的完整性规则。通过这些限制数据库中接受符合完整性约束条件的数据值,不接受违反约束条件的数据,从而保证数据库的数据合理可靠。

8.一个完整的 数据库设计 一般分为以下六个阶段

  • 需求分析:分析用户的需求,包括数据、功能和性能需求;
  • 概念结构设计:主要采用E-R模型进行设计,包括画E-R图;
  • 逻辑结构设计:通过将E-R图转换成表,实现从E-R模型到关系模型 的转换,进行关系规范化
  • 数据库物理设计:主要是为所设计的数据库选择合适的 存储结构 和存取路径;
  • 数据库的实施:包括编程、测试和试运行;
  • 数据库运行与维护:系统的运行与数据库的日常维护。

9.并发带来的数据不一致主要包括 丢失修改、不可重复读和读脏数据

  • 丢失修改:两个事务各自的修改导致对方的操作无效;两个事务T1和T2读入同一数据并修改,T2提交的结果破坏了T1提交的结果,导致T1的修改被丢失。
  • 不可重复读:一个事务正在读时,另外一个事务对其进行修改了,导致再读的时候不知道哪个为真;事务T1读取某一数据后,事务T2执行更新操作,使T1无法再现前一次读取结果
  • 读污:事务的回滚操作导致另外一个事务在此期间所读到的数据没有价值了。读“脏”数据是指事务T1修改某一数据,并将其写回磁盘,事务T2读取同一数据后,T1由于某种原因被撤销,则T2读到的数据就是“脏”数据。