精华内容
下载资源
问答
  • 现在网投,公司动不动就是2年以上工作经验。 试问没有工作,哪里来的经验? 如果有了经验,对你公司没有感情,也不会长久。 10年考研失败,找工作太难了。
  • 软件测试面试题(面试前准备篇)

    万次阅读 多人点赞 2019-09-27 10:42:37
    了解过哪些技术博客/论坛(有问到) 是否了解软件测试需要掌握哪些知识(问到类似问题) 之前面试过,觉得自己需要补充哪些?做了哪些行动? 为什么做测试,觉得自己做测试有哪些优势?(有问到) 知道哪些...

    目录

    一、问题预测

    1. 让简单介绍下自己(每次面试开场)

    2. 让说下自己会的内容

    3. 看了哪些书籍(有问到)

    4. 了解过哪些技术博客/论坛(有问到)

    5. 是否了解软件测试需要掌握哪些知识(问到类似问题)

    6. 之前面试过,觉得自己需要补充哪些?做了哪些行动?

    7. 为什么做测试,觉得自己做测试有哪些优势?(有问到)

    8. 知道哪些Bug系统

    9.测试用例的基本要素是?

    二、介绍一下公司项目

    三、技能方面

    1、 数据库方面常识

    2、 linux操作

    3、缺陷方面(有问到)

    4、用例部分

    5、软件测试流程

    6、网络相关

    7、测试工具

    8、其他概念问题

    四、你还有什么想问的吗(必答)

    五、简历模板

    一、问题预测

    1. 让简单介绍下自己(这个不用说了每次面试开场)

    你好,我叫xx,来自xx,毕业于xx。目前有两年的功能测试经验。最近的一份工作是xx公司,主要参与app系统测试,负责xxapp,一款类似抖音的短视频app功能测试,负责过的功能模块有拍摄、上传、搜索、推荐引擎等。主要运用边界值,等价类,错误推测等常见黑盒测试方法。

    1. 让说下自己会的内容

    我熟悉软件测试基础理论和测试流程,测试方法等,有app测试、web测试、接口测试经验。熟悉数据库增删改查操作,熟悉使用测试管理工具。

    1. 看了哪些书籍(有问到)

    软件测试,软件测试的艺术、软件测试实用教程,在我负责短视频的推荐引擎测试期间看完了项亮的《推荐系统实战》主要是推荐系统的评测部分。

    1. 了解过哪些技术博客/论坛(有问到)

    51testing论坛,CSDN一些博客(面试经验:面试中会问具体哪些博客),和公众号(搜狗测试、软件测试资源分享)

    1. 是否了解软件测试需要掌握哪些知识(有问到类似问题)

    软件测试基础知识,流程,测试用例方法,数据库相关知识,抓包分析,接口测试、测试工具、性能测试等。

    1. 之前面试过,觉得自己需要补充哪些?做了哪些行动?

    很多公司对性能测试和自动化测试工具有要求,由于之前的工作主要涉及的是功能测试,所以这方面的知识储备不够。不过最近我在学习这方面的知识,希望以后在工作中能深入学习。

    1. 为什么做测试,觉得自己做测试有哪些优势?(有问到)

    我觉得我个人的性格比较适合做测试。我比较细心耐心,考虑事情比较全面,这样对于我在设计测试用例时很有帮助,而且我能够很好的与人协调沟通,当我们测试和开发发生沟通上的矛盾时我也能很好的解决,我平常喜欢刷微博、知乎看热门评论,喜欢考究大众心理,这有助于我站在用户角度设计测试点。

    1. 知道哪些Bug系统

    禅道/bugzila等

    9.测试用例的基本要素是?

    版本号,功能模块,优先级别,前置条件,步骤,预期结果,实际结果等。

    二、介绍一下公司项目

    xxapp,是一款集短视频、游戏、直播、社交互动于一体的内容娱乐APP。公司大约一个月发布一个较大的版本,需求数20几个-40几个不等(用例数xx+),每个版本包括的需求www\wap、后台以及客户端的需求。项目分客户端版本负责人、后台版本负责人、H5版本负责人等,负责人牵头及落实整个测试流程。我当过的角色有H5活动负责人、推荐引擎版本负责人、客户端和后台系统测试人员。负责过的模块用例数大概是500左右。

    三、技能方面

    1、数据库方面常识

    l关系型数据库:把复杂的数据结构归结为简单的二元关系(即二维表格形式),通过SQL结构化查询语句存储数据

    典型产品:

    Mysql:互联网领域、大中小型网站,游戏公司,电商平台等等。体积小、速度快、成本低、开放源代码

    Oracle:传统大企业、大公司、政府、金融、证券等。安全性、成本高、

    l非关系型数据库:非关系型数据库也被成为NoSQL数据库,NOSQL的本意是“Not Olnly SQL”。NOSQL为了高性能、高并发而生

    其他分类

    1)键值(Key-Value)存储数据库:主要是使用一个哈希表,这个表中有一个特定的键和一个指针指向特定的数据。简单、易部署、高并发

    典型:Redis、Memcached

    2)列存储(Column-oriented)数据库:应对分布式存储的海量数据。如果我们有一个Person类,我们通常会一起查询他们的姓名和年龄,而不是薪资。这种情况下,姓名和年龄就会被放入一个列族中,而薪资则在另外一个列族中。

    典型:Hbase

    3)面向文档数据库:数据存储的最小单位是文档

    典型:Mongodb、Hive

    Mongodb一个介于关系型数据库和非关系型数据库之间的产品。高性能、易部署、易使用,存储数据非常方便。

    Hive可以用来进行统计查询,HBase可以用来进行实时查询

    一些增删改查笔试题准备

    (另起一篇)

    2、linux操作

    linux搭建测试环境,比如web系统服务搭建。

    一些常见命令准备

    (另起一篇)

    3、缺陷方面(有问到)

    描述一个你印象最深刻的bug

    在做上传视频的测试时,发现华为荣耀V10上传手机自带相机专业模式录制的视频会闪退。而ios上传同个视频提示合成失败。

    我将手机自带相机录制的专业模式和普通模式录制的同样时长的视频发到电脑上,用格式工厂软件查看视频的不同之处,之后发现视频编码是不同的。

    我继续网上查阅了视频编码方面的知识,发现mp4视频有几种编码,而继续测试验证发现我们的app上传的视频只支持mp4视频中的H.264编码格式。于是提交了视频上传不支持非H.264格式的视频。并补充完善了相关用例。

    (因为在公司没有查日志权限,所以其实应该先查日志)

    4、用例部分

    现场让你设计个用例,比如水杯、凳子怎么测试?

    首先说明的是,遇到这样的测试题目,首先应该反问面试官,需求是什么样的,比如是测什么样的杯子。

    因为设计测试用例的规则应该是根据需求分析文档设计用例,客户需求什么,就测试什么。

    但是在没有需求分析文档的前提下,来设计测试用例,可以考查一个测试人员的基本功,比如考虑问题是否全面,设计测试用例的方法是否合理等。

    一般是根据自己的日常经验和测试的思维来设计测试用例。在设计测试用例时一般从以下几个方面进行分析:功能测试,性能测试,界面测试,安全性测试,兼容性测试,可用性测试,可靠性测试,本地化/国际化测试。

    例子(另起一篇)

    5、软件测试流程

    公司严格规范测试流程和测试文档,首先是参与需求评审,编写测试计划、测试方案、测试用例,进行测试方案及用例的测试组内部评审,外部评审。

    提取部分一级用例提交研发自测,研发自测通过后开开始执行一轮系统测试。

    测试过程中发现并提交、跟踪问题。

    问题修复后进行回归测试。

    一轮测试完成后对修复包进行冒烟测试,测试通过则进行二轮测试。

    二轮测试完成后会进行需求交叉测试。

    完成测试编写系统测试报告提交验收测试。验收测试通过输出验收测试报告。

    6、网络相关

    网络协议,如TCP/UDP的区别?(https://www.cnblogs.com/steven520213/p/8005258.html)

    1、TCP面向连接(如打电话要先拨号建立连接);UDP是无连接的,即发送数据之前不需要建立连接

    2、TCP提供可靠的服务。也就是说,通过TCP连接传送的数据,无差错,不丢失,不重复,且按序到达;UDP尽最大努力交付,即不保证可靠交付

    3、TCP面向字节流,实际上是TCP把数据看成一连串无结构的字节流;UDP是面向报文的

    UDP没有拥塞控制,因此网络出现拥塞不会使源主机的发送速率降低(对实时应用很有用,如IP电话,实时视频会议等)

    4、每一条TCP连接只能是点到点的;UDP支持一对一,一对多,多对一和多对多的交互通信

    5、TCP首部开销20字节;UDP的首部开销小,只有8个字节

    6、TCP的逻辑通信信道是全双工的可靠信道,UDP则是不可靠信道

    三次握手与四次挥手

    三次握手通俗版:

    第一次握手:客户端要和服务端进行通信,首先要告知服务端一声,遂发出一个SYN=1的连接请求信号,”服务端哥哥,我想给你说说话”。

    第二次握手:当服务端接收到客户端的连接请求,此时要给客户端一个确认信息,”我知道了(ACK),我这边已经准备好了,你现在能连吗(SYN)”。

    第三次握手:当客户端收到了服务端的确认连接信息后,要礼貌的告知一下服务端,“好的,咱们开始联通吧(ACK)”。

    到此整个建立连接的过程已经结束,接下来就是双方你一句我一句甚至同时交流传递信息的过程了。

    四次挥手断开连接通俗版:

    第一次挥手:双方交流的差不多了,此时客户端也已经结尾了,接下来要断开通信连接,所以告诉服务端“我说完了(FIN)”,此时自身形成等待结束连接的状态。

    第二次挥手:服务端知道客户端已经没话说了,服务端此时还有两句话要给客户端说“我知道你说完了(ACK),我再说两句&*…%¥”…

    第三次挥手:此时客户端洗耳恭听继续处于等待结束的状态,服务器端也说完了,自身此时处于等待关闭连接的状态,并对告诉客户端,“我说完了,咱们断了吧(FIN)”。

    第四次挥手:客户端收知道服务端也说完了,也要告诉服务端一声(ACK),因为连接和断开要双方都按下关闭操作才能断开,客户端同时又为自己定义一个定时器,因为不知道刚才说的这句话能不能准确到达服务端(网络不稳定或者其他因素引起的网络原因)。

    所以默认时间定为两个通信的最大时间之和,超出这个时间就默认服务器端已经接收到了自己的确认信息,此时客户端就关闭自身连接,服务器端一旦接收到客户端发来的确定通知就立刻关闭服务器端的连接。

    到此为止双方整个通信过程就此终结。

    这里要声明一下:断开链接不一定就是客户端,谁都可以先发起断开指令,另外客户端和服务端是没有固定标准的,谁先发起请求谁就是客户端。

    三次握手阐述:

    在第一次消息发送中,A随机选取一个序列号作为自己的初始序号发送给B;

    第二次消息B使用ack对A的数据包进行确认,因为已经收到了序列号为x的数据包,准备接收序列号为x+1的包,所以ack=x+1,同时B告诉A自己的初始序列号,就是seq=y;

    第三条消息A告诉B收到了B的确认消息并准备建立连接,A自己此条消息的序列号是x+1,所以seq=x+1,而ack=y+1是表示A正准备接收B序列号为y+1的数据包。

    四次挥手阐述:

    由于TCP连接时全双工的,因此,每个方向都必须要单独进行关闭,这一原则是当一方完成数据发送任务后,发送一个FIN来终止这一方向的连接,

    收到一个FIN只是意味着这一方向上没有数据流动了,即不会再收到数据了,但是在这个TCP连接上仍然能够发送数据,直到这一方向也发送了FIN。

    首先进行关闭的一方将执行主动关闭,而另一方则执行被动关闭,上图描述的即是如此。
    (1)第一次挥手:Client发送一个FIN,用来关闭Client到Server的数据传送,Client进入FIN_WAIT_1状态。
    (2)第二次挥手:Server收到FIN后,发送一个ACK给Client,确认序号为收到序号+1(与SYN相同,一个FIN占用一个序号),Server进入CLOSE_WAIT状态。
    (3)第三次挥手:Server发送一个FIN,用来关闭Server到Client的数据传送,Server进入LAST_ACK状态。
    (4)第四次挥手:Client收到FIN后,Client进入TIME_WAIT状态,接着发送一个ACK给Server,确认序号为收到序号+1,Server进入CLOSED状态,完成四次挥手。

    7、测试工具

    测试工具,无非这几类:

    自动化测试工具 (如QTP)

    性能测试工具 (如loadrunner)

    测试管理类 (如jira)

    安全测试工具

    渗透测试工具

    8、其他概念问题

    Beta测试与Alpha测试有什么区别

    1、Alpha测试

    Alpha测试是由用户在开发环境下进行的测试,也可以是开发机构内部的用户在模拟实际操作环境下进行的测试。开发者坐在用户旁边,这是在开发者受控的环境下进行的测试。由开发者随时记录下错误情况和使用中的问题。

    2、Beta测试

    Beta测试是由软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场,这是在开发者无法控制的环境下进行的测试。由用户记录下遇到的所有问题,定期向开发者报告。beta测试是一模拟真实的使用环境从而发现缺陷的一种测试

    3、验收测试

    验收测试是以用户为主的测试,软件开发和QA人员也应该参加,测试一般在用户所在地进行,由用户验证软件产品是否满足了所有的需求的一系列的验收测试工作。

    仅限于做项目的公司,部门内部测试稳定后,根据合同中需求由发包商进行验收测试。验收测试的目的是为了以发现”未实现的需求”为目的,以评估”适合使用”为目标,该类测试的不是以发现缺陷为主要目的。

    区别:两者的主要区别是测试的场所不同。

    Alpha测试是指把用户请到开发方的场所来测试,beta测试是指在一个或多个用户的场所进行的测试。Alpha测试的环境是受开发方控制的,用户的数量相对比较少,时间比较集中。

    而beta测试的环境是不受开发方控制的,谁也不知道用户如何折磨软件,用户数量相对比较多,时间不集中。

    一般地,alpha测试先于beta测试执行。通用的软件产品需要较大规模的beta测试,测试周期比较长。如果产品通过了beta测试,那么就可以正式发行了。

    Alpha测试在系统开发接近完成时对应用系统的测试;测试后仍然会有少量的设计变更。这种测试一般由最终用户或其它人员完成,不能由程序或测试员完成。

    Beta测试 当开发和测试根本完成时所做的测试,最终的错误和问题需要在最终发行前找到。这种测试一般由最终用户或其它人员完成,不能由程序员或测试员完成。

    四、你还有什么想问的吗(必答)

    我非常希望能够加入公司,所以想请问您觉得我还有哪些地方比较不足,能否给一些建议?以及是否有复试时间呢?

    五、简历模板

    可在公众号《软件测试er》回复‘简历模板’获取
    文章首发于公众号

    关于我准备后的面试经历、面试题汇总、面试结果

    有兴趣请继续关注~

    展开全文
  • MySQL 面试题

    万次阅读 多人点赞 2019-09-02 16:03:33
    MySQL 面试题 MySQL 涉及的内容非常非常非常多,所以面试题也容易写的杂乱。当年,我们记着几个一定要掌握的重心: ...对于【运维】部分,更多考验开发的知识储备情况,当然能回答出来是比较好的...

    MySQL 面试题

    MySQL 涉及的内容非常非常非常多,所以面试题也容易写的杂乱。当年,我们记着几个一定要掌握的重心:

    重点的题目添加了【重点】前缀。

    1. 索引。
    2. 锁。
    3. 事务和隔离级别。

    因为 MySQL 还会有部分内容和运维相关度比较高,所以本文我们分成两部分【开发】【运维】两部分。

    • 对于【开发】部分,我们需要掌握。
    • 对于【运维】部分,更多考验开发的知识储备情况,当然能回答出来是比较好的,特别是对于高级开发工程师、架构师等。

    开发

    为什么互联网公司一般选择 MySQL 而不是 Oracle?

    免费、流行、够用。

    ? 当然,这个回答要稍微润色下。不过一般,很少问这个问题了。

    数据库的三范式是什么?什么是反模式?

    艿艿:重点在于反模式的回答。实际开发中,不会严格遵守三范式。

    胖友直接看 《服务端指南 数据存储篇 | MySQL(07) 范式与反模式》

    MySQL 有哪些数据类型?

    MySQL 支持多种类型,大致可以分为三类:数值、日期/时间和字符串(字符)类型。具体可以看看 《MySQL 数据类型》 文档。

    • 正确的使用数据类型,对数据库的优化是非常重要的。

    ? MySQL 中 varchar 与 char 的区别?varchar(50) 中的 50 代表的涵义?

    • 1、varchar 与 char 的区别,char 是一种固定长度的类型,varchar 则是一种可变长度的类型。
    • 2、varchar(50) 中 50 的涵义最多存放 50 个字符。varchar(50) 和 (200) 存储 hello 所占空间一样,但后者在排序时会消耗更多内存,因为 ORDER BY col 采用 fixed_length 计算 col 长度(memory引擎也一样)。所以,实际场景下,选择合适的 varchar 长度还是有必要的。

    ? int(11) 中的 11 代表什么涵义?

    int(11) 中的 11 ,不影响字段存储的范围,只影响展示效果。具体可以看看 《MySQL 中 int 长度的意义》 文章。

    ? 金额(金钱)相关的数据,选择什么数据类型?

    • 方式一,使用 int 或者 bigint 类型。如果需要存储到分的维度,需要 *100 进行放大。
    • 方式二,使用 decimal 类型,避免精度丢失。如果使用 Java 语言时,需要使用 BigDecimal 进行对应。

    ? 一张表,里面有 ID 自增主键,当 insert 了 17 条记录之后,删除了第 15,16,17 条记录,再把 MySQL 重启,再 insert 一条记录,这条记录的 ID 是 18 还是 15?

    • 一般情况下,我们创建的表的类型是 InnoDB ,如果新增一条记录(不重启 MySQL 的情况下),这条记录的 ID 是18 ;但是如果重启 MySQL 的话,这条记录的 ID 是 15 。因为 InnoDB 表只把自增主键的最大 ID 记录到内存中,所以重启数据库或者对表 OPTIMIZE 操作,都会使最大 ID 丢失。
    • 但是,如果我们使用表的类型是 MyISAM ,那么这条记录的 ID 就是 18 。因为 MyISAM 表会把自增主键的最大 ID 记录到数据文件里面,重启 MYSQL 后,自增主键的最大 ID 也不会丢失。

    最后,还可以跟面试官装个 x ,生产数据,不建议进行物理删除记录。

    ? 表中有大字段 X(例如:text 类型),且字段 X 不会经常更新,以读为为主,请问您是选择拆成子表,还是继续放一起?写出您这样选择的理由

    • 拆带来的问题:连接消耗 + 存储拆分空间。

      如果能容忍拆分带来的空间问题,拆的话最好和经常要查询的表的主键在物理结构上放置在一起(分区) 顺序 IO ,减少连接消耗,最后这是一个文本列再加上一个全文索引来尽量抵消连接消耗。

    • 不拆可能带来的问题:查询性能。

      如果能容忍不拆分带来的查询性能损失的话,上面的方案在某个极致条件下肯定会出现问题,那么不拆就是最好的选择。

    实际场景下,例如说商品表数据量比较大的情况下,会将商品描述单独存储到一个表中。即,使用拆的方案。

    MySQL 有哪些存储引擎?

    MySQL 提供了多种的存储引擎:

    • InnoDB
    • MyISAM
    • MRG_MYISAM
    • MEMORY
    • CSV
    • ARCHIVE
    • BLACKHOLE
    • PERFORMANCE_SCHEMA
    • FEDERATED

    具体每种存储引擎的介绍,可以看看 《数据库存储引擎》

    ? 如何选择合适的存储引擎?

    提供几个选择标准,然后按照标准,选择对应的存储引擎即可,也可以根据 常用引擎对比 来选择你使用的存储引擎。使用哪种引擎需要根据需求灵活选择,一个数据库中多个表可以使用不同的引擎以满足各种性能和实际需求。使用合适的存储引擎,将会提高整个数据库的性能。

    1. 是否需要支持事务。

    2. 对索引和缓存的支持。

    3. 是否需要使用热备。

    4. 崩溃恢复,能否接受崩溃。

    5. 存储的限制。

    6. 是否需要外键支持。

      艿艿:目前开发已经不考虑外键,主要原因是性能。具体可以看看 《从 MySQL 物理外键开始的思考》 文章。

    目前,MySQL 默认的存储引擎是 InnoDB ,并且也是最主流的选择。主要原因如下:

    • 【最重要】支持事务。
    • 支持行级锁和表级锁,能支持更多的并发量。
    • 查询不加锁,完全不影响查询。
    • 支持崩溃后恢复。

    在 MySQL5.1 以及之前的版本,默认的存储引擎是 MyISAM ,但是目前已经不再更新,且它有几个比较关键的缺点:

    • 不支持事务。
    • 使用表级锁,如果数据量大,一个插入操作锁定表后,其他请求都将阻塞。

    艿艿:也就是说,我们不需要花太多力气在 MyISAM 的学习上。

    ? 请说明 InnoDB 和 MyISAM 的区别

    InnoDBMyISAM
    事务支持不支持
    存储限制64TB
    锁粒度行锁表锁
    崩溃后的恢复支持不支持
    外键支持不支持
    全文检索5.7 版本后支持支持

    更完整的对比,可以看看 《数据库存储引擎》「常用引擎对比」 小节。

    ? 请说说 InnoDB 的 4 大特性?

    艿艿:貌似我面试没被问过…反正,我是没弄懂过~~

    • 插入缓冲(insert buffer)
    • 二次写(double write)
    • 自适应哈希索引(ahi)
    • 预读(read ahead)

    ? 为什么 SELECT COUNT(*) FROM table 在 InnoDB 比 MyISAM 慢?

    对于 SELECT COUNT(*) FROM table 语句,在没有 WHERE 条件的情况下,InnoDB 比 MyISAM 可能会慢很多,尤其在大表的情况下。因为,InnoDB 是去实时统计结果,会全表扫描;而 MyISAM 内部维持了一个计数器,预存了结果,所以直接返回即可。

    详细的原因,胖友可以看看 《高性能 MySQL 之 Count 统计查询》 博客。

    ? 各种不同 MySQL 版本的 Innodb 的改进?

    艿艿:这是一个选择了解的问题。

    MySQL5.6 下 Innodb 引擎的主要改进:

    1. online DDL
    2. memcached NoSQL 接口
    3. transportable tablespace( alter table discard/import tablespace)
    4. MySQL 正常关闭时,可以 dump 出 buffer pool 的( space, page_no),重启时 reload,加快预热速度
    5. 索引和表的统计信息持久化到 mysql.innodb_table_stats 和 mysql.innodb_index_stats,可提供稳定的执行计划
    6. Compressed row format 支持压缩表

    MySQL5.7 下 Innodb 引擎的主要改进:

    • 1、修改 varchar 字段长度有时可以使用

      这里的“有时”,指的是也有些限制。可见 《MySQL 5.7 online ddl 的一些改进》

    • 2、Buffer pool 支持在线改变大小

    • 3、Buffer pool 支持导出部分比例

    • 4、支持新建 innodb tablespace,并可以在其中创建多张表

    • 5、磁盘临时表采用 innodb 存储,并且存储在 innodb temp tablespace 里面,以前是 MyISAM 存储

    • 6、透明表空间压缩功能

    重点】什么是索引?

    索引,类似于书籍的目录,想找到一本书的某个特定的主题,需要先找到书的目录,定位对应的页码。

    MySQL 中存储引擎使用类似的方式进行查询,先去索引中查找对应的值,然后根据匹配的索引找到对应的数据行。

    ? 索引有什么好处?

    1. 提高数据的检索速度,降低数据库IO成本:使用索引的意义就是通过缩小表中需要查询的记录的数目从而加快搜索的速度。
    2. 降低数据排序的成本,降低CPU消耗:索引之所以查的快,是因为先将数据排好序,若该字段正好需要排序,则正好降低了排序的成本。

    ? 索引有什么坏处?

    1. 占用存储空间:索引实际上也是一张表,记录了主键与索引字段,一般以索引文件的形式存储在磁盘上。
    2. 降低更新表的速度:表的数据发生了变化,对应的索引也需要一起变更,从而减低的更新速度。否则索引指向的物理数据可能不对,这也是索引失效的原因之一。

    ? 索引的使用场景?

    • 1、对非常小的表,大部分情况下全表扫描效率更高。

    • 2、对中大型表,索引非常有效。

    • 3、特大型的表,建立和使用索引的代价随着增长,可以使用分区技术来解决。

      实际场景下,MySQL 分区表很少使用,原因可以看看 《互联网公司为啥不使用 MySQL 分区表?》 文章。

      对于特大型的表,更常用的是“分库分表”,目前解决方案有 Sharding Sphere、MyCAT 等等。

    ? 索引的类型?

    索引,都是实现在存储引擎层的。主要有六种类型:

    • 1、普通索引:最基本的索引,没有任何约束。

    • 2、唯一索引:与普通索引类似,但具有唯一性约束。

    • 3、主键索引:特殊的唯一索引,不允许有空值。

    • 4、复合索引:将多个列组合在一起创建索引,可以覆盖多个列。

    • 5、外键索引:只有InnoDB类型的表才可以使用外键索引,保证数据的一致性、完整性和实现级联操作。

    • 6、全文索引:MySQL 自带的全文索引只能用于 InnoDB、MyISAM ,并且只能对英文进行全文检索,一般使用全文索引引擎。

      常用的全文索引引擎的解决方案有 Elasticsearch、Solr 等等。最为常用的是 Elasticsearch 。

    具体的使用,可以看看 《服务端指南 数据存储篇 | MySQL(03) 如何设计索引》

    ? MySQL 索引的“创建”原则?

    注意,是“创建”噢。

    • 1、最适合索引的列是出现在 WHERE 子句中的列,或连接子句中的列,而不是出现在 SELECT 关键字后的列。

    • 2、索引列的基数越大,索引效果越好。

      具体为什么,可以看看如下两篇文章:

    • 3、根据情况创建复合索引,复合索引可以提高查询效率。

      因为复合索引的基数会更大。

    • 4、避免创建过多的索引,索引会额外占用磁盘空间,降低写操作效率。

    • 5、主键尽可能选择较短的数据类型,可以有效减少索引的磁盘占用提高查询效率。

    • 6、对字符串进行索引,应该定制一个前缀长度,可以节省大量的索引空间。

    ? MySQL 索引的“使用”注意事项?

    注意,是“使用”噢。

    • 1、应尽量避免在 WHERE 子句中使用 !=<> 操作符,否则将引擎放弃使用索引而进行全表扫描。优化器将无法通过索引来确定将要命中的行数,因此需要搜索该表的所有行。

      注意,column IS NULL 也是不可以使用索引的。

    • 2、应尽量避免在 WHERE 子句中使用 OR 来连接条件,否则将导致引擎放弃使用索引而进行全表扫描,如:SELECT id FROM t WHERE num = 10 OR num = 20

    • 3、应尽量避免在 WHERE 子句中对字段进行表达式操作,这将导致引擎放弃使用索引而进行全表扫描。

    • 4、应尽量避免在 WHERE 子句中对字段进行函数操作,这将导致引擎放弃使用索引而进行全表扫描。

    • 5、不要在 WHERE 子句中的 = 左边进行函数、算术运算或其他表达式运算,否则系统将可能无法正确使用索引。

    • 6、复合索引遵循前缀原则。

    • 7、如果 MySQL 评估使用索引比全表扫描更慢,会放弃使用索引。如果此时想要索引,可以在语句中添加强制索引。

    • 8、列类型是字符串类型,查询时一定要给值加引号,否则索引失效。

    • 9、LIKE 查询,% 不能在前,因为无法使用索引。如果需要模糊匹配,可以使用全文索引。

    关于这块,可以看看 《服务端指南 数据存储篇 | MySQL(04) 索引使用的注意事项》 文章,写的更加细致。

    ? 以下三条 SQL 如何建索引,只建一条怎么建?

    WHERE a = 1 AND b = 1
    WHERE b = 1
    WHERE b = 1 ORDER BY time DESC
    
    
    • 以顺序 b , a, time 建立复合索引,CREATE INDEX table1_b_a_time ON index_test01(b, a, time)
    • 对于第一条 SQL ,因为最新 MySQL 版本会优化 WHERE 子句后面的列顺序,以匹配复合索引顺序。

    ? 想知道一个查询用到了哪个索引,如何查看?

    EXPLAIN 显示了 MYSQL 如何使用索引来处理 SELECT 语句以及连接表,可以帮助选择更好的索引和写出更优化的查询语句。

    使用方法,在 SELECT 语句前加上 EXPLAIN 就可以了。 《MySQL explain 执行计划详细解释》

    【重点】MySQL 索引的原理?

    解释 MySQL 索引的原理,篇幅会比较长,并且网络上已经有靠谱的资料可以看,所以艿艿这里整理了几篇,胖友可以对照着看。

    下面,艿艿对关键知识做下整理,方便胖友回顾。

    几篇好一点的文章:

    《MySQL索引背后的数据结构及算法原理》

    《MySQL 索引原理》

    《深入理解 MySQL 索引原理和实现 —— 为什么索引可以加速查询?》

    MySQL 有哪些索引方法?

    在 MySQL 中,我们可以看到两种索引方式:

    什么是 B-Tree 索引?

    B-Tree 是为磁盘等外存储设备设计的一种平衡查找树。因此在讲 B-Tree 之前先了解下磁盘的相关知识。

    • 系统从磁盘读取数据到内存时是以磁盘块(block)为基本单位的,位于同一个磁盘块中的数据会被一次性读取出来,而不是需要什么取什么。
    • InnoDB存储引擎中有页(Page)的概念,页是其磁盘管理的最小单位。InnoDB 存储引擎中默认每个页的大小为 16 KB,可通过参数 innodb_page_size 将页的大小设置为 4K、8K、16K ,在 MySQL 中可通过如下命令查看页的大小:
    mysql> show variables like 'innodb_page_size';
    
    • 而系统一个磁盘块的存储空间往往没有这么大,因此 InnoDB 每次申请磁盘空间时都会是若干地址连续磁盘块来达到页的大小 16KB 。InnoDB 在把磁盘数据读入到磁盘时会以页为基本单位,在查询数据时如果一个页中的每条数据都能有助于定位数据记录的位置,这将会减少磁盘 I/O 次数,提高查询效率。

    B-Tree 结构的数据可以让系统高效的找到数据所在的磁盘块。为了描述B-Tree,首先定义一条记录为一个二元组 [key, data] ,key 为记录的键值,对应表中的主键值,data 为一行记录中除主键外的数据。对于不同的记录,key值互不相同。

    一棵 m 阶的 B-Tree 有如下特性:

    1. 每个节点最多有 m 个孩子。
      • 除了根节点和叶子节点外,其它每个节点至少有 Ceil(m/2) 个孩子。
      • 若根节点不是叶子节点,则至少有 2 个孩子。
    2. 所有叶子节点都在同一层,且不包含其它关键字信息。
    3. 每个非叶子节点包含 n 个关键字信息(P0,P1,…Pn, k1,…kn)
      • 关键字的个数 n 满足:ceil(m/2)-1 <= n <= m-1
      • ki(i=1,…n) 为关键字,且关键字升序排序。
      • Pi(i=0,…n) 为指向子树根节点的指针。P(i-1) 指向的子树的所有节点关键字均小于 ki ,但都大于 k(i-1) 。

    B-Tree 中的每个节点根据实际情况可以包含大量的关键字信息和分支,如下图所示为一个 3 阶的 B-Tree:

    B-Tree 的结构

    • 每个节点占用一个盘块的磁盘空间,一个节点上有两个升序排序的 key 和三个指向子树根节点的 point ,point 存储的是子节点所在磁盘块的地址。两个 key 划分成的三个范围域,对应三个 point 指向的子树的数据的范围域。
    • 以根节点为例,key 为 17 和 35 ,P1 指针指向的子树的数据范围为小于 17 ,P2 指针指向的子树的数据范围为 [17~35] ,P3 指针指向的子树的数据范围为大于 35 。

    模拟查找 key 为 29 的过程:

    • 1、根据根节点找到磁盘块 1 ,读入内存。【磁盘I/O操作第1次】
    • 2、比较 key 29 在区间(17,35),找到磁盘块 1 的指针 P2 。
    • 3、根据 P2 指针找到磁盘块 3 ,读入内存。【磁盘I/O操作第2次】
    • 4、比较 key 29 在区间(26,30),找到磁盘块3的指针P2。
    • 5、根据 P2 指针找到磁盘块 8 ,读入内存。【磁盘I/O操作第3次】
    • 6、在磁盘块 8 中的 key 列表中找到 eky 29 。

    分析上面过程,发现需要 3 次磁盘 I/O 操作,和 3 次内存查找操作。由于内存中的 key 是一个有序表结构,可以利用二分法查找提高效率。而 3 次磁盘 I/O 操作是影响整个 B-Tree 查找效率的决定因素。B-Tree 相对于 AVLTree 缩减了节点个数,使每次磁盘 I/O 取到内存的数据都发挥了作用,从而提高了查询效率。

    什么是 B+Tree 索引?

    B+Tree 是在 B-Tree 基础上的一种优化,使其更适合实现外存储索引结构,InnoDB存储引擎就是用 B+Tree 实现其索引结构。

    从上一节中的 B-Tree 结构图中可以看到,每个节点中不仅包含数据的 key 值,还有 data 值。而每一个页的存储空间是有限的,如果 data 数据较大时将会导致每个节点(即一个页)能存储的 key 的数量很小,当存储的数据量很大时同样会导致 B-Tree 的深度较大,增大查询时的磁盘 I/O 次数,进而影响查询效率。在 B+Tree 中,所有数据记录节点都是按照键值大小顺序存放在同一层的叶子节点上,而非叶子节点上只存储 key 值信息,这样可以大大加大每个节点存储的 key 值数量,降低 B+Tree 的高度。

    B+Tree 相对于 B-Tree 有几点不同:

    • 非叶子节点只存储键值信息。
    • 所有叶子节点之间都有一个链指针。
    • 数据记录都存放在叶子节点中。

    将上一节中的 B-Tree 优化,由于 B+Tree 的非叶子节点只存储键值信息,假设每个磁盘块能存储 4 个键值及指针信息,则变成 B+Tree 后其结构如下图所示:

    B+Tree 的结构

    • 通常在 B+Tree 上有两个头指针,一个指向根节点,另一个指向关键字最小的叶子节点,而且所有叶子节点(即数据节点)之间是一种链式环结构。因此可以对 B+Tree 进行两种查找运算:一种是对于主键的范围查找和分页查找,另一种是从根节点开始,进行随机查找。

    可能上面例子中只有 22 条数据记录,看不出 B+Tree 的优点,下面做一个推算:

    • InnoDB 存储引擎中页的大小为 16KB,一般表的主键类型为 INT(占用4个字节) 或 BIGINT(占用8个字节),指针类型也一般为 4 或 8 个字节,也就是说一个页(B+Tree 中的一个节点)中大概存储 16KB/(8B+8B)=1K 个键值(因为是估值,为方便计算,这里的 K 取值为〖10〗^3)。也就是说一个深度为 3 的 B+Tree 索引可以维护10^3 *10^3 *10^3 = 10亿 条记录。
    • 实际情况中每个节点可能不能填充满,因此在数据库中,B+Tree 的高度一般都在 2~4 层。MySQL 的 InnoDB 存储引擎在设计时是将根节点常驻内存的,也就是说查找某一键值的行记录时最多只需要 1~3 次磁盘 I/O 操作。

    B+Tree 有哪些索引类型?

    在 B+Tree 中,根据叶子节点的内容,索引类型分为主键索引非主键索引

    • 主键索引的叶子节点存的数据是整行数据( 即具体数据 )。在 InnoDB 里,主键索引也被称为聚集索引(clustered index)。
    • 非主键索引的叶子节点存的数据是整行数据的主键,键值是索引。在 InnoDB 里,非主键索引也被称为辅助索引(secondary index)。

    辅助索引与聚集索引的区别在于辅助索引的叶子节点并不包含行记录的全部数据,而是存储相应行数据的聚集索引键,即主键。当通过辅助索引来查询数据时,需要进过两步:

    • 首先,InnoDB 存储引擎会遍历辅助索引找到主键。
    • 然后,再通过主键在聚集索引中找到完整的行记录数据。

    另外,InnoDB 通过主键聚簇数据,如果没有定义主键,会选择一个唯一的非空索引代替,如果没有这样的索引,会隐式定义个主键作为聚簇索引。

    再另外,可能有胖友有和艿艿的一样疑惑,在辅助索引如果相同的索引怎么存储?最终存储到 B+Tree 非子节点中时,它们对应的主键 ID 是不同的,所以妥妥的。如下图所示:

    相同的索引怎么存储

    聚簇索引的注意点有哪些?

    聚簇索引表最大限度地提高了 I/O 密集型应用的性能,但它也有以下几个限制:

    • 1、插入速度严重依赖于插入顺序,按照主键的顺序插入是最快的方式,否则将会出现页分裂,严重影响性能。因此,对于 InnoDB 表,我们一般都会定义一个自增的 ID 列为主键。

      关于这一点,可能面试官会换一个问法。例如,为什么主键需要是自增 ID ,又或者为什么主键需要带有时间性关联。

    • 2、更新主键的代价很高,因为将会导致被更新的行移动。因此,对于InnoDB 表,我们一般定义主键为不可更新。

      MySQL 默认情况下,主键是允许更新的。对于 MongoDB ,其 主键是不允许更新的。

    • 3、二级索引访问需要两次索引查找,第一次找到主键值,第二次根据主键值找到行数据。

      当然,有一种情况可以无需二次查找,基于非主键索引查询,但是查询字段只有主键 ID ,那么在二级索引中就可以查找到。

    • 4、主键 ID 建议使用整型。因为,每个主键索引的 B+Tree 节点的键值可以存储更多主键 ID ,每个非主键索引的 B+Tree 节点的数据可以存储更多主键 ID 。

    什么是索引的最左匹配特性?

    当 B+Tree 的数据项是复合的数据结构,比如索引 (name, age, sex) 的时候,B+Tree 是按照从左到右的顺序来建立搜索树的。

    • 比如当 (张三, 20, F) 这样的数据来检索的时候,B+Tree 会优先比较 name 来确定下一步的所搜方向,如果 name 相同再依次比较 age 和 sex ,最后得到检索的数据。
    • 但当 (20, F) 这样的没有 name 的数据来的时候,B+Tree 就不知道下一步该查哪个节点,因为建立搜索树的时候 name 就是第一个比较因子,必须要先根据 name 来搜索才能知道下一步去哪里查询。
    • 比如当 (张三, F) 这样的数据来检索时,B+Tree 可以用 name 来指定搜索方向,但下一个字段 age 的缺失,所以只能把名字等于张三的数据都找到,然后再匹配性别是 F 的数据了。

    这个是非常重要的性质,即索引的最左匹配特性。

    MyISAM 索引实现?

    MyISAM 索引的实现,和 InnoDB 索引的实现是一样使用 B+Tree ,差别在于 MyISAM 索引文件和数据文件是分离的,索引文件仅保存数据记录的地址

    MyISAM 索引与 InnoDB 索引的区别?

    • InnoDB 索引是聚簇索引,MyISAM 索引是非聚簇索引。
    • InnoDB 的主键索引的叶子节点存储着行数据,因此主键索引非常高效。
    • MyISAM 索引的叶子节点存储的是行数据地址,需要再寻址一次才能得到数据。
    • InnoDB 非主键索引的叶子节点存储的是主键和其他带索引的列数据,因此查询时做到覆盖索引会非常高效。

    【重点】请说说 MySQL 的四种事务隔离级别?

    • 1、插入速度严重依赖于插入顺序,按照主键的顺序插入是最快的方式,否则将会出现页分裂,严重影响性能。因此,对于 InnoDB 表,我们一般都会定义一个自增的 ID 列为主键。

      关于这一点,可能面试官会换一个问法。例如,为什么主键需要是自增 ID ,又或者为什么主键需要带有时间性关联。

    • 2、更新主键的代价很高,因为将会导致被更新的行移动。因此,对于InnoDB 表,我们一般定义主键为不可更新。

      MySQL 默认情况下,主键是允许更新的。对于 MongoDB ,其 主键是不允许更新的。

    • 3、二级索引访问需要两次索引查找,第一次找到主键值,第二次根据主键值找到行数据。

      当然,有一种情况可以无需二次查找,基于非主键索引查询,但是查询字段只有主键 ID ,那么在二级索引中就可以查找到。

    • 4、主键 ID 建议使用整型。因为,每个主键索引的 B+Tree 节点的键值可以存储更多主键 ID ,每个非主键索引的 B+Tree 节点的数据可以存储更多主键 ID 。

    • 1、插入速度严重依赖于插入顺序,按照主键的顺序插入是最快的方式,否则将会出现页分裂,严重影响性能。因此,对于 InnoDB 表,我们一般都会定义一个自增的 ID 列为主键。

      关于这一点,可能面试官会换一个问法。例如,为什么主键需要是自增 ID ,又或者为什么主键需要带有时间性关联。

    • 2、更新主键的代价很高,因为将会导致被更新的行移动。因此,对于InnoDB 表,我们一般定义主键为不可更新。

      MySQL 默认情况下,主键是允许更新的。对于 MongoDB ,其 主键是不允许更新的。

    • 3、二级索引访问需要两次索引查找,第一次找到主键值,第二次根据主键值找到行数据。

      当然,有一种情况可以无需二次查找,基于非主键索引查询,但是查询字段只有主键 ID ,那么在二级索引中就可以查找到。

    • 4、主键 ID 建议使用整型。因为,每个主键索引的 B+Tree 节点的键值可以存储更多主键 ID ,每个非主键索引的 B+Tree 节点的数据可以存储更多主键 ID 。

    • 1、插入速度严重依赖于插入顺序,按照主键的顺序插入是最快的方式,否则将会出现页分裂,严重影响性能。因此,对于 InnoDB 表,我们一般都会定义一个自增的 ID 列为主键。

      关于这一点,可能面试官会换一个问法。例如,为什么主键需要是自增 ID ,又或者为什么主键需要带有时间性关联。

    • 2、更新主键的代价很高,因为将会导致被更新的行移动。因此,对于InnoDB 表,我们一般定义主键为不可更新。

      MySQL 默认情况下,主键是允许更新的。对于 MongoDB ,其 主键是不允许更新的。

    • 3、二级索引访问需要两次索引查找,第一次找到主键值,第二次根据主键值找到行数据。

      当然,有一种情况可以无需二次查找,基于非主键索引查询,但是查询字段只有主键 ID ,那么在二级索引中就可以查找到。

    • 4、主键 ID 建议使用整型。因为,每个主键索引的 B+Tree 节点的键值可以存储更多主键 ID ,每个非主键索引的 B+Tree 节点的数据可以存储更多主键 ID 。

    事务就是对一系列的数据库操作(比如插入多条数据)进行统一的提交或回滚操作,如果插入成功,那么一起成功,如果中间有一条出现异常,那么回滚之前的所有操作。

    这样可以防止出现脏数据,防止数据库数据出现问题。

    事务的特性指的是?

    指的是 ACID ,如下图所示:

    事务的特性

    1. 原子性 Atomicity :一个事务(transaction)中的所有操作,或者全部完成,或者全部不完成,不会结束在中间某个环节。事务在执行过程中发生错误,会被恢复(Rollback)到事务开始前的状态,就像这个事务从来没有执行过一样。即,事务不可分割、不可约简。
    2. 一致性 Consistency :在事务开始之前和事务结束以后,数据库的完整性没有被破坏。这表示写入的资料必须完全符合所有的预设约束触发器级联回滚等。
    3. 隔离性 Isolation :数据库允许多个并发事务同时对其数据进行读写和修改的能力,隔离性可以防止多个事务并发执行时由于交叉执行而导致数据的不一致。事务隔离分为不同级别,包括读未提交(Read uncommitted)、读提交(read committed)、可重复读(repeatable read)和串行化(Serializable)。
    4. 持久性 Durability :事务处理结束后,对数据的修改就是永久的,即便系统故障也不会丢失。

    事务的并发问题?

    实际场景下,事务并不是串行的,所以会带来如下三个问题:

    • 1、脏读:事务 A 读取了事务 B 更新的数据,然后 B 回滚操作,那么 A 读取到的数据是脏数据。
    • 2、不可重复读:事务 A 多次读取同一数据,事务 B 在事务 A 多次读取的过程中,对数据作了更新并提交,导致事务 A 多次读取同一数据时,结果不一致。
    • 3、幻读:系统管理员 A 将数据库中所有学生的成绩从具体分数改为 ABCDE 等级,但是系统管理员 B 就在这个时候插入了一条具体分数的记录,当系统管理员 A 改结束后发现还有一条记录没有改过来,就好像发生了幻觉一样,这就叫幻读。

    小结:不可重复读的和幻读很容易混淆,不可重复读侧重于修改,幻读侧重于新增或删除。解决不可重复读的问题只需锁住满足条件的行,解决幻读需要锁表。

    MySQL 事务隔离级别会产生的并发问题?

    • READ UNCOMMITTED(未提交读):事务中的修改,即使没有提交,对其他事务也都是可见的。

      会导致脏读。

    • READ COMMITTED(提交读):事务从开始直到提交之前,所做的任何修改对其他事务都是不可见的。

      会导致不可重复读。

      这个隔离级别,也可以叫做“不可重复读”。

    • REPEATABLE READ(可重复读):一个事务按相同的查询条件读取以前检索过的数据,其他事务插入了满足其查询条件的新数据。产生幻行。

      会导致幻读。

    • SERIALIZABLE(可串行化):强制事务串行执行。

    事务隔离级别脏读不可重复读幻读
    读未提交(read-uncommitted)
    读已提交(read-committed)
    可重复读(repeatable-read)是(x)
    串行化(serializable)
    • MySQL 默认的事务隔离级别为可重复读(repeatable-read) 。
    • 上图的 <X> 处,MySQL 因为其间隙锁的特性,导致其在可重复读(repeatable-read)的隔离级别下,不存在幻读问题。也就是说,上图 <X> 处,需要改成“否”!!!!
    • ? 记住这个表的方式,我们会发现它是自左上向右下是一个对角线。当然,最好是去理解。
    • 具体的实验,胖友可以看看 《MySQL 的四种事务隔离级别》

    【重点】请说说 MySQL 的锁机制?

    表锁是日常开发中的常见问题,因此也是面试当中最常见的考察点,当多个查询同一时刻进行数据修改时,就会产生并发控制的问题。MySQL 的共享锁和排他锁,就是读锁和写锁。

    • 共享锁:不堵塞,多个用户可以同时读一个资源,互不干扰。
    • 排他锁:一个写锁会阻塞其他的读锁和写锁,这样可以只允许一个用户进行写入,防止其他用户读取正在写入的资源。

    ? 锁的粒度?

    • 表锁:系统开销最小,会锁定整张表,MyIsam 使用表锁。
    • 行锁:最大程度的支持并发处理,但是也带来了最大的锁开销,InnoDB 使用行锁。

    ? 什么是悲观锁?什么是乐观锁?

    1)悲观锁

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

    在悲观锁的情况下,为了保证事务的隔离性,就需要一致性锁定读。读取数据时给加锁,其它事务无法修改这些数据。修改删除数据时也要加锁,其它事务无法读取这些数据。

    2)乐观锁

    相对悲观锁而言,乐观锁机制采取了更加宽松的加锁机制。悲观锁大多数情况下依靠数据库的锁机制实现,以保证操作最大程度的独占性。但随之而来的就是数据库性能的大量开销,特别是对长事务而言,这样的开销往往无法承受。

    而乐观锁机制在一定程度上解决了这个问题。乐观锁,大多是基于数据版本( Version )记录机制实现。何谓数据版本?即为数据增加一个版本标识,在基于数据库表的版本解决方案中,一般是通过为数据库表增加一个 “version” 字段来实现。读取出数据时,将此版本号一同读出,之后更新时,对此版本号加一。此时,将提交数据的版本数据与数据库表对应记录的当前版本信息进行比对,如果提交的数据版本号大于数据库表当前版本号,则予以更新,否则认为是过期数据。

    什么是死锁?

    多数情况下,可以认为如果一个资源被锁定,它总会在以后某个时间被释放。而死锁发生在当多个进程访问同一数据库时,其中每个进程拥有的锁都是其他进程所需的,由此造成每个进程都无法继续下去。简单的说,进程 A 等待进程 B 释放他的资源,B 又等待 A 释放他的资源,这样就互相等待就形成死锁。

    虽然进程在运行过程中,可能发生死锁,但死锁的发生也必须具备一定的条件,死锁的发生必须具备以下四个必要条件:

    • 互斥条件:指进程对所分配到的资源进行排它性使用,即在一段时间内某资源只由一个进程占用。如果此时还有其它进程请求资源,则请求者只能等待,直至占有资源的进程用毕释放。
    • 请求和保持条件:指进程已经保持至少一个资源,但又提出了新的资源请求,而该资源已被其它进程占有,此时请求进程阻塞,但又对自己已获得的其它资源保持不放。
    • 不剥夺条件:指进程已获得的资源,在未使用完之前,不能被剥夺,只能在使用完时由自己释放。
    • 环路等待条件:指在发生死锁时,必然存在一个进程——资源的环形链,即进程集合 {P0,P1,P2,•••,Pn} 中的 P0 正在等待一个 P1 占用的资源;P1 正在等待 P2 占用的资源,……,Pn 正在等待已被 P0 占用的资源。

    下列方法有助于最大限度地降低死锁:

    • 设置获得锁的超时时间。

      通过超时,至少保证最差最差最差情况下,可以有退出的口子。

    • 按同一顺序访问对象。

      这个是最重要的方式。

    • 避免事务中的用户交互。

    • 保持事务简短并在一个批处理中。

    • 使用低隔离级别。

    • 使用绑定连接。

    ? MySQL 中 InnoDB 引擎的行锁是通过加在什么上完成(或称实现)的?为什么是这样子的??

    InnoDB 是基于索引来完成行锁。例如:SELECT * FROM tab_with_index WHERE id = 1 FOR UPDATE

    • FOR UPDATE 可以根据条件来完成行锁锁定,并且 id 是有索引键的列,如果 id 不是索引键那么 InnoDB 将完成表锁,并发将无从谈起。

    【重要】MySQL 查询执行顺序?

    MySQL 查询执行的顺序是:

    (1)     SELECT
    (2)     DISTINCT <select_list>
    (3)     FROM <left_table>
    (4)     <join_type> JOIN <right_table>
    (5)     ON <join_condition>
    (6)     WHERE <where_condition>
    (7)     GROUP BY <group_by_list>
    (8)     HAVING <having_condition>
    (9)     ORDER BY <order_by_condition>
    (10)    LIMIT <limit_number>
    

    具体的,可以看看 《SQL 查询之执行顺序解析》 文章。

    【重要】聊聊 MySQL SQL 优化?

    可以看看如下几篇文章:

    另外,除了从 SQL 层面进行优化,也可以从服务器硬件层面,进一步优化 MySQL 。具体可以看看 《MySQL 数据库性能优化之硬件优化》

    编写 SQL 查询语句的考题合集

    MySQL 数据库 CPU 飙升到 500% 的话,怎么处理?

    当 CPU 飙升到 500% 时,先用操作系统命令 top 命令观察是不是 mysqld 占用导致的,如果不是,找出占用高的进程,并进行相关处理。

    如果此时是 IO 压力比较大,可以使用 iostat 命令,定位是哪个进程占用了磁盘 IO 。

    如果是 mysqld 造成的,使用 show processlist 命令,看看里面跑的 Session 情况,是不是有消耗资源的 SQL 在运行。找出消耗高的 SQL ,看看执行计划是否准确, index 是否缺失,或者实在是数据量太大造成。一般来说,肯定要 kill 掉这些线程(同时观察 CPU 使用率是否下降),等进行相应的调整(比如说加索引、改 SQL 、改内存参数)之后,再重新跑这些 SQL。

    也可以查看 MySQL 慢查询日志,看是否有慢 SQL 。

    也有可能是每个 SQL 消耗资源并不多,但是突然之间,有大量的 Session 连进来导致 CPU 飙升,这种情况就需要跟应用一起来分析为何连接数会激增,再做出相应的调整,比如说限制连接数等。

    ? 在 MySQL 服务器运行缓慢的情况下输入什么命令能缓解服务器压力?

    1)检查系统的状态

    通过操作系统的一些工具检查系统的状态,比如 CPU、内存、交换、磁盘的利用率,根据经验或与系统正常时的状态相比对,有时系统表面上看起来看空闲,这也可能不是一个正常的状态,因为 CPU 可能正等待IO的完成。除此之外,还应观注那些占用系统资源(CPU、内存)的进程。

    • 使用 sar 来检查操作系统是否存在 IO 问题。
    • 使用 vmstat 监控内存 CPU 资源。
    • 磁盘 IO 问题,处理方式:做 raid10 提高性能 。
    • 网络问题,telnet 一下 MySQL 对外开放的端口。如果不通的话,看看防火墙是否正确设置了。另外,看看 MySQ L是不是开启了 skip-networking 的选项,如果开启请关闭。

    2)检查 MySQL 参数

    • max_connect_errors
    • connect_timeout
    • skip-name-resolve
    • slave-net-timeout=seconds
    • master-connect-retry

    3)检查 MySQL 相关状态值

    • 关注连接数
    • 关注下系统锁情况
    • 关注慢查询(slow query)日志

    Innodb 的事务与日志的实现方式

    ? 有多少种日志?

    • redo 日志
    • undo 日志

    ? 日志的存放形式?

    • redo:在页修改的时候,先写到 redo log buffer 里面, 然后写到 redo log 的文件系统缓存里面(fwrite),然后再同步到磁盘文件(fsync)。
    • undo:在 MySQL5.5 之前,undo 只能存放在 ibdata* 文件里面, 5.6 之后,可以通过设置 innodb_undo_tablespaces 参数把 undo log 存放在 ibdata* 之外。

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

    艿艿:这个流程的理解还是比较简单的,实际思考实现感觉还是蛮复杂的。

    基本流程如下:

    • 因为事务在修改页时,要先记 undo ,在记 undo 之前要记 undo 的 redo, 然后修改数据页,再记数据页修改的 redo。 redo(里面包括 undo 的修改)一定要比数据页先持久化到磁盘。
    • 当事务需要回滚时,因为有 undo,可以把数据页回滚到前镜像的状态。
    • 崩溃恢复时,如果 redo log 中事务没有对应的 commit 记录,那么需要用 undo 把该事务的修改回滚到事务开始之前。如果有 commit 记录,就用 redo 前滚到该事务完成时并提交掉。

    MySQL binlog 的几种日志录入格式以及区别

    ? 各种日志格式的涵义

    binlog 有三种格式类型,分别如下:

    1)Statement

    每一条会修改数据的 SQL 都会记录在 binlog 中。

    • 优点:不需要记录每一行的变化,减少了 binlog 日志量,节约了 IO,提高性能。(相比 row 能节约多少性能与日志量,这个取决于应用的 SQL 情况,正常同一条记录修改或者插入 row 格式所产生的日志量还小于 Statement 产生的日志量,但是考虑到如果带条件的 update 操作,以及整表删除,alter 表等操作,ROW 格式会产生大量日志,因此在考虑是否使用 ROW 格式日志时应该跟据应用的实际情况,其所产生的日志量会增加多少,以及带来的 IO 性能问题。)

    • 缺点:由于记录的只是执行语句,为了这些语句能在 slave 上正确运行,因此还必须记录每条语句在执行的时候的一些相关信息,以保证所有语句能在 slave 得到和在 master 端执行时候相同 的结果。另外 MySQL 的复制,像一些特定函数功能,slave 可与 master 上要保持一致会有很多相关问题(如 sleep() 函数,last_insert_id(),以及 user-defined functions(udf) 会出现问题)。

    • 使用以下函数的语句也无法被复制:

      • LOAD_FILE()

      • UUID()

      • USER()

      • FOUND_ROWS()

      • SYSDATE() (除非启动时启用了 --sysdate-is-now 选项)

        同时在 INSERT …SELECT 会产生比 RBR 更多的行级锁 。

    2)Row

    不记录 SQL 语句上下文相关信息,仅保存哪条记录被修改。

    • 优点:binlog 中可以不记录执行的 SQL 语句的上下文相关的信息,仅需要记录那一条记录被修改成什么了。所以 rowlevel 的日志内容会非常清楚的记录下每一行数据修改的细节。而且不会出现某些特定情况下的存储过程,或 function ,以及 trigger 的调用和触发无法被正确复制的问题。
    • 缺点:所有的执行的语句当记录到日志中的时候,都将以每行记录的修改来记录,这样可能会产生大量的日志内容,比如一条 Update 语句,修改多条记录,则 binlog 中每一条修改都会有记录,这样造成 binlog 日志量会很大,特别是当执行 alter table 之类的语句的时候,由于表结构修改,每条记录都发生改变,那么该表每一条记录都会记录到日志中。

    3)Mixedlevel

    是以上两种 level 的混合使用。

    • 一般的语句修改使用 Statement 格式保存 binlog 。
    • 如一些函数,statement 无法完成主从复制的操作,则采用 Row 格式保存 binlog 。

    MySQL 会根据执行的每一条具体的 SQL 语句来区分对待记录的日志形式,也就是在 Statement 和 Row 之间选择 一种。

    新版本的 MySQL 中对 row level 模式也被做了优化,并不是所有的修改都会以 row level 来记录。

    • 像遇到表结构变更的时候就会以 Statement 模式来记录。
    • 至于 Update 或者 Delete 等修改数据的语句,还是会记录所有行的变更,即使用 Row 模式。

    ? 适用场景?

    在一条 SQL 操作了多行数据时, Statement 更节省空间,Row 更占用空间。但是, Row 模式更可靠。

    因为,互联网公司,使用 MySQL 的功能相对少,基本不使用存储过程、触发器、函数的功能,选择默认的语句模式,Statement Level(默认)即可。

    ? 结合第一个问题,每一种日志格式在复制中的优劣?

    • Statement 可能占用空间会相对小一些,传送到 slave 的时间可能也短,但是没有 Row 模式的可靠。
    • Row 模式在操作多行数据时更占用空间,但是可靠。

    所以,这是在占用空间和可靠之间的选择。

    如何在线正确清理 MySQL binlog?

    MySQL 中的 binlog 日志记录了数据中的数据变动,便于对数据的基于时间点和基于位置的恢复。但日志文件的大小会越来越大,占用大量的磁盘空间,因此需要定时清理一部分日志信息。

    # 首先查看主从库正在使用的binlog文件名称
    show master(slave) status
    
    # 删除之前一定要备份
    purge master logs before'2017-09-01 00:00:00'; # 删除指定时间前的日志
    purge master logs to'mysql-bin.000001'; # 删除指定的日志文件
    
    # 自动删除:通过设置binlog的过期时间让系统自动删除日志
    show variables like 'expire_logs_days'; # 查看过期时间
    set global expire_logs_days = 30; # 设置过期时间
    

    MySQL 主从复制的流程是怎么样的?

    MySQL 的主从复制是基于如下 3 个线程的交互(多线程复制里面应该是 4 类线程):

    • 1、Master 上面的 binlog dump 线程,该线程负责将 master 的 binlog event 传到 slave 。
    • 2、Slave 上面的 IO 线程,该线程负责接收 Master 传过来的 binlog,并写入 relay log 。
    • 3、Slave 上面的 SQL 线程,该线程负责读取 relay log 并执行。
    • 4、如果是多线程复制,无论是 5.6 库级别的假多线程还是 MariaDB 或者 5.7 的真正的多线程复制, SQL 线程只做 coordinator ,只负责把 relay log 中的 binlog 读出来然后交给 worker 线程, woker 线程负责具体 binlog event 的执行。

    ? MySQL 如何保证复制过程中数据一致性?

    • 1、在 MySQL5.5 以及之前, slave 的 SQL 线程执行的 relay log 的位置只能保存在文件( relay-log.info)里面,并且该文件默认每执行 10000 次事务做一次同步到磁盘, 这意味着 slave 意外 crash 重启时, SQL 线程执行到的位置和数据库的数据是不一致的,将导致复制报错,如果不重搭复制,则有可能会导致数据不一致。
      • MySQL 5.6 引入参数 relay_log_info_repository,将该参数设置为 TABLE 时, MySQL 将 SQL 线程执行到的位置存到 mysql.slave_relay_log_info 表,这样更新该表的位置和 SQL 线程执行的用户事务绑定成一个事务,这样 slave 意外宕机后,slave 通过 innodb 的崩溃恢复可以把 SQL 线程执行到的位置和用户事务恢复到一致性的状态。
    • 2、MySQL 5.6 引入 GTID 复制,每个 GTID 对应的事务在每个实例上面最多执行一次, 这极大地提高了复制的数据一致性。
    • 3、MySQL 5.5 引入半同步复制, 用户安装半同步复制插件并且开启参数后,设置超时时间,可保证在超时时间内如果 binlog 不传到 slave 上面,那么用户提交事务时不会返回,直到超时后切成异步复制,但是如果切成异步之前用户线程提交时在 master 上面等待的时候,事务已经提交,该事务对 master 上面的其他 session 是可见的,如果这时 master 宕机,那么到 slave 上面该事务又不可见了,该问题直到 5.7 才解决。
    • 4、MySQL 5.7 引入无损半同步复制,引入参 rpl_semi_sync_master_wait_point,该参数默认为 after_sync,指的是在切成半同步之前,事务不提交,而是接收到 slave 的 ACK 确认之后才提交该事务,从此,复制真正可以做到无损的了。
    • 5、可以再说一下 5.7 的无损复制情况下, master 意外宕机,重启后发现有 binlog 没传到 slave 上面,这部分 binlog 怎么办???分 2 种情况讨论, 1 宕机时已经切成异步了, 2 是宕机时还没切成异步??? 这个怎么判断宕机时有没有切成异步呢??? 分别怎么处理???

    ? MySQL 如何解决主从复制的延时性?

    5.5 是单线程复制,5.6 是多库复制(对于单库或者单表的并发操作是没用的),5.7 是真正意义的多线程复制,它的原理是基于 group commit, 只要 master 上面的事务是 group commit 的,那 slave 上面也可以通过多个 worker线程去并发执行。 和 MairaDB10.0.0.5 引入多线程复制的原理基本一样。

    ? 工作遇到的复制 bug 的解决方法?

    5.6 的多库复制有时候自己会停止,我们写了一个脚本重新 start slave 。

    ? 你是否做过主从一致性校验,如果有,怎么做的,如果没有,你打算怎么做?

    主从一致性校验有多种工具 例如 checksum、mysqldiff、pt-table-checksum 等。

    聊聊 MySQL 备份方式?备份策略是怎么样的?

    具体的,胖友可以看看 《MySQL 高级备份策略》 。主要有几个知识点:

    • 数据的备份类型

      • 【常用】完全备份

        这是大多数人常用的方式,它可以备份整个数据库,包含用户表、系统表、索引、视图和存储过程等所有数据库对象。但它需要花费更多的时间和空间,所以,一般推荐一周做一次完全备份。

      • 增量备份

        它是只备份数据库一部分的另一种方法,它不使用事务日志,相反,它使用整个数据库的一种新映象。它比最初的完全备份小,因为它只包含自上次完全备份以来所改变的数据库。它的优点是存储和恢复速度快。推荐每天做一次差异备份。

      • 【常用】事务日志备份

        事务日志是一个单独的文件,它记录数据库的改变,备份的时候只需要复制自上次备份以来对数据库所做的改变,所以只需要很少的时间。为了使数据库具有鲁棒性,推荐每小时甚至更频繁的备份事务日志。

      • 文件备份

        数据库可以由硬盘上的许多文件构成。如果这个数据库非常大,并且一个晚上也不能将它备份完,那么可以使用文件备份每晚备份数据库的一部分。由于一般情况下数据库不会大到必须使用多个文件存储,所以这种备份不是很常用。

    • 备份数据的类型

      • 热备份
      • 温备份
      • 冷备份
    • 备份工具

      • cp
      • mysqldump
      • xtrabackup
      • lvm2 快照

    MySQL 几种备份方式?

    MySQL 一般有 3 种备份方式。

    1)逻辑备份

    使用 MySQL 自带的 mysqldump 工具进行备份。备份成sql文件形式。

    • 优点:最大好处是能够与正在运行的 MySQL 自动协同工作,在运行期间可以确保备份是当时的点,它会自动将对应操作的表锁定,不允许其他用户修改(只能访问)。可能会阻止修改操作。SQL 文件通用方便移植。
    • 缺点:备份的速度比较慢。如果是数据量很多的时候,就很耗时间。如果数据库服务器处在提供给用户服务状态,在这段长时间操作过程中,意味着要锁定表(一般是读锁定,只能读不能写入数据),那么服务就会影响的。

    2)物理备份

    艿艿:因为现在主流是 InnoDB ,所以基本不再考虑这种方式。

    直接拷贝只适用于 MyISAM 类型的表。这种类型的表是与机器独立的。但实际情况是,你设计数据库的时候不可能全部使用 MyISAM 类型表。你也不可能因为 MyISAM 类型表与机器独立,方便移植,于是就选择这种表,这并不是选择它的理由。

    • 缺点:你不能去操作正在运行的 MySQL 服务器(在拷贝的过程中有用户通过应用程序访问更新数据,这样就无法备份当时的数据),可能无法移植到其他机器上去。

    3)双机热备份。

    当数据量太大的时候备份是一个很大的问题,MySQL 数据库提供了一种主从备份的机制,也就是双机热备。

    • 优点:适合数据量大的时候。现在明白了,大的互联网公司对于 MySQL 数据备份,都是采用热机备份。搭建多台数据库服务器,进行主从复制。

    数据库不能停机,请问如何备份? 如何进行全备份和增量备份?

    可以使用逻辑备份和双机热备份。

    • 完全备份:完整备份一般一段时间进行一次,且在网站访问量最小的时候,这样常借助批处理文件定时备份。主要是写一个批处理文件在里面写上处理程序的绝对路径然后把要处理的东西写在后面,即完全备份数据库。
    • 增量备份:对 ddl 和 dml 语句进行二进制备份。且 5.0 无法增量备份,5.1 后可以。如果要实现增量备份需要在 my.ini 文件中配置备份路径即可,重启 MySQL 服务器,增量备份就启动了。

    ? 你的备份工具的选择?备份计划是怎么样的?

    视库的大小来定,一般来说 100G 内的库,可以考虑使用 mysqldump 来做,因为 mysqldump 更加轻巧灵活,备份时间选在业务低峰期,可以每天进行都进行全量备份(mysqldump 备份出来的文件比较小,压缩之后更小)。

    100G 以上的库,可以考虑用 xtrabackup 来做,备份速度明显要比 mysqldump 要快。一般是选择一周一个全备,其余每天进行增量备份,备份时间为业务低峰期。

    备份恢复时间是多长?

    物理备份恢复快,逻辑备份恢复慢。

    这里跟机器,尤其是硬盘的速率有关系,以下列举几个仅供参考:

    • 20G 的 2 分钟(mysqldump)
    • 80G 的 30分钟(mysqldump)
    • 111G 的 30分钟(mysqldump)
    • 288G 的 3 小时(xtrabackup)
    • 3T 的 4 小时(xtrabackup)

    逻辑导入时间一般是备份时间的 5 倍以上。

    备份恢复失败如何处理?

    首先在恢复之前就应该做足准备工作,避免恢复的时候出错。比如说备份之后的有效性检查、权限检查、空间检查等。如果万一报错,再根据报错的提示来进行相应的调整。

    ? mysqldump 和 xtrabackup 实现原理?

    1)mysqldump

    mysqldump 是最简单的逻辑备份方式。

    • 在备份 MyISAM 表的时候,如果要得到一致的数据,就需要锁表,简单而粗暴。
    • 在备份 InnoDB 表的时候,加上 –master-data=1 –single-transaction 选项,在事务开始时刻,记录下 binlog pos 点,然后利用 MVCC 来获取一致的数据,由于是一个长事务,在写入和更新量很大的数据库上,将产生非常多的 undo ,显著影响性能,所以要慎用。
    • 优点:简单,可针对单表备份,在全量导出表结构的时候尤其有用。
    • 缺点:简单粗暴,单线程,备份慢而且恢复慢,跨 IDC 有可能遇到时区问题

    2)xtrabackup

    xtrabackup 实际上是物理备份+逻辑备份的组合。

    • 在备份 InnoDB 表的时候,它拷贝 ibd 文件,并一刻不停的监视 redo log 的变化,append 到自己的事务日志文件。在拷贝 ibd 文件过程中,ibd文件本身可能被写”花”,这都不是问题,因为在拷贝完成后的第一个 prepare 阶段,xtrabackup 采用类似于 Innodb 崩溃恢复的方法,把数据文件恢复到与日志文件一致的状态,并把未提交的事务回滚。
    • 如果同时需要备份 MyISAM 表以及 InnoDB 表结构等文件,那么就需要用 flush tables with lock 来获得全局锁,开始拷贝这些不再变化的文件,同时获得 binlog 位置,拷贝结束后释放锁,也停止对 redo log 的监视。

    如何从 mysqldump 产生的全库备份中只恢复某一个库、某一张表?

    具体可见 《MySQL 全库备份中恢复某个库和某张表以及 mysqldump 参数 –ignore-table 介绍》 文章。

    聊聊 MySQL 集群?

    艿艿:这块艿艿懂的少,主要找了一些网络上的资料。

    ? 对于简历中写有熟悉 MySQL 高可用方案?

    我一般先问他现在管理的数据库架构是什么,如果他只说出了主从,而没有说任何 HA 的方案,那么我就可以判断出他没有实际的 HA 经验。

    不过这时候也不能就是断定他不懂 MySQL 高可用,也许是没有实际机会去使用,那么我就要问 MMM 以及 MHA 以及 MM + keepalived 等的原理、实现方式以及它们之间的优势和不足了,一般这种情况下,能说出这个的基本没有。

    • MMM 那东西好像不靠谱,据说不稳定,但是有人在用的,和 mysql-router 比较像,都是指定可写的机器和只读机器。
    • MHA 的话一句话说不完,可以搜索下相关博客。

    聊聊 MySQL 安全?

    感兴趣的胖友,可以看看:

    MySQL 有哪些日志?

    • 错误日志:记录了当 mysqld 启动和停止时,以及服务器在运行过程中发生任何严重错误时的相关信息。

    • 二进制文件:记录了所有的 DDL(数据定义语言)语句和 DML(数据操纵语言)语句,不包括数据查询语句。语句以“事件”的形式保存,它描述了数据的更改过程。(定期删除日志,默认关闭)。

      就是我们上面看到的 MySQL binlog 日志。

    • 查询日志:记录了客户端的所有语句,格式为纯文本格式,可以直接进行读取。(log 日志中记录了所有数据库的操作,对于访问频繁的系统,此日志对系统性能的影响较大,建议关闭,默认关闭)。

    • 慢查询日志:慢查询日志记录了包含所有执行时间超过参数long_query_time(单位:秒)所设置值的 SQL 语句的日志。(纯文本格式)

      重要,一定要开启。

    另外,错误日志和慢查询日志的详细解释,可以看看 《MySQL 日志文件之错误日志和慢查询日志详解》 文章。

    聊聊 MySQL 监控?

    你是如何监控你们的数据库的?

    监控的工具有很多,例如 Zabbix ,Lepus ,我这里用的是 Lepus

    对一个大表做在线 DDL ,怎么进行实施的才能尽可能降低影响?

    使用 pt-online-schema-change ,具体可以看看 《MySQL 大表在线 DML 神器–pt-online-schema-change》 文章。

    另外,还有一些其它的工具,胖友可以搜索下。

    展开全文
  • 2021大前端技术储备

    千次阅读 2020-12-30 10:38:46
    GMTC全球大前端技术大会是由极客邦科技旗下InfoQ中国主办的技术盛会,关注前端、移动、AI应用等多个技术领域,促进全球技术交流,推动国内技术升级。GMTC为期4天,包括两天的会议和两天的培训课,主要面向各行业前端...

    image-20201229101050657

    GMTC

    GMTC全球大前端技术大会是由极客邦科技旗下InfoQ中国主办的技术盛会,关注前端、移动、AI应用等多个技术领域,促进全球技术交流,推动国内技术升级。GMTC为期4天,包括两天的会议和两天的培训课,主要面向各行业前端、移动开发、AI技术感兴趣的中高端技术人员,大会聚焦前沿技术及实践经验,旨在帮助参会者了解大前端&移动开发领域的技术趋势与实践案例。

    GMTC技术演变

    2016全球移动技术大会

    大会主题

    • 动态化
    • swift
    • 新技术实践RN
    • 客户端性能优化
    • 应用架构
    • VR/AR开发
    • 架构演进
    • 移动解决⽅案

    2017全球移动技术大会(智能时代的大前端)

    大会主题

    • 动态化
    • 性能优化
    • VR/ AR
    • 移动AI
    • 解决⽅案
    • 移动架构
    • 移动web优化
    • web框架实践
    • ⼤前端
    • ⼯程化
    • 质量保证

    2018全球⼤前端技术⼤会

    大会主题

    • 客户端新技术专场
    • 性能优化与监控
    • 解决⽅案
    • 终端AI
    • PWA专场
    • UI与动画
    • web框架专场
    • 跨平台专场
    • ⼯程化
    • Node专场
    • 编程语⾔

    2019全球⼤前端技术⼤会

    大会主题

    • 性能优化与监控
    • UI与图形渲染
    • 质量保证
    • 移动AI
    • 架构演进
    • 跨平台技术Flutter
    • 编程语⾔ts
    • 前端框架
    • 前端⼯程化
    • Node实战
    • 未来移动技术
    • 小程序
    • 前端团队管理

    2020全球前端技术大会

    大会主题

    Flutter 实战

    Flutter 作为革命性的跨终端解决方案,一经推出就获得了广泛关注。新的一年,Flutter 在原有的工程效率和体验侧有什么新的变化?在业务对用户增长和游戏化诉求强烈的今天,Flutter 带来的想象力是什么?Flutter 未来的机会和挑战是什么?

    小程序实战与优化

    随着各大平台小程序的快速放量,开发者遇到越来越多的平台适配问题。各平台小程序的性能优化方法也各不相同。本专场将邀请一线的技术专家为各位带来跨平台小程序框架实现原理,跨平台小程序实战中的一些挑战,以及小程序性能优化的实践案例等等。

    编程语言

    从编程语言方面看,在前端开发领域,JavaScript 一直是当之无愧的王者;在移动开发领域,Objective-C 和 Java 又分别统治着 iOS 和 Android 阵营。最近几年,很多新的语言凭借更现代的语言特性、更高的开发效率,以及背后大厂的支持,应用也越来越广泛。

    跨端框架演进

    Angular、Vue 和 React,前端框架从最初的仅限于 Web 的开发场景逐渐向多端研发开始演进。从最初 Angular 采用的“脏检查” UI 更新方式,到 Vue 3.0 基于 Proxy 的启发式 UI 更新策略。前端框架的底层技术随着标准的不断发展也在不断地进行着创新。

    大前端中台化演进

    伴随着 TOB 场景越来越多,传统的前后端分离的研发模式已经不再满足需求,微“前端”服务的“中台”的作用愈加明显。我们把业务、行业共同点提升到中台完成,成为“大中台、小前端”,能最大程度复用、解耦业务、满足业务敏捷扩展。

    前端安全生产

    随着前端专业技术的发展,前端研发在整个 Web 应用研发工程链路上扮演着越来越重要的角色,前端安全生产的责任也随之放大,在前端应用开发、发布、线上运行的不同阶段,如何让前端工程师产出的代码更加靠谱,不带着问题发布,线上发现前端故障后也能及时止血?

    端侧AI

    人工智能发展已进入“落地为王”阶段,端侧 AI 相比云侧 AI,具有低延时、保护数据隐私、节省云端计算资源等优势,现已成为端侧技术新热点,并且紧贴用户在 AR 特效、搜索推荐等有诸多创新应用。

    Node 实战

    随着大前端的发展,Node.js 也已经发布到 v13,其应用场景从脚手架、辅助前端开发(比如 SSR、PWA 等)的快速开发实践,到 API 中间层、代理层,甚至到后端开发都有非常成熟的经验。本专场将重点邀请一线专家给大家带来他们在各自领域的实战经验。

    大前端工程化

    大前端工程化是指移动端、前端在项目规模、工程复杂度、快速迭代等相同背景下,对一些共性问题的思考。工程化是与实践密不可分的,本专场我们通过分享业内一些经过实践检验的工程化方案,希望能够为大家提供借鉴和帮助。

    性能优化与监控

    性能优化能直接提升用户更快、更流畅的产品体验,在资源受限的移动设备上显得越发重要。通过全链路监控前端、后端、客户端整个通道,拆解用户到达场景下的性能瓶颈,优化整个关键耗时路径,提升产品服务稳定性和速度。

    Serverless 实战

    Serverless 即无服务器技术,是当今炙手可热的方向。因其降低开发成本、按需自动扩缩容、免运维等诸多优势,被越来越多的行业和公司用于更快的构建云上应用。如何让更多的研发团队和开发者,将 Serverless 与自身业务相结合,进行技术升级 ?

    前端前沿技术

    前端技术的发展趋势在最近十年里以惊人的速度向上攀升,而新技术的出现则使得前端从传统的 Web 平台逐渐向外扩展到更多领域。新前端技术的出现源于对业务场景所追求的高性能、高可用性以及高扩展性等多个方面。

    团队建设与管理

    中国互联网产业高速发展,在带动前端行业蓬勃发展的同时,也伴随着成千上万的前端工程师的管理问题。如何在业务达成过程中帮助前端工程师更快成长,如何挖掘工程师的价值考验着每一位前端团队管理者。

    大前端架构演进

    前端和移动端的场景越来越复杂,了解前端架构发展的路径,抽象出其背后的原理,找到变革的驱动力,掌握技术发展的趋势,是学习前端架构的有效途径。 本专场借助几个行业具体的实践案例,谈谈对目前大前端发展趋势和架构演进的理解和展望。

    GMTC的演变

    image-20201229104057703

    大前端时代的焦点

    前端给终端⽤户提供什么?

    • 通过不同端、端侧技术达到最佳的交互体验

    前端能⼲什么? 技术⼿段?

    • 跨端、Node、BFF & Serveless、可视化、IoT、AI等

    前端需要什么 ⼯程设施?

    • 不同场景下的开箱即⽤的⽅案
    • ⼀站式开发体验

    image-20201229105916297

    我们关注什么?

    image-20201229110040655

    前端工程化体系

    基础工程设施

    image-20201229110324346

    工程化工具链形态

    image-20201229111442068

    工程化-平台化时代

    image-20201229111656747

    image-20201229111722227

    云+端时代

    image-20201229111755594

    nodejs应用

    node应用场景演变

    image-20201229141559243

    工具时代

    image-20201229141623502

    web应用

    image-20201229141650223

    BFF应用

    image-20201229141739640

    特点:多端应用、服务聚合

    Serverless去服务器化

    image-20201229143334499

    TypeScript

    越来越多⼈开始使⽤TypeScript

    image-20201229143534841

    node趋势

    image-20201229143651433

    跨平台技术

    image-20201229153000885

    RN与Flutter原理对比

    image-20201229153452524

    Flutter For Web

    image-20201229153538184

    小程序

    image-20201229153615862

    小程序架构选型

    image-20201229153707102

    转换原理:语法树的映射解析 (⽂件格式、命名规则、属性和组件名替换,api的适配等)

    小程序性能优化

    image-20201229154654670

    image-20201229154737044

    性能优化与监控

    关键因素

    • 前端⼈员深⼊理解浏览器,webview 渲染机制
    • 客户端视⻆缓存,不要局限单端视⻆
    • 性能指标监控

    我们能做什么

    image-20201229174523655

    大佬的前端监控的实现

    传送门

    大前端人才需求

    互联网世界离不开前端开发,像淘宝、阿里巴巴、支付宝、腾讯、京东、新浪微博等等大型的基于互联网的企业与产品,都需要优秀的前端高级开发人才。

    不仅仅是互联网企业,随着O2O模式的越来越普及,传统企业越来越互联网化、云端化,前端开发人才需求越来越多,人才缺口高达上百万。

    随着5G落地,云计算、大数据和人工智能领域都赋予大前端开发更广阔的空间,跟上这个时代,抓住人工智能、大数据的风口,来学习前端开发,在这里遇见更优秀的自己

    展开全文
  • 到了5G时代,已经突破传统通信技术人与人之间点对点的通信模式,大量物联网设备和工业设备成为新的联网终端,这使得各行业加速融合,垂直行业的应用也更加多样,产业互联网新生态正在加速形成。 5G或许是第一个为...

    导 读

    回顾整个移动通信发展史,有人说2G时代发短信是最时髦的通信方式,3G时代微信兴起,4G时代手机把衣食住行都“管起来”。

    到了5G时代,已经突破传统通信技术人与人之间点对点的通信模式,大量物联网设备和工业设备成为新的联网终端,这使得各行业加速融合,垂直行业的应用也更加多样,产业互联网新生态正在加速形成。

    5G或许是第一个为各类传感器、机器人、自动驾驶车辆、虚拟现实等智能设备服务的网络,它将重新定义信息技术相关行业,包括从零售到教育,从交通运输到远程医疗,从基础设施到工业制造。

     三大运营商竞速:5G is ON 

    今天,中国联通宣布在国内40个城市开通5G试验网络,这标志着联通5G网络正走向初步规模化部署。而在终端设备上,5G应用进展更加快速,目前以华为、三星、小米、OPPO、中兴等为代表的第一波5G手机已陆续出现,这也标志着中国5G网络已到商用临界点,网络、终端全线成熟,只待5G牌照东风。

    中国联通此前就已在5G技术上动作频频。3月26日,中国联通大连分公司与大连亚明汽车部件股份有限公司正式签署5G战略合作协议,以5G传输为基础,结合VR与IoT技术,应用于企业生产车间,提供智能化人机交互模式,通过传感器采集设备生产数据,借助物联网及远程传输,最终由VR设备进行显现,实现对设备状态、生产流程的远程监控、预警分析和应急处置。

    2月28日,山东联通、中国信通院与海尔共建5G智能制造实验室。以COSMOPlat为基础,海尔工业智能研究院不仅能解决冰箱发泡工艺参数实时监测、自适应控制系统的传感器无线传输问题,令系统能够实时精准采集工艺参数,进行大数据运算并反馈实时控制信号,而且在联合生态资源推出的国内首个机器视觉算法库工具研发及机器视觉通用平台上,完成了算法云平台的5G测试,以此降低机器视觉应用门槛。

    中国移动也在5G新技术、新业务、新生态上不断探索。此前,中国移动联合中控集团,将新安化工园区众多数据采集终端通过5G接入SCADA实时监控系统,满足DCS系统工业控制要求,让企业摆脱传统有线的部署方式,降低生产、维护成本。

    4月10日,中国移动湖北公司与中国信科集团共同发布“5G智慧工厂”项目,这也是我国首条5G智能制造生产线。生产线上,机械手自动焊接、组装,并通过5G网络随时上传工作状态,云端平台统一管理,几乎无需人为干预,而生产效率较改造前提升30%以上。

    中国电信同样不愿缺席这项新技术,2018年4月中国电信携手华为,在深圳基于5G的端到端网络进行了无人机测试;2018年6月中国电信发布了《中国电信5G技术白皮书》,成为全球首个全面阐述5G技术观点和总体策略的运营商。

    2018年9月,中国电信打通首个独立组网的SA呼叫,正式启动了Hello 5G行动计划。在四川成都,中国电信于2018年12月实现了成都二环高架路的5G全覆盖,并在2019年的跨年夜,联手成都在全国首创5G+卫星电视直播。

    可以说,三大运营商都于2018年启动面向商用的大规模组网试验,2019年进入预商用阶段,2020年有望成为5G规模商用元年。

     5G物流的广阔想象

    有人说,智能物流将成为5G率先覆盖的又一商业场景。以京东物流为例,3月20日其宣布率先于上海建设国内首个5G智能物流示范园区,依托5G网络通信技术,通过AI、IoT、自动驾驶、机器人等智能物流技术和产品融合应用,打造高智能、自决策、一体化的智能物流示范园区。

     

    除此之外,京东物流还将同时在北京亚一、物流全链路可视化监控、机器人智能配送等多个物流场景进行5G应用部署。

    在数字化仓库中,自动入仓及出仓匹配、实时库容管理、仓储大脑和机器人无缝衔接、AR作业、包裹跟踪定位等场景,5G技术也将发挥重要作用。

    根据规划,园区将通过自动识别仓内商品实物体积,匹配最合理车辆,提升满载率;借助仓储大脑实现所有搬运、拣选、码垛机器人互联互通和调度统筹,及仓内叉车、托盘、周转筐等资产设备的定位跟踪;通过AR眼镜帮助操作员自动识别商品,并结合可视化指令辅助作业;实现包裹实时追踪和全程视频监控,方便商家、客户随时查询包裹情况并进行履约超时预警。

    除了电商物流外,在产线物流领域,斯坦德机器人CEO王永锟则指出,5G可能会改变工厂的运作模式,AGV作为工厂物流的关键一环,5G会带来很多使用方式、维护方式上的新模式。

    总之,与AI、IoT、自动驾驶等一样,5G未来将成为智能物流发展必不可少的技术前提。

     机器人+5G+AI的未来工厂 

    去年以来,作为“工业互联网第一股”的工业富联已经抢先布局5G时代网络布建与数据传输,完成5G小基站、用户设备、MIMO天线等5G发展初期关键技术的开发。

    “我们在3G、4G时代就已经做了很多,经过了多年的积累,已有专门的全球化团队去做5G。”工业富联总经理郑弘孟表示,公司会在云、工业互联网、机器人、5G等领域持续投入,其中5G投入会扩大,将不只做基站的硬件,更要致力于5G的应用,提供一个完整的解决方案;不仅仅采集数据,而是用数据驱动应用,创造价值。

    郑弘孟还透露,今年公司的5G产品将会出货,“目前有两家世界级的客户,产品包括开路式设备、终端使用产品、EPC产品等。” 

    除了工业富联以外,中兴通讯已经做出展示级的5G智能制造、5G远程控制机器人、5G MEC云VR及物联网、智慧视频分析等5G相关行业应用。

    在智能制造领域,中兴模拟了智能工厂中手机屏幕的质检和视频远程指导、生产环境视频监控场景,展示了中国首款基于真实5G网络实现远程控制的机器人。据称,对机器人毫秒级的远程实时控制,时延比目前4G或Wi-Fi网络最高可缩短近百倍。

    中兴通讯副总裁崔丽表示,5G将催生“瘦终端”。5G的超宽带使云端和本地已经没有差异了,许多应用可以放到云端,这将使终端更加简洁,“变瘦”的终端也会更便宜,使消费者节省了成本。“云端机器人一定比你单独买一个大的机器人要便宜很多。”

    为了迎接即将到来的5G时代,国外相关厂商也在加紧布局。电装已经开始在旗下的自动化工厂对配置了5G通讯系统的工业机器人进行实证试验。

    采用5G技术后,工厂内的有线线路将会被移动通讯所取代,也就可以省略掉原本必不可少的通讯线路重新铺设的步骤。同时,在引入高精度三次元测量传感器后,调试机器人动作的环节,可以将传感器捕获的信息经由5G进行大量传送,从而节省人力与时间成本,提升工厂建设的灵活性,也大大缩短了因制造工序变更而造成工厂停运的时间。

    本次实证试验在布设了28GHz频段5G基站的试验区内进行,将高精度三次元测量传感器与机器人对应5G端口相连接,就可以通过5G进行测量数据和控制数据的传送,进而对机器人进行高精度控制。

    除此之外,诺基亚和博世合作开发一个基于5G及专网下的工作系统,帮助博世实现定制化工业生产,并进行现场监控,大幅提升产品质量。高通针对机器人领域推出专用平台RB3,该平台有着经高度优化后的硬件、软件和开发工具,旨在帮助制造商和开发者们制造下一代机器人。RB3平台计划在今年晚些时候支持5G连接,以满足工业机器人应用对于低时延、高吞吐量的需求

     布局5G,慢了半拍or为时过早 

    总体来看,5G对于整个机器人行业来说还处于技术储备阶段。如华数机器人总经理杨海滨所言:“有实力的机器人制造商和集成商都会关注5G,在物联网、大数据、自动化控制、物流追踪、云机器人等领域,5G技术将发挥支撑作用;同时,企业也会积极探索与5G相关的产品和产线带来的技术变革。”

    在配天机器人副总经理索利洋看来,最关注的是机器人在相关领域如何与5G技术融合并优化自身的产品。“凡是用到高速数据通信的领域都可以探索,比如说工业总线等。但是也要看5G通信的可靠性。”

    节卡机器人总经理李明洋认为,5G技术普及和提升对JAKA节卡机器人而言是重大的战略机遇,这与节卡小助系列协作机器人“无线协作,全球互联”的研发初衷相契合。

    “5G的进一步落地,有助于节卡机器人远程编程、调试、维护方面的进一步提升用户体验,同时依托云计算及5G的超高速通信,节卡正在打造新一代协作机器人关节技术。”李明洋指出,每一个企业的产品和产业链定位不一样,所以对机器人的通讯及运算能力要求不一样。对于协作机器人企业而言,现在布局5G,可能已经晚了半拍。

    大象机器人CEO宋君毅对于5G技术在机器人物联网、远程控制与监控方面的应用前景表示认同。“这对于未来做远程教学会有更好的体验,用VR+实时教学也是可以尝试的方法;此外还不需要实地去到国外进行机器人的维护维修。”

    而在远程维护应用方面,宋君毅也指出,现在谈5G,还为时略早,“首先5G网络还没有搭建起来,我们的想法还没有实施;其次与各家的业务类型和业务量有很大关系,如果都是国内客户,让系统集成商前往就可以搞定,如果国外客户,就要考虑能否实现‘VR+’,前提是国外也实现了5G覆盖。”他认为,底层建设决定上层建筑,先等5G搭起来再说也不迟。

    据预计,到2020年,5G将需要连接500亿台智能设备和77亿人。正如腾讯CEO马化腾所说:“把5G网络看做一把钥匙,它能够帮我们解锁原先难以数字化的现实场景,让数字技术以更小的颗粒度重塑现实世界。”5G浪潮下的机器人时代更值得期待了。

    品略图书馆 http://www.pinlue.com/

    免责声明:北大创新评论

     

     

    展开全文
  • 本文讲的是人才储备不足映射出“大数据”技术缺陷,根据咨询师和IT经理的观点,“大数据”分析的最大挑战可以简单地归结为两个方面:1、技术尚未成且用户体验不佳;2、缺乏相关领域的技术人才储备。  许多大数据技术...
  • 基于物品的协同过滤算法实现图书推荐系统

    万次阅读 多人点赞 2019-09-14 21:20:24
    目录 摘 要 ABSTRACT 第一章 概述 1.1课题背景及意义 1.2推荐系统的发展历史 1.3推荐系统的研究内容 第二章 开发平台及技术 2.1开发平台 2.1.1系统开发环境介绍 2.1.2 数据库系统介绍 2.1.3 开发工具介绍 2.2 开发...
  •  在测试的过程中对于测试技能的储备,是一项非常重要的工作,不能总之把希望寄托在测试本身,必须要有一些方法来强制性的让测试对测试过程中需要用到的测试技能充分理解和运用,比如定期的组织测试在一起...
  • Linux运维工程师、系统管理、网站架构师 技能专长 【写出来的必须能说清,重点不能去掉,保留10条左右】 工作经验 项目经验【简历上写5个】 以下是列出: 一 二、 三 。四 五、 六、七 八、 九、 十、 ...
  • 利用全概率分解技术和拉普拉斯变换工具, 分别讨论了在两类故障模式下服务台的瞬态不可用度和稳态不可用度, (0,t]时间内的平均故障次数和稳态故障频度等可靠性指标, 进一步还讨论了服务台由温储备失效引起等待修理的...
  • 数据结构相关知识储备

    千次阅读 2020-07-22 19:50:33
    幻读:系统管理 A 将数据库中所有学生的成绩从具体分数改为 ABCDE 等级,但是系统管理B就在这个时候插入了一条具体分数的记录,当系统管理 A 改结束后发现还有一条记录没有改过来,就好像发生了幻觉一样,这...
  • 技术到管理 前几天分享过 全球技术领导力峰会的一些心得。那么这个心得里提到过一个观点,这也是很多技术讲师共同的观点,就是互联网上有大量的技术资源可以利用,学会整合现有的...
  • 疫情下技术人的宅家指南

    千次阅读 多人点赞 2021-01-18 01:17:08
    作为一名技术宅,虽说疫情对我的影响可以忽略不计,不过我还是疫情能够早日结束的。毕竟我们每个人都是社交动物,隔离14天真的是太让人绝望了。再说我们绝大多数人的春节假期也不过7天,这一口气直接隔离14天,简直...
  • 转自云狄 阿里高级技术专家的一篇文章 阿里妹导读:技术主管,又叫「技术经理」,英文一般是 Tech Leader ,简 称 TL。随着工作经验的不断积累,能力的不断提升,每个人都有机会成为 Team Leader。然而在机会到来...
  • 我是一个退休公务,也是一名从年轻时就迷恋电子制作的业余爱好者。而电子制作的核心是制作一块功能齐全,而又美观漂亮的电路板(即PCB板)。不管你是不是“发烧友”,哪怕制作一件简单的作品,都要经过设计——制...
  • 导读:寒冬中,最值得投资的是学习,是增厚的知识储备。下面就是20位阿里技术大牛们为我们推荐的经典书籍。书籍类型涉及技术、管理、哲学等方面,希望这些书籍陪伴你度过这个漫长的寒冬。书单之外,还有成长感悟。 ...
  • 点击上方“蓝色字”可关注我们!暴走时评:对于与美元挂钩的稳定币USDT运营公司的Tether有限公司,投资者一直存在着一个疑问:它是否拥有足够的现金储备以支持其18亿枚代...
  • 技术人员通往财务自由之路

    千次阅读 2017-09-22 12:21:08
    ,即通过你所储备的知识、技能、经验、框架等帮助别人解决问题的能力。 热爱分享的开发者还会拥有另一项核心竞争力:写作。 软件开发、讲授、写作、咨询这四种能力,构成了开发者走向财务...
  • 中国的人才储备概况

    千次阅读 2008-01-22 14:25:00
    1.中国的人才储备概况(一) 高等教育资源到2003年,全国共有普通高等学校和成人高等学校2241所。普通高等学校1683所,其中本科院校636所,高职(专科)院校1047所。另外还有成人高等学校558所。全国共有培养研究生...
  • 每一个优秀交易注定是孤独的。他的交易系统,是对交易与市场的理解、对自身认识的综合体现,也体现了理念与信仰,还有性格。这不是其他人能学到和理解得了的。我试试,能写多少就写多少,助人也自助。人,
  • 从本质上说,运维其实是用自己的技术储备知识,保证自己所管理的IT服务可以正常运转的岗位。 举个例子,在公司里经常会有妹子找软件开发工程师修电脑,而软件工程师一般就是关机重启;但是很少会有人去找运维工程师...
  • 密码安全攻防技术精讲

    千次阅读 2018-07-03 02:45:09
    本课程内容将以作者亲身经历的事情为主,从技术的视野和攻防角度来剖析各种密码及其他技术对工作和个人生活的影响,将“高高在上”的技术拉进我们日常的生活中来。每一篇文章都是精挑细选的典型案例,背后都有真实...
  • 嘉宾:姜波,电子和计算机工程博士,现任学霸君研究资深研究,现主要负责基于深度学习技术的文档图像智能分析。研究方向:多尺度图像处理、通用视觉模式识别、目标检测、跟踪和识别、深度学习,以及基于并行...
  • 短信储备知识

    2014-03-03 15:37:47
    1、 网关:不同网络之间的翻译器,A网和B网是两个高层协议不同的网络,A网中主机a想发包给B网主机b,则a发送的包先进A网网关,A网网关把包发送给B网网关,B网网关将包发给b 网关的具体形式是路由器的...怎么才能让外地
  • ... 仔细观察你会发现,技术高手都有这两个习惯:保持对最新技术趋势的敏感性,并定期更新自己的技能储备。有没有一种高效的方式来做到呢?我觉得最好的方法,就是直接向 BAT 等一线...
  • 因为斯蒂芬·普拉塔十分在意读者在阅读过程中的阅读体验,所以书中新出现的每一个术语,符号,都给出贴近读者目前知识储备的和理解能力的解释。 而且,这本书在编排上也十分与众不同,在每个知识点后面都会附带一个...
  • NoSQL世界还会有DBA存在吗

    千次阅读 2014-02-28 10:54:43
    NoSQL世界还会有DBA存在吗 作者:chszs,转载需注明。博客主页: ...咨询公司Gartner在本月初发布了一项...开发者继续控制着应用程序的生命周期,而DBA则需要从数据库管理转换为数据服务管理。DBA的角色会转变为DSA。
  • 12 月 7 - 9 日,由中国计算机学会主办,CCF 大数据专家委员会承办,中国科学院计算技术研究所、中科天玑数据科技股份有限公司、CSDN 协办的 2017 中国大数据技术大会(BDTC 2017)在北京新云南皇冠假日酒店盛大召开...
  • 大秀了一把“技术肌肉”,将产业互联网和消费互联网的新成果、新技术、新应用集中分享出来,技术储备着实令人惊叹。 聊聊“这张网”。 作为运营着亚洲最大网络、服务器集群和数据中心 的部门 ,TEG搭建的腾讯...
  • 如果你喜欢技术,那大可放心,随着国家的发展,对技术的尊重,总有一天会有类似国外工程师的环境,五六十岁还做一个纯正的工程师,也没有什么不可以的。如果仅把工作作为一个养家糊口的工具,那也没有问题,FPGA将...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 8,979
精华内容 3,591
关键字:

储备技术员