数据库部分

1、事务四大特性(ACID)

    ⑴ 原子性(Atomicity):原子性是指事务包含的所有操作要么全部成功,要么全部失败回滚,这和前面两篇博客介绍事务的功能是一样的概念,因此事务的操作如果成功就必须要完全应用到数据库,如果操作失败则不能对数据库有任何影响。

    ⑵ 一致性(Consistency):一致性是指事务必须使数据库从一个一致性状态变换到另一个一致性状态,也就是说一个事务执行之前和执行之后都必须处于一致性状态。拿转账来说,假设用户A和用户B两者的钱加起来一共是5000,那么不管A和B之间如何转账,转几次账,事务结束后两个用户的钱相加起来应该还得是5000,这就是事务的一致性。

    ⑶ 隔离性(Isolation):隔离性是当多个用户并发访问数据库时,比如操作同一张表时,数据库为每一个用户开启的事务,不能被其他事务的操作所干扰,多个并发事务之间要相互隔离。即要达到这么一种效果:对于任意两个并发的事务T1和T2,在事务T1看来,T2要么在T1开始之前就已经结束,要么在T1结束之后才开始,这样每个事务都感觉不到有其他事务在并发地执行。

    ⑷ 持久性(Durability):持久性是指一个事务一旦被提交了,那么对数据库中的数据的改变就是永久性的,即便是在数据库系统遇到故障的情况下也不会丢失提交事务的操作。例如我们在使用JDBC操作数据库时,在提交事务方法后,提示用户事务操作完成,当我们程序执行完成直到看到提示后,就可以认定事务以及正确提交,即使这时候数据库出现了问题,也必须要将我们的事务完全执行完成,否则就会造成我们看到提示事务处理完毕,但是数据库因为故障而没有执行事务的重大错误。

2、数据库隔离级别,每个级别会引发什么问题,mysql默认是哪个级别

        介绍完事务的四大特性(简称ACID),现在重点来说明下事务的隔离性,当多个线程都开启事务操作数据库中的数据时,数据库系统要能进行隔离操作,以保证各个线程获取数据的准确性,在介绍数据库提供的各种隔离级别之前,我们先看看如果不考虑事务的隔离性,会发生的几种问题:

1,脏读

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

     当一个事务正在多次修改某个数据,而在这个事务中这多次的修改都还未提交,这时一个并发的事务来访问该数据,就会造成两个事务得到的数据不一致。例如:用户A向用户B转账100元,对应SQL命令如下

    updateaccountsetmoney=money+100wherename=’B’;  (此时A通知B)

    updateaccountsetmoney=money-100wherename=’A’;

     当只执行第一条SQL时,A通知B查看账户,B发现确实钱已到账(此时即发生了脏读),而之后无论第二条SQL是否执行,只要该事务不提交,则所有操作都将回滚,那么当B以后再次查看账户时就会发现钱其实并没有转。

2,不可重复读

     不可重复读是指在对于数据库中的某个数据,一个事务范围内多次查询却返回了不同的数据值,这是由于在查询间隔,被另一个事务修改并提交了。

  例如事务T1在读取某一数据,而事务T2立马修改了这个数据并且提交事务给数据库,事务T1再次读取该数据就得到了不同的结果,发送了不可重复读。

  不可重复读和脏读的区别是,脏读是某一事务读取了另一个事务未提交的脏数据,而不可重复读则是读取了前一事务提交的数据。

  在某些情况下,不可重复读并不是问题,比如我们多次查询某个数据当然以最后查询得到的结果为主。但在另一些情况下就有可能发生问题,例如对于同一个数据A和B依次查询就可能不同,A和B就可能打起来了……

3,虚读(幻读)

    幻读是事务非独立执行时发生的一种现象。例如事务T1对一个表中所有的行的某个数据项做了从“1”修改为“2”的操作,这时事务T2又对这个表中插入了一行数据项,而这个数据项的数值还是为“1”并且提交给数据库。而操作事务T1的用户如果再查看刚刚修改的数据,会发现还有一行没有修改,其实这行是从事务T2中添加的,就好像产生幻觉一样,这就是发生了幻读。

  幻读和不可重复读都是读取了另一条已经提交的事务(这点就脏读不同),所不同的是不可重复读查询的都是同一个数据项,而幻读针对的是一批数据整体(比如数据的个数)。

  现在来看看MySQL数据库为我们提供的四种隔离级别:

  ① Serializable (串行化):可避免脏读、不可重复读、幻读的发生。

  ② Repeatable read (可重复读):可避免脏读、不可重复读的发生。

  ③ Read committed (读已提交):可避免脏读的发生。

  ④ Read uncommitted (读未提交):最低级别,任何情况都无法保证。

  以上四种隔离级别最高的是Serializable级别,最低的是Read uncommitted级别,当然级别越高,执行效率就越低。像Serializable这样的级别,就是以锁表的方式(类似于Java多线程中的锁)使得其他的线程只能在锁外等待,所以平时选用何种隔离级别应该根据实际情况。在MySQL数据库中默认的隔离级别为Repeatable read (可重复读)。

  在MySQL数据库中,支持上面四种隔离级别,默认的为Repeatable read (可重复读);而在Oracle数据库中,只支持Serializable (串行化)级别和Read committed (读已提交)这两种级别,其中默认的为Read committed级别。

  在MySQL数据库中查看当前事务的隔离级别:

        select@@tx_isolation;

        在MySQL数据库中设置事务的隔离 级别:

        set[glogal | session]transactionisolationlevel 隔离级别名称;

        settx_isolation=’隔离级别名称;’

例1:查看当前事务的隔离级别:

例2:将事务的隔离级别设置为Read uncommitted级别:

或:

记住:设置数据库的隔离级别一定要是在开启事务之前!

如果是使用JDBC对数据库的事务设置隔离级别的话,也应该是在调用Connection对象的setAutoCommit(false)方法之前。调用Connection对象的setTransactionIsolation(level)即可设置当前链接的隔离级别,至于参数level,可以使用Connection对象的字段:

在JDBC中设置隔离级别的部分代码:

后记:隔离级别的设置只对当前链接有效。对于使用MySQL命令窗口而言,一个窗口就相当于一个链接,当前窗口设置的隔离级别只对当前窗口中的事务有效;对于JDBC操作数据库来说,一个Connection对象相当于一个链接,而对于Connection对象设置的隔离级别只对该Connection对象有效,与其他链接Connection对象无关。

3、MYSQL的两种存储引擎区别(事务、锁级别等等),各自的适用场景

    MyISAM MyISAM表是独立于操作系统的,这说明可以轻松地将其从Windows服务器移植到Linux服务器;每当我们建立一个MyISAM引擎的表时,就会在本地磁盘上建立三个文件,文件名就是表明。例如,我建立了一个MyISAM引擎的tb_Demo表,那么就会生成以下三个文件:

        1.tb_demo.frm,存储表定义; 

        2.tb_demo.MYD,存储数据; 

        3.tb_demo.MYI,存储索引。

    MyISAM表无法处理事务,这就意味着有事务处理需求的表,不能使用MyISAM存储引擎。MyISAM存储引擎特别适合在以下几种情况下使用:

        1.选择密集型的表。MyISAM存储引擎在筛选大量数据时非常迅速,这是它最突出的优点。 

        2.插入密集型的表。MyISAM的并发插入特性允许同时选择和插入数据。例如:MyISAM存储引擎很适合管理邮件或Web服务器日志数据。

    (1)特性   

        不支持事务:MyISAM存储引擎不支持事务,所以对事务有要求的业务场景不能使用

        表级锁定:其锁定机制是表级索引,这虽然可以让锁定的实现成本很小但是也同时大大降低了其并发性能   

        读写互相阻塞:不仅会在写入的时候阻塞读取,MyISAM还会在读取的时候阻塞写入,但读本身并不会阻塞另外的读   

        只会缓存索引:MyISAM可以通过key_buffer缓存以大大提高访问性能减少磁盘IO,但是这个缓存区只会缓存索引,而不会缓存数据

    (2)适用场景   

        不需要事务支持(不支持)  ,并发相对较低(锁定机制问题) ;数据修改相对较少(阻塞问题);以读为主;数据一致性要求不是非常高    

    (3)最佳实践  

        尽量索引(缓存机制)  ,调整读写优先级;根据实际需求确保重要操作更优先;启用延迟插入改善大批量写入性能;尽量顺序操作让insert数据都写入到尾部,减少阻塞;分解大的操作,降低单个操作的阻塞时间;降低并发数,某些高并发场景通过应用来进行排队机制;对于相对静态的数据,充分利用Query Cache可以极大的提高访问效率;MyISAM的Count只有在全表扫描的时候特别高效,带有其他条件的count都需要进行实际的数据访问      

 InnoDB

    InnoDB是一个健壮的事务型存储引擎,在以下场合下,使用InnoDB是最理想的选择:

        更新密集的表。InnoDB存储引擎特别适合处理多重并发的更新请求。 

        事务。InnoDB存储引擎是支持事务的标准MySQL存储引擎。 

        自动灾难恢复。与其它存储引擎不同,InnoDB表能够自动从灾难中恢复。 

        外键约束。MySQL支持外键的存储引擎只有InnoDB。 

        支持自动增加列AUTO_INCREMENT属性。

        一般来说,如果需要事务支持,并且有较高的并发读取频率,InnoDB是不错的选择。

    (1)特性   

        具有较好的事务支持:支持4个事务隔离级别,支持多版本读 

        行级锁定:通过索引实现,全表扫描仍然会是表锁,注意间隙锁的影响   

        读写阻塞与事务隔离级别相关   

        具有非常高效的缓存特性:能缓存索引,也能缓存数据

        整个表和主键以Cluster方式存储,组成一颗平衡树   

        所有Secondary Index都会保存主键信息    

    (2)适用场景   

        需要事务支持(具有较好的事务特性) ;行级锁定对高并发有很好的适应能力,但需要确保查询是通过索引完成;数据更新较为频繁的场景    ;数据一致性要求较高 ;硬件设备内存较大,可以利用InnoDB较好的缓存能力来提高内存利用率,尽可能减少磁盘 IO    

   (3)最佳实践   

        主键尽可能小,避免给Secondary index带来过大的空间负担;避免全表扫描,因为会使用表锁;尽可能缓存所有的索引和数据,提高响应速度;在大批量小插入的时候,尽量自己控制事务而不要使用autocommit自动提交;合理设置innodb_flush_log_at_trx_commit参数值,不要过度追求安全性 ;避免主键更新,因为这会带来大量的数据移动。

        主要区别:

        MyIASM是非事务安全的,而InnoDB是事务安全的

        MyIASM锁的粒度是表级的,而InnoDB支持行级锁

        MyIASM支持全文类型索引,而InnoDB不支持全文索引

        MyIASM相对简单,效率上要优于InnoDB,小型应用可以考虑使用MyIASM

        MyIASM表保存成文件形式,跨平台使用更加方便

        应用场景:

        MyIASM管理非事务表,提供高速存储和检索以及全文搜索能力,如果再应用中执行大量select操作,应该选择MyIASM

        InnoDB用于事务处理,具有ACID事务支持等特性,如果在应用中执行大量insert和update操作,应该选择InnoDB

4、数据库的优化(从sql语句优化和索引两个部分回答)

        http://blog.csdn.net/yzllz001/article/details/54848513

        https://www.cnblogs.com/zishengY/p/6892345.html

5、B+索引数据结构,和B树的区别

        https://www.cnblogs.com/George1994/p/7008732.html

6、聚集索引和非聚集索引区别

        聚集索引:搜索码顺序连续、物理存储顺序连续且与抖索码顺序相同。(聚集索引可以建立在任何键上,但还是主键居多,考虑主键唯一性带来的性能;一个表只能有一个聚集索引,因为一个表的物理顺序只有一种情况,所以,对应的聚集索引只能有一个。聚集索引类似数组)

        非聚集索引:搜索码顺序连续、物理存储顺序不连续。(非聚集索引类似链表;因为非聚集索引是逻辑上的连续,所以一个表可以有多个非聚集索引。)

7、有哪些锁(乐观锁悲观锁),select时怎么加排它锁

        http://blog.itpub.net/11627468/viewspace-1788399/


        (1)乐观锁:在关系数据库管理系统里,乐观并发控制(又名“乐观锁”,Optimistic Concurrency Control,缩写“OCC”)是一种并发控制的方法。它假设多用户并发的事务在处理时不会彼此互相影响,各事务能够在不产生锁的情况下处理各自影响的那部分数据。在提交数据更新之前,每个事务会先检查在该事务读取数据后,有没有其他事务又修改了该数据。如果其他事务有更新的话,正在提交的事务会进行回滚。

        (2)悲观锁:悲观锁,正如其名,它指的是对数据被外界(包括本系统当前的其他事务,以及来自外部系统的事务处理)修改持保守态度(悲观),因此,在整个数据处理过程中,将数据处于锁定状态。 悲观锁的实现,往往依靠数据库提供的锁机制 (也只有数据库层提供的锁机制才能真正保证数据访问的排他性,否则,即使在本系统中实现了加锁机制,也无法保证外部系统不会修改数据)

        (3)排他锁和共享锁 :在数据库中有两种基本的锁类型:排它锁(Exclusive Locks,即X锁)和共享锁(Share Locks,即S锁)。当数据对象被加上排它锁时,其他的事务不能对它读取和修改。加了共享锁的数据对象可以被其他事务读取,但不能修改。数据库利用这两种基本的锁类型来对数据库的事务进行并发控制。

        (4)表级锁和行级锁:DML锁的目的在于保证并发情况下的数据完整性,主要包括TM锁和TX锁,其中TM锁称为表级锁,TX锁称为事务锁或行级锁。当Oracle执行DML语句时,系统自动在所要操作的表上申请TM类型的锁。当TM锁获得后,系统再自动申请TX类型的锁,并将实际锁定的数据行的锁标志位进行置位。这样在事务加锁前检查TX锁相容性时就不用再逐行检查锁标志,而只需检查TM锁模式的相容性即可,大大提高了系统的效率。TM锁包括了SS、SX、S、X等多种模式,在数据库中用0-6来表示。不同的SQL操作产生不同类型的TM锁。

        select ....for update

8、SQL和NoSQL的区别

        http://blog.csdn.net/xlgen157387/article/details/47908797

        http://blog.csdn.net/han_cui/article/details/60765969

        从数据结构出发对比关系型数据库和文档型数据库:https://crzidea.com/2016/08/08/relational-database-vs-document-oriented-database-in-data-structure/

9、数据库三范式,根据某个场景设计数据表(可以通过手绘ER图)

        https://www.zhihu.com/question/24696366

10、数据库的主从复制

        http://www.cnblogs.com/exceptioneye/p/5042133.html

11、使用explain优化sql和索引

        https://www.cnblogs.com/chenxqNo01/p/6371075.html

        http://blog.csdn.net/zc474235918/article/details/74923614

12、内连接与外链接

        http://dataunion.org/11954.html

*1、MVCC机制

        http://blog.csdn.net/whoamiyang/article/details/51901888

        https://www.cnblogs.com/phpper/p/6937650.html

*2、根据具体场景,说明版本控制机制

        http://www.kuqin.com/system-analysis/20120319/319108.html

*3、varchar和char的使用场景

        http://www.jb51.net/article/55366.htm

*4、数据库死锁的原因和解决方法

        https://www.cnblogs.com/sivkun/p/7518540.html

Redis

1、redis和Memcach

        http://blog.csdn.net/langzi7758521/article/details/51672028

2、redis队列应用场景

        https://www.cnblogs.com/xiaoxi/p/7007695.html

4、分布式使用场景(储存session等)

5、发布/订阅使用场景

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

推荐阅读更多精彩内容