面试问题复盘

Skr-Eric

已于 2022-03-02 16:14:34 修改

阅读量604

点赞数

分类专栏：面试遇到的一些问题文章标签：面试 mysql linux

于 2022-02-27 17:18:25 首次发布

本文链接：https://blog.csdn.net/skr_eric/article/details/123125955

版权

面试遇到的一些问题专栏收录该内容

9 篇文章 0 订阅

订阅专栏

本文探讨了数据库登录加密的方法、MySQL索引优化技巧，区分何时创建和不创建索引，以及MongoDB与MySQL的适用场景。还涵盖了千万级表优化、RESTful API开发、Vue生命周期管理与Redis应用实例。

摘要由CSDN通过智能技术生成

1、登录系统是如何加密的，怎么处理？

用户注册登录系统加密方案分析与实践

https://blog.csdn.net/Saintyyu/article/details/102754194

Django密码系统实现过程详解

https://www.jb51.net/article/165785.htm

2、mysql如何调优

3、怎么判断哪些是要加索引哪些不用

1. 较频繁的作为查询条件的字段应该创建索引
提高数据查询检索的效率最有效的办法就是减少须要访问的数据量，从上面索引的益处中我们知道，索引正是减少通过索引键字段作为查询条件的 Query 的IO量之最有效手段。所以一般来说应该为较为频繁的查询条件字段创建索引。
2. 唯一性太差的字段不适合单独创建索引，即使频繁作为查询条件
唯一性太差的字段主要是指哪些呢？如状态字段、类型字段等这些字段中存放的数据可能总共就是那么几个或几十个值重复使用，每个值都会存在于成千上万或更多的记录中。对于这类字段，完全没有必要创建单独的索引。因为即使创建了索引，MySQL Query Optimizer 大多数时候也不会去选择使用，如果什么时候 MySQL Query Optimizer选择了这种索引，那么非常遗憾地告诉你，这可能会带来极大的性能问题。由于索引字段中每个值都含有大量的记录，那么存储引擎在根据索引访问数据的时候会带来大量的随机IO，甚至有些时候还会出现大量的重复IO。
这主要是由于数据基于索引扫描的特点引起的。当我们通过索引访问表中数据时，MySQL 会按照索引键的键值顺序来依序访问。一般来说，每个数据页中大都会存放多条记录，但是这些记录可能大多数都不会和你所使用的索引键的键值顺序一致。
假如有以下场景，我们通过索引查找键值为A和B的某些数据。在通过A键值找到第一条满足要求的记录后，会读取这条记录所在的 X 数据页，然后继续往下查找索引，发现 A 键值所对应的另外一条记录也满足要求，但是这条记录不在 X 数据页上，而在Y数据页上，这时候存储引擎就会丢弃X数据页，而读取Y数据页。如此继续一直到查找完A键值所对应的所有记录。然后轮到B键值了，这时发现正在查找的记录又在X数据页上，可之前读取的 X 数据页已经被丢弃了，只能再次读取 X 数据页。这时候，实际上已经重复读取 X 数据页两次了。在继续往后的查找中，可能还会出现一次又一次的重复读取，这无疑给存储引擎极大地增加了IO访问量。
不仅如此，如果一个键值对应了太多的数据记录，也就是说通过该键值会返回占整个表比例很大的记录时，由于根据索引扫描产生的都是随机 IO，其效率比进行全表扫描的顺序IO效率低很多，即使不会出现重复 IO 的读取，同样会造成整体 IO 性能的下降。
很多比较有经验的 Query 调优专家经常说，当一条Query返回的数据超过了全表的 15%时，就不应该再使用索引扫描来完成这个 Query 了。对于"15%"这个数字我们并不能判定是否很准确，但是至少侧面证明了唯一性太差的字段并不适合创建索引。
3. 更新非常频繁的字段不适合创建索引
上面在索引的弊端中已经分析过了，索引中的字段被更新的时候，不仅要更新表中的数据，还要更新索引数据，以确保索引信息是准确的。这个问题致使IO 访问量较大增加，不仅仅影响了更新 Query 的响应时间，还影响了整个存储系统的资源消耗，加大了整个存储系统的负载。
当然，并不是存在更新的字段就适合创建索引，从判定策略的用语上也可以看出，是"非常频繁"的字段。到底什么样的更新频率应该算是"非常频繁"呢？每秒？每分钟？还是每小时呢？说实话，还真难定义。很多时候是通过比较同一时间段内被更新的次数和利用该字段作为条件的查询次数来判断的，如果通过该字段的查询并不是很多，可能几个小时或是更长才会执行一次，更新反而比查询更频繁，那这样的字段肯定不适合创建索引。反之，如果我们通过该字段的查询比较频繁，但更新并不是特别多，比如查询几十次或更多才可能会产生一次更新，那我个人觉得更新所带来的附加成本也是可以接受的。
4. 不会出现在 WHERE 子句中的字段不该创建索引

4、什么情况下索引会失效

1.用or连接的其中有一个字段未加索引;
2.复合索引未用左列字段;
3.like以%开头;
4.需要类型转换;
5.where中索引列有运算;
6.where中索引列使用了函数;
7.如果mysql觉得全表扫描更快时（数据少）;

什么时没必要用

1.唯一性差;
2.频繁更新的字段不用（更新索引消耗）;
3.where中不用的字段;
4.索引使用<>时，效果一般;

对查询进行优化,尽量避免全表扫描,避免导致索引失效

在where子句中进行null值判断的话会导致引擎放弃索引而产生全表扫描

SELECT id FROM table WHERE num is null

在建立数据库的时候因尽量为字段设置默认值,如int类型可以使用0,varchar类型使用 ''
当你在指定类型大小如int(11)时,其实空间就已经固定了,即时存的是null也是这个大小

避免在where子句中使用!= ,< >这样的符号,否则会导致引擎放弃索引而产生全表扫描

SELECT id FROM table WHERE num != 0

避免在where子句中使用or来连接条件,因为如果俩个字段中有一个没有索引的话,引擎会放弃索引而产生全表扫描

SELECT id FROM table WHERE num = 0 OR num = 1

可以考虑使用between,但是只能是连续的数值

SELECT id FROM table WHERE num BETWEEN 0 AND 1

避免在where子句中使用int关于网上说的MySQL在使用int不走索引的问题,严谨的来说的话分为俩种情况
- 走索引的

SELECT id FROM table WHERE num IN (1)

- 不走索引的

SELECT id FROM table WHERE num IN (1,2)
其实在in里面,如果只有一个值的话是等价于num = 1的

避免在where子句中=的左边使用表达式操作或者函数操作
- 表达式

SELECT id FROM table WHERE num / 2 = 1

- 函数操作

SELECT id FROM table WHERE SUBSTRING(name,1,2) = 'wise'

避免在where子句中使用like模糊查询

SELECT id FROM table WHERE name LIKE 'wise'

在使用联合索引是要注意最左原则,例如如果当前联合索引是index(a,b,c),那么如果where子句中有a就会用到联合索引,但是如果只用到b,c就会失去索引效果

SELECT id FROM table WHERE name LIKE 'wise'

5、为什么要选择mongodb，他和mysql的区别

1、MongoDB的应用场景

1）表结构不明确且数据不断变大
MongoDB是非结构化文档数据库，扩展字段很容易且不会影响原有数据。内容管理或者博客平台等，例如圈子系统，存储用户评论之类的。
2）更高的写入负载
MongoDB侧重高数据写入的性能，而非事务安全，适合业务系统中有大量“低价值”数据的场景。本身存的就是json格式数据。例如做日志系统。
3）数据量很大或者将来会变得很大
Mysql单表数据量达到5-10G时会出现明细的性能降级，需要做数据的水平和垂直拆分、库的拆分完成扩展，MongoDB内建了sharding、很多数据分片的特性，容易水平扩展，比较好的适应大数据量增长的需求。
4）高可用性
自带高可用，自动主从切换（副本集）

不适用的场景
1）MongoDB不支持事务操作，需要用到事务的应用建议不用MongoDB。
2）MongoDB目前不支持join操作，需要复杂查询的应用也不建议使用MongoDB。

2、关系型数据库和非关系型数据库的应用场景对比

关系型数据库适合存储结构化数据，如用户的帐号、地址：
1）这些数据通常需要做结构化查询，比如join，这时候，关系型数据库就要胜出一筹
2）这些数据的规模、增长的速度通常是可以预期的
3）事务性、一致性
　　
NoSQL适合存储非结构化数据，如文章、评论：
1）这些数据通常用于模糊处理，如全文搜索、机器学习
2）这些数据是海量的，而且增长的速度是难以预期的，
3）根据数据的特点，NoSQL数据库通常具有无限（至少接近）伸缩性
4）按key获取数据效率很高，但是对join或其他结构化查询的支持就比较差

6、oracle和mysql的区别

(1) 对事务的提交
MySQL默认是自动提交，而Oracle默认不自动提交，需要用户手动提交，需要在写commit;指令或者点击commit按钮

(2) 分页查询
   MySQL是直接在SQL语句中写"select... from ...where...limit x, y",有limit就可以实现分页;而Oracle则是需要用到伪列ROWNUM和嵌套查询
(3) 事务隔离级别
      MySQL是read commited的隔离级别，而Oracle是repeatable read的隔离级别，同时二者都支持serializable串行化事务隔离级别，可以实现最高级别的
   读一致性。每个session提交后其他session才能看到提交的更改。Oracle通过在undo表空间中构造多版本数据块来实现读一致性，每个session
   查询时，如果对应的数据块发生变化，Oracle会在undo表空间中为这个session构造它查询时的旧的数据块
    MySQL没有类似Oracle的构造多版本数据块的机制，只支持read commited的隔离级别。一个session读取数据时，其他session不能更改数据，但
   可以在表最后插入数据。session更新数据时，要加上排它锁，其他session无法访问数据
(4) 对事务的支持
   MySQL在innodb存储引擎的行级锁的情况下才可支持事务，而Oracle则完全支持事务
(5) 保存数据的持久性
   MySQL是在数据库更新或者重启，则会丢失数据，Oracle把提交的sql操作线写入了在线联机日志文件中，保持到了磁盘上，可以随时恢复
(6) 并发性
   MySQL以表级锁为主，对资源锁定的粒度很大，如果一个session对一个表加锁时间过长，会让其他session无法更新此表中的数据。
虽然InnoDB引擎的表可以用行级锁，但这个行级锁的机制依赖于表的索引，如果表没有索引，或者sql语句没有使用索引，那么仍然使用表级锁。
Oracle使用行级锁，对资源锁定的粒度要小很多，只是锁定sql需要的资源，并且加锁是在数据库中的数据行上，不依赖与索引。所以Oracle对并
发性的支持要好很多。
(7) 逻辑备份
   MySQL逻辑备份时要锁定数据，才能保证备份的数据是一致的，影响业务正常的dml使用,Oracle逻辑备份时不锁定数据，且备份的数据是一致
(8) 复制
   MySQL:复制服务器配置简单，但主库出问题时，丛库有可能丢失一定的数据。且需要手工切换丛库到主库。
   Oracle:既有推或拉式的传统数据复制，也有dataguard的双机或多机容灾机制，主库出现问题是，可以自动切换备库到主库，但配置管理较复杂。
(9) 性能诊断
   MySQL的诊断调优方法较少，主要有慢查询日志。
   Oracle有各种成熟的性能诊断调优工具，能实现很多自动分析、诊断功能。比如awr、addm、sqltrace、tkproof等
(10)权限与安全
   MySQL的用户与主机有关，感觉没有什么意义，另外更容易被仿冒主机及ip有可乘之机。
   Oracle的权限与安全概念比较传统，中规中矩。
(11)分区表和分区索引
   MySQL的分区表还不太成熟稳定。
   Oracle的分区表和分区索引功能很成熟，可以提高用户访问db的体验。
(12)管理工具
   MySQL管理工具较少，在linux下的管理工具的安装有时要安装额外的包（phpmyadmin， etc)，有一定复杂性。
   Oracle有多种成熟的命令行、图形界面、web管理工具，还有很多第三方的管理工具，管理极其方便高效。
(13)最重要的区别
   MySQL是轻量型数据库，并且免费，没有服务恢复数据。
   Oracle是重量型数据库，收费，Oracle公司对Oracle数据库有任何服务。

(13) 自动增长的数据类型处理
          MYSQL有自动增长的数据类型，插入记录时不用操作此字段，会自动获得数据值。ORACLE没有自动增长的数据类型，需要建立一个自动增长的序列号，插入记录时要把序列号的下一个值赋于此字段。
CREATE SEQUENCE 序列号的名称 (最好是表名+序列号标记) INCREMENT BY 1        START        WITH        1 MAXVALUE        99999        CYCLE        NOCACHE;
其中最大的值按字段的长度来定, 如果定义的自动增长的序列号 NUMBER(6) , 最大值为999999
INSERT 语句插入这个字段值为: 序列号的名称.NEXTVAL
(14) 单引号的处理
          MYSQL里可以用双引号包起字符串，ORACLE里只可以用单引号包起字符串。在插入和修改字符串前必须做单引号的替换：把所有出现的一个单引号替换成两个单引号。
(15)  翻页的SQL语句的处理
          MYSQL处理翻页的SQL语句比较简单，用LIMIT 开始位置, 记录个数；PHP里还可以用SEEK定位到结果集的位置。ORACLE处理翻页的SQL语句就比较繁琐了。每个结果集只有一个ROWNUM字段标明它的位置, 并且只能用ROWNUM<100, 不能用ROWNUM>80。

(16) 长字符串的处理
长字符串的处理ORACLE也有它特殊的地方。INSERT和UPDATE时最大可操作的字符串长度小于等于4000个单字节, 如果要插入更长的字符串, 请考虑字段用CLOB类型，方法借用ORACLE里自带的DBMS_LOB程序包。插入修改记录前一定要做进行非空和长度判断，不能为空的字段值和超出长度字段值都应该提出警告,返回上次操作。

(17) 日期字段的处理
           MYSQL日期字段分DATE和TIME两种，ORACLE日期字段只有DATE，包含年月日时分秒信息，用当前数据库的系统时间为SYSDATE, 精确到秒，或者用字符串转换成日期型函数TO_DATE(‘<st1:chsdate isrocdate="False" islunardate="False" day="1" month="8" year="2001">2001-08-01</st1:chsdate>’,’YYYY-MM-DD’)年-月-日 24小时:分钟:秒的格式YYYY-MM-DD HH24:MI:SS TO_DATE()还有很多种日期格式, 可以参看ORACLE DOC.日期型字段转换成字符串函数TO_CHAR(‘<st1:chsdate isrocdate="False" islunardate="False" day="1" month="8" year="2001">2001-08-01</st1:chsdate>’,’YYYY-MM-DD HH24:MI:SS’)
    日期字段的数学运算公式有很大的不同。MYSQL找到离当前时间7天用 DATE_FIELD_NAME > SUBDATE（NOW（），INTERVAL 7 DAY）ORACLE找到离当前时间7天用 DATE_FIELD_NAME >SYSDATE - 7;
(18) 空字符的处理
           MYSQL的非空字段也有空的内容，ORACLE里定义了非空字段就不容许有空的内容。按MYSQL的NOT NULL来定义ORACLE表结构, 导数据的时候会产生错误。因此导数据时要对空字符进行判断，如果为NULL或空字符，需要把它改成一个空格的字符串。
(19)字符串的模糊比较
          MYSQL里用字段名 like '%字符串%',ORACLE里也可以用字段名 like '%字符串%' 但这种方法不能使用索引, 速度不快，用字符串比较函数 instr(字段名,'字符串')>0 会得到更精确的查找结果。
(20)程序和函数里，操作数据库的工作完成后请注意结果集和指针的释放。

7、千万级别的表如何优化

MySQL 对于千万级的大表要怎么优化？ - 知乎

8、说一下restful api开发

RESTful API 设计指南 - 阮一峰的网络日志
9、vue的生命周期

谈谈vue生命周期-看了这篇你就懂了 - 简书

Vue - 生命周期详解 - 简书

10、什么情况会用到redis

● 不需要实时更新但是又极其消耗数据库的数据。比如网站上商品销售排行榜，这种数据一天统计一次就可以了，用户不会关注其是否是实时的。

● 需要实时更新，但是更新频率不高的数据。比如一个用户的订单列表，他肯定希望能够实时看到自己下的订单，但是大部分用户不会频繁下单。

● 在某个时刻访问量极大而且更新也很频繁的数据。这种数据有一个很典型的例子就是秒杀，在秒杀那一刻，可能有N倍于平时的流量进来，系统压力会很大。但是这种数据使用的缓存不能和普通缓存一样，这种缓存必须保证不丢失，否则会有大问题。
一般地，Redis可以用来作为MySQL的缓存层。为什么MySQL最好有缓存层呢？想象一下这样的场景：在一个多人在线的游戏里，排行榜、好友关系、队列等直接关系数据的情景下，如果直接和MySQL正面交手，大量的数据请求可能会让MySQL疲惫不堪，甚至过量的请求将会击穿数据库，导致整个数据服务中断，数据库性能的瓶颈将掣肘业务的开发；那么如果通过Redis来做数据缓存，将大大减小查询数据的压力。在这种架子里，当我们在业务层有数据查询需求时，先到Redis缓存中查询，如果查不到，再到MySQL数据库中查询，同时将查到的数据更新到Redis里；当我们在业务层有修改插入数据需求时，直接向MySQL发起请求，同时更新Redis缓存。

深入分析Redis特点及应用场景 - 简书