遇到的慢SQL问题的共性:
- 遇到的这些慢SQL的问题,不仅仅是单方面的,更是该模块的设计者的架构能力和对计算机系统基础知识理解的匮乏,在系统被设计好的同时,系统的性能也就一起被设计好了。性能问题不是恰巧发生的
- 内存管理部分极其糟糕,冗余的内存拷贝,对于内存无限制的索取,对于何时使用buffer及其占用的问题
- 并行执行的设计未能达到目的,有三个慢SQL的最后执行仅使用一个cpu核心,实际成为串行的执行
思考:
- 性能分析工具其实可以做一些更深入的,方便用户分析慢SQL, 现在大部分使用的是per火焰图和explain查询计划做宏观分析,用mysql workbench performance查看mysql本身的统计信息,使用代码埋点日志着色做细节分析。可以入手做一些类似oracle awr的更细节的分析报告
- 细节,细节,还是细节,在理解了大的模块交互之后,关键就在于对细节的理解。任何一行代码都要反思思考。
- 对于一个paper和优化方向,最好的方法是去亲自实现一遍,以owner意识亲自缔造出来,如此方能与其融为一体。只是知道,但做不到,那就是不知道。