MSQL常见面试问题

Mysql

一、数据库基础

1.1 sql 语句

1.2 数据库优化

SQL 优化

1、我们在进行数据库查询时首先应该避免的是全表扫描,限定数据的范围。比如查询某一段时间的数据。

2、对于使用where 或者 order by 的列，我们应该建立索引。

3、通过explain显示了mysql如何使用索引来处理select语句以及连接表，可以帮助选择更好的索引和写出更优化的查询语句。

4、同时也应该避免一些索引失效的问题。

5、更多的时候是需要用到一系列的语句来完成某种工作。在这种情况下，当这个语句块中的某一条语句运行出错的时候，整个语句块的操作就会变得不确定起来。要避免这种情况，就应该使用事务。

数据库优化

当MySQL单表记录数过大时，数据库的CRUD性能会明显下降，一些常见的优化措施如下：1、读/写分离：通过主从复制实现读写分离，主库负责写，从库负责读；2、缓存：使用MySQL的缓存，另外对重量级、更新少的数据可以考虑使用应用级别的缓存；3、通过分库分表的方式进行优化，主要有垂直分表和水平分表

1.3 数据库范式

1、第一范式：属性不可分割，每个字段都应该是不可再拆分的。比如一个字段是姓名（NAME）。

2、第二范式：在第一范式的基础之上更进一层。第二范式需要确保数据库表中的每一列都和主键相关，而不能只与主键的某一部分相关（主要针对联合主键而言）记住主键约束

3、第三范式：第三范式需要确保数据表中的每一列数据都和主键直接相关，而不能间接相关。外键约束比如在设计一个订单数据表的时候，可以将客户编号作为一个外键和订单表建立相应的关系。而不可以在订单表中添加关于客户其它信息（比如姓名、所属公司等）的字段。如下面这两个表所示的设计就是一个满足第三范式的数据库表。

1.4 分库分表

垂直拆分 垂直分表:也就是“大表拆小表”，基于列字段进行的。一般是表中的字段较多，将不常用的，数据较大，长度较长的拆分到“扩展表“。一般是针对那种几百列的大表，也避免查询时，数据量太大造成的“跨页”问题。
垂直分库:针对的是一个系统中的不同业务进行拆分，比如用户User一个库，商品Producet一个库，订单Order一个库。 切分后，要放在多个服务器上，而不是一个服务器上。
为什么？我们想象一下，一个购物网站对外提供服务，会有用户，商品，订单等的CRUD。没拆分之前,全部都是落到单一的库上的，这会让数据库的单库处理能力成为瓶颈。按垂直分库后，如果还是放在一个数据库服务器上，随着用户量增大，这会让单个数据库的处理能力成为瓶颈，还有单个服务器的磁盘空间，内存，tps等非常吃紧。所以我们要拆分到多个服务器上，这样上面的问题都解决了，以后也不会面对单机资源问题。

水平拆分水平分表:针对数据量巨大的单张表（比如订单表），按照某种规则（RANGE,HASH取模等），切分到多张表里面去。但是这些表还是在同一个库中，所以库级别的数据库操作还是有IO瓶颈。不建议采用。
水平分库:将单张表的数据切分到多个服务器上去，每个服务器具有相应的库与表，只是表中数据集合不同。水平分库分表能够有效的缓解单机和单库的性能瓶颈和压力，突破IO、连接数、硬件资源等的瓶颈。

水平分库分表切分规则

1、RANGE：从0到10000一个表，10001到20000一个表；
2、HASH取模：一个商场系统，一般都是将用户，订单作为主表，然后将和它们相关的作为附表，这样不会造成跨库事务之类的问题。 取用户id，然后hash取模，分配到不同的数据库上。
3、地理区域：比如按照华东，华南，华北这样来区分业务，七牛云应该就是如此。
4、时间：按照时间切分，就是将6个月前，甚至一年前的数据切出去放到另外的一张表，因为随着时间流逝，这些表的数据 被查询的概率变小，所以没必要和“热数据”放在一起，这个也是“冷热数据分离”。

分库分表后引入的问题:
1、分布式事务问题

如果我们做了垂直分库或者水平分库以后,就必然会涉及到跨库执行SQL的问题,这样就引发了互联网界的老大难问题-"分布式事务"。

2、跨库join的问题
分库分表后表之间的关联操作将受到限制，我们无法join位于不同分库的表，也无法join分表粒度不同的表， 结果原本一次查询能够完成的业务，可能需要多次查询才能完成。

3、横向扩容与数据迁移的问题
当我们使用HASH取模做分表的时候,针对数据量的递增,可能需要动态的增加表,此时就需要考虑因为reHash导致数据迁移的问题。

4、结果集合并、排序的问题因为我们是将数据分散存储到不同的库、表里的,当我们查询指定数据列表时,数据来源于不同的子库或者子表,就必然会引发结果集合并、排序的问题。

1.5 主从复制

什么是主从复制：是用来建立一个和主数据库完全一样的数据库环境，称为从数据库，主数据库一般是准实时的业务数据库。

主从复制的作用：1、做数据的热备:作为后备数据库，主数据库服务器故障后，可切换到从数据库继续工作，避免数据丢失。2、架构的扩展:业务量越来越大，I/O访问频率过高，单机无法满足，此时做多库的存储，降低磁盘I/O访问的频率，提高单个机器的I/O性能。3、读写分离:使数据库能支撑更大的并发。在报表中尤其重要。由于部分报表sql语句非常的慢，导致锁表，影响前台服务。如果前台使用master，报表使用slave，那么报表sql将不会造成前台锁，保证了前台速度。

主从复制的原理:分为四步走：1、主库对所有DDL和DML产生的日志写进binlog；2、主库生成一个 log dump 线程，用来给从库I/O线程读取binlog；3、从库的I/O Thread去请求主库的binlog，并将得到的binlog日志写到relay log文件中；4、从库的SQL Thread会读取relay log文件中的日志解析成具体操作，将主库的DDL和DML操作事件重放。
DML（Data ManipulationLanguage）语句：即数据操纵语句，用来查询、添加、更新、删除等
DDL（Data Definition Languages）语句：即数据库定义语句，用来创建数据库中的表、索引、视图、存储过程、触发器等

1.6 读写分离

    数据库写入效率要低于读取效率，一般系统中数据读取频率高于写入频率，单个数据库实例在写入的时候会影响读取性能，这是做读写分离的原因。实现方式主要基于mysql的主从复制，通过路由的方式使应用对数据库的写请求只在master上进行，读请求在slave上进行。
在应用和数据库之间增加代理层，代理层接收应用对数据库的请求，根据不同请求类型转发到不同的实例，在实现读写分离的同时可以实现负载均衡。

二、索引

2.1 什么是索引

索引是一种数据结构。数据库索引，是数据库管理系统中一个排序的数据结构，以协助快速查询、更新数据库表中数据，是要占据物理空间的。
索引的实现通常使用B树及其变种B+树。

2.2 索引的优缺点

索引的优点：可以大大加快数据的检索速度，这也是创建索引的最主要的原因。
索引的缺点时间方面：创建索引和维护索引要耗费时间。具体地，当对表中的数据进行增加、删除和修改的时候，索引也要动态的维护，会降低增/改/删的执行效率；空间方面：索引需要占物理空间。

2.3 索引的类型

唯一索引：唯一索引是不允许其中任何两行具有相同索引值的索引；一般要求列值唯一（可以有null）。
主键索引：在我们给一个字段设置主键的时候，它就会自动创建主键索引，用来确保每一个值都是唯一的，且不能为空。
组合索引：多列值组成一个索引，专门用于组合搜索
全文索引：有点像是一个搜索引擎提供模糊查询，通过对文章中关键字建立索引，不是直接与索引中的值相比较。（http://www.360doc.com/content/17/1211/13/33260087_712076317.shtml）
非聚集索引将数据存储于索引分开结构，索引结构的叶子节点指向了数据的对应行。当定位到索引之后还需要通过索引找到磁盘相应数据。
聚簇索引:将数据存储与索引放到了一块，找到索引也就找到了数据。

2.4 索引的创建原则

建立索引：
1、查询比较频繁：较频繁作为查询条件的字段才去创建索引
2、有外键的列：定义有外键的数据列一定要建立索引。不建立索引
1、频繁更改：更新频繁字段不适合创建索引
2、查询较少：对于那些查询中很少涉及的列，重复值比较多的列不要建立索引。
3、区分度比较低：若是不能有效区分数据的列不适合做索引列(如性别，男女未知，最多也就三种，区分度实在太低)
4、对于定义为text、image和bit的数据类型的列不要建立索引。扩展索引
尽量的扩展索引，不要新建索引。比如表中已经有a的索引，现在要加(a,b)的索引，那么只需要修改原来的索引即可。

2.5 索引失效条件

1、如果条件中有or，即使其中有部分条件带索引也不会使用
2、like以%开头
3、对于复合索引，如果不使用前列，后续列也将无法使用
4、存在索引列的数据类型隐形转换，则用不上索引，比如列类型是字符串，那一定要在条件中将数据使用引号引用起来,否则不使用索引
5、where 子句里对索引列上有数学运算，用不上索引
6、where 子句里对有索引列使用函数，用不上索引
7、"如果mysql估计使用全表扫描要比使用索引快,则不使用索引"
https://www.cnblogs.com/liehen2046/p/11052666.html

2.6 B树索引和Hash 索引的区别

B+树索引：是通过B+树实现的；B+树是一个多路平衡查找树，从根节点到每个叶子节点的高度差值不超过1，而且叶子的节点之按照大小顺序从左往右排序并通过指针相连。在B+树上的常规检索，"从根节点到叶子节点的搜索效率基本相当，不会出现大幅波动。而且基于索引的顺序扫描时，效率非常高"。因此，B+树索引被广泛应用于数据库、文件系统等场景。

Hash 索引：哈希索引就是采用一定的哈希算法，把键值换算成新的哈希值，检索时不需要类似B+树那样从根节点到叶子节点逐级查找，只需一次哈希算法即可立刻定位到相应的位置，速度非常快。

B+树索引和哈希索引的明显区别是:
(1) 如果是等值查询，那么哈希索引明显有绝对优势，因为只需要经过一次算法即可找到相应的键值；当然了，这个前提是，键值都是唯一的。如果键值不是唯一的，就需要先找到该键所在位置，然后再根据链表往后扫描，直到找到相应的数据；
(2)如果是范围查询检索，这时候哈希索引就毫无用武之地了，因为"原先是有序的键值，经过哈希算法后，有可能变成不连续的了"(3)同理，哈希索引也没办法利用索引完成排序,以及like `xxx%`这样的模糊查询（范围查询)(4)hash索引不⽀持多了联合索引的最左匹配规则,原理也是因为hash函数的不可预测。AAAA和AAAAB的索引没有相关性。(5)hash索引虽然在"等值查询上较快，但是不稳定。性能不可预测，当某个键值存在大量重复的时候，发生hash碰撞，此时效率可能极差”。而B+树的查询效率比较稳定，对于所有的查询都是从根节点到叶子节点，且树的高度较低。 因此，在大多数情况下，直接选择B+树索引可以获得稳定且较好的查询速度。而不需要使用hash索引。

2.7 介绍一下B 树、B + 树

B树是一种平衡的多叉查找树，通常我们说m阶的B树，它必须满足如下条件： 1、每个节点最多只有m个子节点。
2、若根节点不是非终端节点，至少有两个孩子3、除根结点和叶子结点外，其它每个结点至少有[ceil(m / 2)]个孩子（向上取整）
4、中间的节点有k-1个元素和k个孩子5、所有叶子结点都出现在同一层
6、每个节点中元素从小到大排列

B+树是应文件系统所需而产生的B树的变形树，其特征在于1、有m个子树的中间节点包含有m个元素（B树中是k-1个元素），每个元素不保存数据，只用来索引；2、叶子节点包含信息，非叶子节点仅起到索引作用。3、叶子节点包含全部的关键子信息，且叶子结点本身依关键字的大小自小而大的顺序链接。

2.8 为什么说B+树比B树更适合数据库索引？

1）B+树的磁盘读写代价更低B+树的内部结点并没有指向关键字具体信息的指针。因此其内部结点相对B 树更小。那么一个盘块所能容纳的关键字数量也越多。一次性读入内存中的需要查找的关键字也就越多。相对来说IO读写次数也就降低了；2）B+树查询效率更加稳定由于非终结点并不是最终指向文件内容的结点，而只是叶子结点中关键字的索引。所以任何关键字的查找必须走一条从根结点到叶子结点的路。所有关键字查询的路径长度相同，导致每一个数据的查询效率相当；   3）B+树便于范围查询（最重要的原因，范围查找是数据库的常态）B树在提高了IO性能的同时并没有解决元素遍历的效率低下的问题，正是为了解决这个问题，B+树应用而生。B+树只需要去遍历叶子节点就可以实现整棵树的遍历。而且在数据库中基于范围的查询是非常频繁的，而B树不支持这样的操作或者说效率太低

2.9 最左前缀原则是什么？

在进行组合搜索的时候，我们通常会将建立组合索引。
MySQL中的索引可以按照一定顺序引用多列，这种索引叫作联合索引。如User表的name和city加联合索引就是(name,city)
而最左前缀原则指的是，如果查询的时候查询条件精确匹配索引的左边连续一列或几列，则此索引列就可以被用到。如下：
select * from user where name=xx and city=xx ; ／／可以命中索引
select * from user where name=xx ; // 可以命中索引
select * from user where city=xx ; // 无法命中索引
这里需要注意的是，查询的时候如果两个条件都用上了，但是顺序不同，如 city= xx and name ＝xx，那么现在的查询引擎会自动优化为匹配联合索引的顺序，这样是能够命中索引的。

三、事务

3.1 简单介绍一下事务

事务是一个不可分割的数据库操作序列，也是数据库并发控制的基本单位。
事务执行的结果必须使数据库从一种一致性状态变到另一种一致性状态。
事务中包含的这组操作，要么都执行，要么都不执行。

3.2 事务的四大特性

原子性（Atomicity）:原子性是指事务包含的所有操作要么全部成功，要么全部失败回滚.
一致性（Consistency）:事务开始前和结束后，数据库的完整性约束没有被破坏。比如A向B转账，不可能A扣了钱，B却没收到。
隔离性（Isolation）: 多个事务并发访问时，事务之间是隔离的，一个事务不应该影响其它事务运行效果。
持久性（Durability）:持久性是指一个事务一旦被提交了，那么对数据库中的数据的改变就是永久性的

3.3 事务之间的相互影响（事务并发）

脏读：事务A读取了事务B更新的数据，然后B回滚操作，那么A读取到的数据是脏数据.不可重复读：事务A多次读取同一数据，事务B在事务A多次读取的过程中，对数据作了更新并提交，导致事务A多次读取同一数据时，结果事务先后两次读到的数据结果会不一致。幻读：幻读，是指当事务不是独立执行时发生的一种现象，例如第一个事务对一个表中的数据进行了修改，这种修改涉及到表中的全部数据行。同时，第二个事务也修改这个表中的数据，这种修改是向表中插入一行新数据。那么，以后就会发生操作第一个事务的用户发现表中还有没有修改的数据行，就好象发生了幻觉一样.

3.4 事务的隔离级别

隔离级别共4种
1、读未提交:即能够读取到没有被提交的数据，所以很明显这个级别的隔离机制无法解决脏读、不可重复读、幻读中的任何一种
2、读已提交:即能够读到那些已经提交的数据，自然能够防止脏读，但是无法限制不可重复读和幻读
3、重复读取:即在数据读出来之后加锁。这样就解决了脏读、不可重复读的问题，但是幻读的问题还是无法解决。
4、串行化:最高的事务隔离级别，不管多少事务，挨个运行完一个事务的所有子事务之后才可以执行另外一个事务里面的所有子事务，这样就解决了脏读、不可重复读和幻读的问题。MySQL 支持4种事务隔离级别;MySQL默认的事务隔离级别为可重复读。事务隔离机制的实现基于锁机制和并发调度。

3.5 事务的传播行为

事务传播行为:指的就是当一个事务方法被另一个事务方法调用时，这个事务方法应该如何运行。
事务的7种传播行为:
mandatory强制性，有事务则加入，没有异常；
supports支持，有则加入，没有就不管了，非事务运行；
required需要，没有新建，有加入
requires_new需要新的，不管有没有，直接创建新事务
not supported不支持事务，存在就挂起
never不支持事务，存在就异常
nested:存在就在嵌套的执行，没有就找是否存在外面的事务，有则加入，没有则新建
对事务的要求程度可以从大到小排序：mandatory / supports / required / requires_new / nested / not supported / never

3.6 事务的隔离级别和锁之间的关系

在Read Uncommitted级别下，读取数据不需要加共享锁，这样就不会跟被修改的数据上的排他锁冲突在Read Committed级别下，读操作需要加共享锁，但是在语句执行完以后释放共享锁；在Repeatable Read级别下，读操作需要加共享锁，必须等待事务执行完毕以后才释放共享锁。SERIALIZABLE 是限制性最强的隔离级别，因为该级别锁定整个范围的键，并一直持有锁，直到事务完成。

四、数据库存储引擎

4.1 Mysql 最常用的存储引擎

Innodb引擎：Innodb引擎提供了对数据库事务的支持。并且还提供了行级锁和外键的约束。它的设计的目标就是处理大数据容量的数据库系统。
MyIASM引擎(原本Mysql的默认引擎)：不提供事务的支持，也不支持行级锁和外键。
MEMORY引擎：所有的数据都在内存中，数据的处理速度快，但是安全性不高。

4.2 MyISAM与InnoDB区别

1.事务：InnoDB支持事务，MyISAM不支持， 这一点是非常之重要。事务是一种高级的处理方式，如在一些列增删改中只要哪个出错还可以回滚还原，而MyISAM就不可以了。
2.外键：InnoDB支持外键，MyISAM不支持。
3.锁：锁是避免资源争用的机制，MYIASM只支持表级锁，InnoDB支持行级锁，锁定力度小并发能力高 。4.增删改查：MyISAM适合查询以及插入为主的应用，InnoDB适合频繁修改以及涉及到安全性较高的应用。    5.存储结构：MYIASM每张表被存放在3个文件中（表格定义，数据文件，索引文件）；InnoDB所有的表都存放在同一个文件中6.存储空间：MYIASM可被压缩，存储空间小；InnoDB需要更多的内存和存储。 7.索引：两者都是使用B+树作为存储结构，但是在实现方式上面差别很大。
MyIASM:索引结构为非聚簇索引,索引和数据文件是分离的，索引保存的是数据文件的指针。
InnoDB:索引结构为聚簇索引,数据文件是和（主键）索引绑在一起的,必须要有主键，通过主键索引效率很高。Innodb不支持全文索引，而MyISAM支持全文索引。
Innodb支持HASh索引，而MyISAM不支持HASH索引。

4.3 InnoDB引擎的4大特性

插入缓冲（insert buffer)、二次写(double write)、自适应哈希索引(ahi)、预读(read ahead)
https://www.jianshu.com/p/dcc0dc450a2c

4.4 存储引擎选择

如果没有特别的需求，使用默认的Innodb即可。
MyISAM：以读写插入为主的应用程序，比如博客系统、新闻门户网站。
Innodb：更新操作频率也高，或者要保证数据的完整性；并发量高，支持事务和外键。比如OA自动化办公系统。

五、数据库的锁

5.1、谈一下对于MySQL锁的了解

当数据库有并发事务的时候，可能会产生数据的不一致，这时候需要一些机制来保证访问的次序，锁机制就是这样的一个机制。就像酒店的房间，如果大家随意进出，就会出现多人抢夺同一个房间的情况，而在房间上装上锁，申请到钥匙的人才可以入住并且将房间锁起来，其他人只有等他使用完毕才可以再次使用。

5.2、按照锁的粒度划分数据库锁有哪些？

在关系型数据库中，可以按照锁的粒度把数据库锁分为行级锁(INNODB引擎)、表级锁(MYISAM引擎)和页级锁(BDB引擎 )。

行级锁，表级锁和页级锁对比1、行级锁：行级锁是Mysql中锁定粒度最细的一种锁，表示只针对当前操作的行进行加锁。行级锁分为共享锁 和 排他锁。
特点：锁定粒度最小，加锁慢，开销大，会出现死锁；发生锁冲突的概率最低，并发度也最高。 2、表级锁：表级锁是MySQL中锁定粒度最大的一种锁，表示对当前操作的整张表加锁。它实现简单，资源消耗较少，被大部分MySQL引擎支持。最常使用的MYISAM与INNODB都支持表级锁定。表级锁定分为表共享读锁（共享锁）与表独占写锁（排他锁）。
特点：锁定粒度最大，加锁快，开销小，不会出现死锁；发出锁冲突的概率最高，并发度最低。3、页级锁：页级锁是MySQL中锁定粒度介于行级锁和表级锁中间的一种锁，一次锁定相邻的一组记录。特点：锁定粒度界于表锁和行锁之间，开销和加锁时间界于表锁和行锁之间，会出现死锁；并发度一般

MyISAM和InnoDB存储引擎使用的锁：MyISAM采用表级锁(table-level locking)。InnoDB支持行级锁(row-level locking)和表级锁，默认为行级锁

5.3、从锁的类别上分MySQL都有哪些锁呢？

在关系型数据库中，可以按照锁的的类别分为：有共享锁和排他锁。
共享锁: 又叫做读锁。当用户要进行数据的读取时，对数据加上共享锁。共享锁可以同时加上多个。
排他锁: 又叫做写锁。当用户要进行数据的写入时，对数据加上排他锁。排他锁只可以加一个，他和其他的排他锁，共享锁都相斥。

5.4 、InnoDB引擎的行锁是怎么实现的？

答：InnoDB是基于索引来完成行锁
例: select * from tab_with_index where id = 1 for update;
for update 可以根据条件来完成行锁锁定，并且 id 是有索引键的列，如果 id 不是索引键那么InnoDB将完成表锁，并发将无从谈起

5.5、 InnoDB存储引擎的锁的算法有三种

Record lock：单个行记录上的锁
Gap lock：间隙锁，锁定一个范围，不包括记录本身
Next-key lock：record+gap 锁定一个范围，包含记录本身

5.6 什么是死锁？怎样解决？

死锁是指两个或多个事务在同一资源上相互占用，并请求锁定对方的资源，从而导致恶性循环的现象。

常见的解决死锁的方法:
1、
2、如果不同程序会并发存取多个表，尽量约定以相同的顺序访问表，可以大大降低死锁机会。
3、对于非常容易产生死锁的业务部分，可以尝试使用升级锁定颗粒度，通过表级锁定来减少死锁产生的概率；

5.7、数据库的乐观锁和悲观锁是什么？怎么实现的？

数据库管理系统中的并发控制的任务:是确保在多个事务同时存取数据库中同一数据时不破坏事务的隔离性和一致性以及数据库的统一性。 乐观并发控制（乐观锁）和悲观并发控制（悲观锁）是并发控制主要采用的技术手段。

悲观锁：当我们要对一个数据库中的一条数据进行修改的时候，假设数据会造成冲突，最好的办法就是直接对该数据进行加锁以防止并发。这种借助数据库锁机制，在修改数据之前先锁定，再修改的方式被称之为悲观并发控制
悲观锁的实现方式：借助数据库锁机制    乐观锁：当我们要对一个数据库中的一条数据进行修改的时候，假设数据不会造成冲突，在对数据进行提交更新的时候，才会正式对数据的冲突与否进行检测，如果发现冲突了，则返回给用户错误的信息，让用户决定如何去做。
乐观锁的实现方式：一般会使用版本号机制或CAS算法实现。

两种锁的使用场景
我们知道两种锁各有优缺点，不可认为一种好于另一种。
乐观锁适用于写比较少的情况下（多读场景），即冲突真的很少发生的时候，这样可以省去了锁的开销，加大了系统的整个吞吐量。
悲观锁适用于写比较多的情况下（多写场景），即冲突经常发生的时候。这就会导致上层应用会不断的进行retry，这样反倒是降低了性能，

六、视图& 触发器

6.1 为什么要使用视图？什么是视图？

为了提高"复杂SQL语句的复用性"和"表操作的安全性"，MySQL数据库管理系统提供了视图特性。

1、视图是由基本表产生的虚表。
2、视图的列可以来自不同的表。
3、视图的建立和删除不影响基本表。
4、对视图内容的增删改直接影响基本表。

6.2 视图的使用场景有哪些？

1、重用SQL语句
2、简化复杂的SQL操作。在编写查询后，可以方便的重用它而不必知道它的基本查询细节；
3、使用表的组成部分而不是整个表；
4、保护数据。可以给用户授予表的特定部分的访问权限而不是整个表的访问权限；

6.3 触发器

触发器是定义在关系表上的"一类由事件驱动"的特殊的存储过程。

使用场景：1、实时监控某张表中的某个字段的更改而需要做出相应的处理。2、可以通过数据库中的相关表实现级联更改。

MSQL常见面试问题相关推荐

js 计算任意凸多边形内最大矩形_题库 | 计算机视觉常见面试题型介绍及解答第 7 期...
- 计算机视觉 -为什么说 Dropout 可以解决过拟合?(1)取平均的作用: 先回到标准的模型即没有 dropout,我们用相同的训练数据去训练 5 个不同的神经网络,一般会得到 5 个不同的结果 ...
Hive常见面试问题（持续更新）
Hive常见面试问题目录 Hive 内部表和外部表的区别,以及各自使用于哪种环境?Hive和传统数据库的区别? HiveRc 文件? Hive 分区? Hive 分区过多有何坏处以及分区时的注意事项 ...
面经——C/C++常见面试知识点总结附面试真题
参考:C/C++ 面试题作者:zhaouc 发布时间: 2015-02-15 15:51:00 网址:https://blog.csdn.net/zhaouc/article/details/438 ...
java面试常见面试问题_Java面试准备：15个Java面试问题
java面试常见面试问题并非所有的访谈都将重点放在算法和数据结构上-通常,访谈通常只侧重于您声称是专家的语言或技术.在此类访谈中,通常没有任何"陷阱"问题,而是它们要求您利用内存 ...
spring常见面试问题_Spring面试问题
spring常见面试问题另外,请查看我们最新的文章69Spring面试问题与解答–最终清单 . 1)什么是春天? 回答: Spring是控件和面向方面的容器框架的轻量级反转. 2)解释春天? 回答: ...
【C++基础】常见面试问题（二）
1. 指针和引用的区别指针保存的是所指对象的地址,引用是所指对象的别名,指针需要通过解引用间接访问,而引用是直接访问指针可以改变地址,从而改变所指的对象,而引用必须从一而终: 引用在定义的时候必须 ...
Java常见面试知识点：继承、接口、多态、代码块
问题:Java常见面试知识点:继承.接口.多态.代码块答案: 1.继承继承中构造方法的访问特点子类中所有的构造方法默认都会访问父类中无参的构造方法为什么? • 子类在初始化的时候,有可能会使用 ...
视频教程：Java常见面试题目深度解析！
视频教程:Java常见面试题目深度解析! Java作为目前比较火的计算机语言之一,连续几年蝉联最受程序员欢迎的计算机语言榜首,因此每年新入职Java程序员也数不胜数.很多java程序员在学成之后,会面 ...
Linux底层IIC 总线的理解、调用函数以及常见面试问题
对 IIC 总线的理解.调用函数以及常见面试问题一.IIC 总线概述: IIC 即Inter-Integrated Circuit(集成电路总线) I2C总线是PHLIPS公司推出的一种串行总线, ...

MSQL常见面试问题

Mysql

MSQL常见面试问题相关推荐

最新文章

热门文章