JAVA面试汇总(五)数据库(三)

写了好几天理财的,今天重回技术,写一写数据库,今天最后一篇数据库。这一篇写的脑袋疼,全是理论知识。

11.如何进行SQL优化

(1)所有的查询SQL建议按照索引查询,查询非常频繁的如果不走索引,查询速度慢,会导致服务响应慢。客户取消后再次请求操作,进而会导致更多的查询甚至导致服务宕机。
(2)update时候,尽量按照primary key作为条件来更新,效率更高,退而求其次也要按照索引更新。
(3)尽量不要频繁更新索引字段,会导致频繁更改索引存储,更新效率也低。
(4)近期发现的一个问题,由于要把全表一百万的数据更新,另外每次查询都是全表查询,自己限制在了100条数据,也就是sql的limit 100,这样每查询一次几秒,我循环20000次,这样损耗了我8个小时才循环完毕,因此如果是全表查询,记得limit要修改的高一些,limit 10000,实际上和limit 100的时间差不多,即使几秒钟,但是循环次数少了,反而减少了很多时间。
(5)大字段上不能建立索引,因为为了这种字段建立索引,会占用大量空间,反而效率不高。
(6)索引字段上使用函数后,是无法走索引的。

12.完整性约束包括哪些?

(1)实体完整性:规定表的每一行在表中是唯一的实体。例如,商品表,那么每一条数据代表唯一一件商品,不能另外再存在一条数据也是这一件商品了。
(2)域完整性:是指表中的列必须满足某种特定的数据类型约束,其中约束又包括取值范围、精度等规定。例如,性别只能是男女未知,不能再有其他了。
(3)参照完整性:是指两个表的主关键字和外关键字的数据应一致,保证了表之间的数据的一致性,防止了数据丢失或无意义的数据在数据库中扩散。例如,表A的外键字段COLUMN_A,是B表的主键,表A的COLUMN_A的数据必须是表B中的数据,不能出现表B中没有的数据。
(4) 用户定义的完整性:不同的关系数据库系统根据其应用环境的不同,往往还需要一些特殊的约束条件。用户定义的完整性即是针对某个特定关系数据库的约束条件,它反映某一具体应用必须满足的语义要求。例如,一些非空约束、唯一约束、检查约束、主键约束、外键约束。

13.Mysql 的存储引擎,myisam和innodb的区别。

(1)存储:Myisam,每个MyISAM在磁盘上存储成三个文件。文件的名字以表的名字开头,扩展名指出文件类型。.frm文件存储表定义。数据文件的扩展名为.MYD (MYData)。索引文件的扩展名是.MYI (MYIndex)。Innodb,基于磁盘的资源是InnoDB表空间数据文件和它的日志文件,InnoDB表的大小只受限于操作系统文件的大小,一般为2GB。这个说的实际不对,当表空间不够时候可以再增加新的表空间,innodb表大小是可以超过2GB的。
(2)事务:MyISAM类型的表强调的是性能,其执行速度比InnoDB类型更快,但是不提供事务支持;InnoDB提供事务支持事务,外部键(foreign key)等高级数据库功能。
(3)增删改查:如果执行大量的SELECT,MyISAM更快。大量修改插入操作时候,InnoDB效率更高。DELETE FROM table时,InnoDB不会重新建立表,而是一行一行的删除,这块不懂了,那么MyISAM每次删除完成数据把其他的数据是重新建立表文件,删除旧文件?
(4)AUTO_INCREMENT:MyISAM,每表一个AUTO_INCREMEN列的内部处理,MyISAM为INSERT和UPDATE操作自动更新这一列,效率更高,AUTO_INCREMENT类型的字段可以和其他字段一起建立联合索引;InnoDB,AUTO_INCREMEN字段有自动增长计数器,存储在主内存中,AUTO_INCREMENT类型的字段必须有该字段的独立索引。
(5)行数:MyISAM存储了行数,InnoDB没有存储行数,因此select count(*)时候,MyISAM查询行数记录就可以返回,但是InnoDB需要全表查询一遍。
(6)锁,MyISAM的增删改查都是表锁;InnoDB提供行锁,不加锁读取,也有表锁。

14.MYSQL的主从延迟怎么解决

(1)网络延迟导致的主从延迟,优化网络,增加带宽,满足网络同步的速度要求。
(2)从数据库配置低,当主数据库大量并发下,从数据库无法及时完成数据库操作,因此需要增加从数据库配置,已达到大量并发的同步操作。
(3)Slave调整参数,关闭binlog,能够不将binlog同步到磁盘,修改innodb_flush_log_at_trx_commit参数值为0,不把日志flush到磁盘,这两项修改能使从数据库的性能提升,但是数据安全性有所下降。

15.MVCC的含义,如何实现的

(1)多版本并发控制,读不加锁,读写不冲突。
(2)表中有一个隐藏列,trx_id操作的事务id,每次记录操作增删改查,都会对这个值修改,修改为当前操作的事务id。
(3)另外MVCC记录了几个事务ID,分别是m_ids:在当前事务开始时,当前系统中活跃的事务id列表;min_trx_id:在当前事务开始时,当前系统中活跃的最小的事务id,也就是m_ids中的最小值;max_trx_id:在当前事务开始时,系统应该分配给下一个事务的事务id值;creator_trx_id:当前事务id。
(4)上面四个id记住后,就可以来继续解释了,如果被访问的数据的trx_id=creator_trx_id,表示这条数据是自己当前事务修改的,当然可以读取了;如果trx_id<min_trx_id,表示这条数据比当前事务开始时活跃的最早的事务还要早,也就是在当前事务之前这条数据已经修改完了,同样是可以读取的;trx_id>=max_trx_id,表示当前事务开始时,最大的活跃事务比这条数据的trx_id要早,说明当前事务开始后,这条数据才修改的,说明无法读取这条数据,需要找到之前的事务版本(最接近当前事务id的一条记录)来展示,如果没有早于当前事务的任何一条记录,则无数据。

16.事务是如何通过日志来实现的,说得越深入越好

(1)先来了解undo log和redo log
(2)undo Log是实现事务的原子性的关键,也就是修改数据时的备份记录,如果出现问题,方便回滚数据到原始状态,例如,事务开始,数据A的COLUMN_A当前值为10,update操作+10,首先将数据A的状态记录到undo Log内存中,COLUMN_A的值为10,然后修改内存中的数据A,COLUMN_A修改为20,下一步将undo log写入到磁盘中,最后一步将内存中的修改记录写入到磁盘,也就是COLUMN_A为20的记录存到磁盘中,事务提交,事务最终结束。在最终的事务提交前失败,都会进行回滚操作,将数据以及内存的记录恢复到之前的状态。
(3)redo log通常是物理日志,记录的是数据页的物理修改,而不是某一行或某几行修改成怎样怎样,它用来恢复提交后的物理数据页(恢复数据页,且只能恢复到最后一次提交的位置)。Redo Log记录的是新数据的备份。它是在事务提交之前,将新数据状态记录到redo Log中,记录的数据的最新状态。例如上面的+10操作,实际上是在修改记录写入到磁盘后,记录redo Log,之后再提交事务。

17.锁的优化策略

(1)所有SQL语句尽量都通过索引执行,避免行级锁升级成为页级锁甚至表级锁。
(2)合理设计索引,尽量缩小行锁的锁定范围,范围过大可能导致其他查询条件的执行。
(3)避免使用通过一定范围的查询条件,因为会产生页级锁甚至表锁,影响效率。
(4)使用事务时,事务执行时间不要太长,时间过长可能影响其他的查询或者增删改查的执行。
(5)避免产生死锁

18.乐观锁和悲观锁是什么,INNODB的标准行级锁有哪2种,解释其含义。

(1)乐观锁,用数据版本(Version)记录机制实现,这是乐观锁最常用的一种实现方式。何谓数据版本?即为数据增加一个版本标识,一般是通过为数据库表增加一个数字类型的 “version” 字段来实现。当读取数据时,将version字段的值一同读出,数据每更新一次,对此version值加1。当我们提交更新的时候,判断数据库表对应记录的当前版本信息与第一次取出来的version值进行比对,如果数据库表当前版本号与第一次取出来的version值相等,则予以更新,否则认为是过期数据,更新失败。
(2)悲观锁就是在操作数据时,认为此操作会出现数据冲突,所以在进行每次操作时都要通过获取锁才能进行对相同数据的操作,这点跟java中的synchronized很相似,所以悲观锁需要耗费较多的时间。另外与乐观锁相对应的,悲观锁是由数据库自己实现的。
(3)行级锁标准有共享锁和排他锁,这两个都是悲观锁。
(4)共享锁,允许多个事务读取数据,但是禁止排他锁来抢占。
(5)排他锁,抢占成功的排他锁事务可以更新数据,其他事务均不可执行,禁止共享锁或者其他排他锁抢占,直到当前事务完成后才可以。

19. db 里面 user 和 schema的区别

(1)user是指具体登陆到数据库的用户,需要有账号密码
(2)schema指的是具体的数据库,同一个数据库实例可以建立多个数据库schema
(3)具体user可以操作哪些schema,需要dba用户为该user赋权,才可以在schema中建表删表(DDL操作)

20. 主键和外键的区别

(1)主键是表数据的唯一标识,每条数据都是唯一的标识对应的字段,比如班级表,班级ID就是唯一的标识。
(2)外键是当前表中对应其他表数据关联的字段,表示当前数据与其他表数据的关联关系,比如学生表中的班级ID,这个就可以是外键,对应关联班级表中的信息。
(3)主键在表中数据不能重复;外键字段在当前表可以重复,例如几个学生都在班级1中。

谢各位的阅读,谢谢您动动手指点赞,万分感谢各位。另外以下是我之前写过的文章,感兴趣的可以点进去继续阅读。

历史文章

Hadoop系列-入门安装
Hadoop系列-HDFS命令
Hadoop系列-Hive安装
Hadoop系列-Hive数据库常见SQL命令
Hadoop系列-HBase数据库
Hadoop系列-HBase数据库(二)
Hadoop系列-HBase数据库JAVA篇
Hadoop系列-Spark安装以及HelloWorld
JAVA面试汇总(五)数据库(一)
JAVA面试汇总(五)数据库(二)
JAVA面试汇总(五)数据库(三)
JAVA面试汇总(四)JVM(一)
JAVA面试汇总(四)JVM(二)
JAVA面试汇总(四)JVM(三)
JAVA面试汇总(三)集合(一)
JAVA面试汇总(三)集合(二)
JAVA面试汇总(三)集合(三)
JAVA面试汇总(三)集合(四)
JAVA面试汇总(二)多线程(一)
JAVA面试汇总(二)多线程(二)
JAVA面试汇总(二)多线程(三)
JAVA面试汇总(二)多线程(四)
JAVA面试汇总(二)多线程(五)
JAVA面试汇总(二)多线程(六)
JAVA面试汇总(二)多线程(七)
JAVA面试汇总(一)Java基础知识

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 216,372评论 6 498
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 92,368评论 3 392
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 162,415评论 0 353
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 58,157评论 1 292
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 67,171评论 6 388
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 51,125评论 1 297
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 40,028评论 3 417
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 38,887评论 0 274
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 45,310评论 1 310
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,533评论 2 332
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 39,690评论 1 348
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 35,411评论 5 343
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 41,004评论 3 325
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,659评论 0 22
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,812评论 1 268
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 47,693评论 2 368
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 44,577评论 2 353

推荐阅读更多精彩内容