问题总结:
整个过程大致是经历了项目拷打,基础八股文测试基础理论,最后手撕数字字符串转数字
接下来是一些提问和回答
Q:看简历你是做了豆瓣这个项目,在这个项目你实现了什么功能?
A:歌手服务,歌单服务
Q:歌手歌单服务的业务流程你是怎么设计和实现的?
A:(这里支支吾吾说不上来)。大概答了思路是通过爬虫爬取原豆瓣FM页面的数据,并且经过对爬取的数据进行重新组装实现的。复盘后觉得可以回答自己对歌手,歌曲这两个模型设计的理解,从实际的业务,到抽象的模型一共是经历了3层抽象的提取。歌手和歌曲是最基础的两个模型,能够作为直接对象输出数据展示在前端,在这两者的基础上,豆瓣FM里还对应了不同的板块,每个板块内还整合了各种不同的主题。因为每个板块都对应了一类的主题,那如果说有5个不同的板块,那我们就要创建五个不同的类,那样的极大的增加了代码的复杂程度和代码量。所以在此基础上我们再主题进行抽象,将主题抽象成一个类,设置一个属性:子类型sujectSubType用来区分不同的主题。再设置了name属性来区分不同的板块名称。类的数量减少,通用性增强了。再经过分析其实兆赫功能和歌单功能类似,只是多组合了个歌曲,所以可以再抽象一个属性subjectType来区分两者,最终非常复杂的一套系统,其实最终只有一个主要的Subject类作为存储数据的类,而作为Singer和Song这两个基础的类就可以通过Subject的数据进行组装。整套系统主要的3个类就可以完成多数的复杂功能。
Q:数据库有了解过吗?MySQL分页查询是怎么实现的?
A:(这里也是答不上来)。其实我是用了MyBatis支持的分页插件pagehelper,基本让我不用额外处理Mybatis XML的逻辑。直接使用doSelectPage的方法自动执行分页逻辑,返回分页对象Page。
合理解释:SELECT 字段列表 FROM 表名 LIMIT 起始索引,查询记录数;
Q:SQL写过吗?现在想要查询某个分数表中分数排序最高的前三位,在评论区写一下。
A:(内心崩溃了这个也没答上来,之前光顾着刷笔试题,面经一点没看直接面试了,大家别学我)
合理解释:SELECT name FROM user ORDER BY score DESC LIMIT 3;
Q:现在有a,b,c三张表,是ac关联b查询快比单是查询b表快,为什么?
A:(这里的话没太理解问的问题什么意思,估计是想问单个索引和组合索引哪个效率高。)
合理解释:组合索引 比对每个列分别建索引更有优势,因为索引建立得越多就越占磁盘空间,在更新数据的时候速度会更慢。另外建立多列索引时,顺序也是需要注意的,应该将严格的索引放在前面,这样筛选的力度会更大,效率更高。
结论:全文索引 > 联合索引 > json函数查询 > like查询
数据量越大,全文索引速度越明显,就10万的量,查询速度大概比直接查询快了20倍左右,如果是百万或千万级别的表,提升差距会更加大,所以有条件还是老老实实用全文索引吧
手撕代码:数字字符串转数字(简单题,数字里有小数点,用进位法的思路解决本题)
Q:用户登录注册怎么实现?数据库存储的密码加密处理用的是什么算法?
A:(没答上来)
合理解释:在用户注册过程中,对密码首先进行一个加盐值的处理,在对其使用md5算法生成唯一对应的序列,然后保存在数据库中,当需要登录检测时候,也对输入的密码进行加盐处理,md5算法转化,然后和数据库中已经得密码进行比对。
Q:解释一下Cookie和Session的区别,说说Session在你的项目中是怎么存储的
A:(学过好多东西都忘了,这个也没答上来)
合理解释:Cookie和Session的主要区别呢是,一个保存在本地的浏览器,一个存储在服务器中,当用户第一次登录注册的时候,用户将他的userid发送给我们的服务器,服务器接受之后生成一个唯一的sessionId保存在服务器内,同时以Cooie为载体返回给客户端,客户端将含有sessionId的cookie保存在本地中,每当客户端想访问其他页面的时候,就不在需要重复验证,只需要从cookie中去除sessionId,看看是否已经在服务器端存在了,如果存在则正常访问,否则跳转验证页面
面试心得体会:
1.老老实实准备好再来面试,不然真的会被拷打得很惨
2.MySQL是一个面试中非常关注的技术点,可以下点功夫去学习MySQL,让其成为自己的一个技术亮点,之后也会在博客里来发布自己对《高性能MySQL》这一本的学习
3.虽然秋招很难,但是永远对编程有热爱,合理面对每次的面试结果,从失败中总结经验教训,如果失败没有反思,失败只会失败之母。
同各位一起共勉,加油,奥利给