面对一个不太认识的数据库优化方法

现在我们面对的情况和三十年前面对Oracle数据库差不多，许多用户在使用国产数据库，遇到题目之后两眼一抹黑，也找不到高手来帮助办理。假如有客户盼望你帮助查查数据库的题目，有志于从事国产数据库服务的朋侪万万不要错过如许的时机，真的可以去实行一下。
那么题目来了，对某个数据库不太认识，能去做数据库优化和题目排查吗?实在答案不肯定就是否定的，由于数据库与应用体系固然大不类似，但是其原理性的东西照旧通用的，高出一半的题目可以通过一些通用的方法排查出来，因此只要你的根本功比力踏实，乐成的概率是高出50%的。本日我来分享一些通用的排查方法，可以用于数据库体系和数据库应用的题目排查。
起首是排查数据库和利用体系日志，当用户说体系有题目的时间，有大概数据库日志里可以大概看到一些非常，好比数据库遇到BUG，遇到一些严肃的IO题目大概锁辩论，有慢SQL等，大概在日志里就有所表现。假如利用体系存在一些BUG大概一些硬件题目，那么在OS日志里也可以看到许多有代价的信息。好比换页的信息、IO链路切换、读写非常等。不管你对某个数据库相识的程度怎样，哪怕是高手，排查数据库题目的时间，起首必须要看的也是日志。
假如在日志中看不出什么题目，那么下一步你可以看看利用体系的资源是否存在瓶颈，假如利用体系的CPU/IO/内存/网络存在题目，那么数据库体系的题目很大概是这些引发的。在这个排查里我们重点要看以下几个方面。
第一个方面是CPU使用率和R队列。假如CPU使用率很高，高出90%，那么假如r队列长期高出服务器CPU线程数的2倍，那么通常瓶颈出在CPU资源上了。假如USER CPU占据了大部分。那么下一步数据库层面的TOP SQL就是排查关键了。假如SYS占据了大部分，那么自旋锁SPINLOCK、SWAP等是排查的关键。SWAP很容易查抄，这是利用体系层面的变乱。SPINLOCK贫苦一些，一样寻常来说和数据库并发方面的题目有关，也有大概是数据库的某些和自旋锁干系的参数设置不公道大概数据库的BUG引发。这时间用perf大概pstack如许的工具来分析体系调用是找到题目的常用方法。
分析IO的方法也很简朴，起首分析IO延时是否需公道，对于数据库的硬件，假如是平常盘，那么IO延时是否高出了10毫秒，假如是SSD盘，IO延时高出2毫秒都是有题目的。其次要看IOPS和吞吐量，假如IOPS不高，IO延时很大，那么是OS出题目了照旧自己存储体系存在题目，就必要进一步排查了。假如IOPS和吞吐量也很高，那么大概率是SQL出题目了。
假如OS层面没有发现显着题目，那么下一步吧就必要去排查数据库了。排查数据库可以先从锁和会话查起，假如数据库有期待事故，可以分析一下紧张期待事故，从期待事故的名称上去找灵感。不外不幸的是，国产数据库的期待事故通常不敷靠谱，很大概劳绩不大。不外会话、活泼会话、锁、长事件等的排查是须要的。荣幸的是大多数国产数据库查这些题目也不算太困难。找得手册就很容易写出排查SQL了。
假如确实是活泼会话太多，那么我们应该通过会话视图找出这些会话属于哪个应用，哪个主机，哪个用户的，从而更加准确地找到题目点。假如发现了，可以让开发商大概应用运维职员先去排查应用。
TOP SQL的查抄可以先从并发实行的SQL查起，一样寻常国产数据库的会话视图都有SQLTEXT，根据SQLTEXT的前几十个字节做统计，看看是否有某些类似的SQL的并发实行量很大，假如存在如许的SQL，那么下一步重点排查的方向就有了。
许多国产数据库都有一个SQL审计视图，这个视图一样寻常是一个内存地域，存储了迩来实行的1000条大概几千条SQL语句，这个视图不是按照Oracle V$SQL如许做过署名归并的，而是每实行一次就会有一条记载，通过这个接口也可以很好地分析当前SQL的实行情况。找到大概存在题目的SQL去办理题目就可以了。假如临时无法优化SQL，杀掉一批会话大概就能临时办理题目了。
是不是不太难?只要你是故意人，哪怕面对一个你不认识的数据库，上面的排查工作你也是可以比力顺遂地完成的。事先准备好一些排查SQL语句就可以了。乃至在现场，假如你的生理素质够好，根据官方手册，临时去写几条排查SQL也没题目。

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！qidao123.com:ToB企服之家，中国第一个企服评测及软件市场,开放入驻,技术点评得现金