从一道面试题谈起

发表于 | 分类于 | 次

从一道面试题谈起

这是一道BAT 的面试题，针对的是应届生，其实我觉得这种题目也适合所有面试人，比刷算法题、八股文要有用、实际多了

题目

给你几天时间自己在家可以借助任何资源用测试工具Sysbench 完成一次MySQL数据的性能测试，并编写测试报告(自行搭建数据库)

sysbench压MySQL常用有只读、读写、只写、update等6个场景

结果

这个候选人把他的结果发给我看了，我看完一惊要坏事，这个结果估计要不及格了

他用 sysbench 跑了一下只读、读写、只写等场景然后截图就没有了！

image-20230908223348050

(如上图，大概就是6/7个这样的截图就没有了！)

我看到这个结果是很震惊的，你希望面试官挨个去看截图？最起码要有测试结果表格当做结论汇总吧。

如果你不知道怎么做可以先去搜一下别人做的测试报告，你可以按照别人的测试流程完全走一遍，基本算是模仿，要有结论的话也能得60分。

60分的答案

每个场景增加1/8/16/32等并发，然后按照6个场景不同并发做成一个表格，并观察rt、cpu的指标最后汇总形成图表、给出结论分析，比如拐点在哪里、为什么

我觉得这个面试题好就好在这里的分析可以无穷展开，适合新手也适合多年的老手，任何结论理由你都可以写上去，只要有理有据有分析

80分的答案

给自己出一个拟题，比如对比5.7和8.0的性能差异，8.0相对5.7在哪些场景有优化、优劣势，比如这个测试报告

比如官方说的8.0在全局锁、pagesize等方面有些有优化，那么就针对性地设置场景来测试这些功能。

比如这是如上链接测试报告中间有数据图表：

image-20230908224210461

最后有结论和分析：

  • the main impact in the given IO-bound OLTP_RW workload is only DBLWR and nothing else !
  • and again, if your workload has more than 32 concurrent users sessions + using a very fast flash storage..
  • so far, impatient to see DBLWR fixed in MySQL 8.0 ;-))
  • using 4K page size is absolutely to consider for any IO-bound workloads !
  • NOTE : every Linux vendor today is claiming that 4K IO writes in Linux are atomic ! – and if this is really true for your platform, then you can safely disable DBLWR if you’re using 4K page and already reach x2 times higher TPS with MySQL 8.0 today in the given IO-bound OLTP_RW or any similar ! ;-)) – the same x2 times higher TPS was also observed on IO-bound TPCC even with an old SSD drive !
  • while if your workload is not IO-bound (having active dataset mostly cached in BP, none or very low IO reads) – then DBLWR is not your main impact ! – you may always tune your MySQL instance to make it mostly “invisible”..
  • Binlog – is the main impact in this case.. Unfortunately it’s another old historical PITA in MySQL Server, and it’s largely a time now to get it fixed (or come with a more advanced alternative).. – “nature is always finding its way”, so let’s see..
  • no comments on MariaDB 10.3 performance.. – but a good live example that just copying InnoDB code from MySQL 5.7 is not enough to get it running right..

之所以有80分是因为超出面试官的期待，给出了一个更高级的结论，面试官肯定很愿意约你过去谈谈

还有没有更高的分

也许有，但是不好说，80分那个就是优秀很好了，挖掘能力强的应届生会搞出来(肯定没有这么细致和周到，但是有几个关键点的结论就够80分了)，再想出彩一点可以根据这个我的星球案例 https://plantegg.github.io/2021/05/14/%E5%8D%81%E5%B9%B4%E5%90%8E%E6%95%B0%E6%8D%AE%E5%BA%93%E8%BF%98%E6%98%AF%E4%B8%8D%E6%95%A2%E6%8B%A5%E6%8A%B1NUMA/ 去搞几台物理机开关NUMA 验证一下，然后给一个对性能影响结果的测试数据报告

或者我博客这篇也行 https://plantegg.github.io/2019/12/16/Intel%20PAUSE%E6%8C%87%E4%BB%A4%E5%8F%98%E5%8C%96%E6%98%AF%E5%A6%82%E4%BD%95%E5%BD%B1%E5%93%8D%E8%87%AA%E6%97%8B%E9%94%81%E4%BB%A5%E5%8F%8AMySQL%E7%9A%84%E6%80%A7%E8%83%BD%E7%9A%84/，找不同Intel机器验证

给出不同的MySQL参数在不同Intel 芯片下性能的差异报告：

image-20221026153750159

这种结论抛出去肯定会让面试官惊到，并对你刮目相看，至少说明你能在某个点上可以钻研很深，到哪里都要的是火车头，而不是普通工程师。

总结

从一个简单的面试题就可以看出应试人员的主观能动性，最起码你要会抄，先去抄别人的测试报告，然后验证一遍然后思考清楚每一个数据的原因(面试大概率会问)

但是大部分工程师都想临时抱佛脚，其实面试官可能会知道你不懂，但是希望看到给你几天你的深度挖掘和学习能力

最后可以从一个问题深挖、总结能力上能看出来候选人的天花板上限，而我们大部分时候都是凑合可以、又不是不能用，逼着自己向前精进一步总是很难的。