这个话题似乎有点不大靠谱，去优化一个不太懂的数据库，是不是有点忽悠。事实上，我第一次帮用户优化ORACLE数据库，也是面临这样的窘境。当时对Oracle数据库，也只懂了点启动关闭，sqlplus连接跑几条SQL这样的简单操作。不过当时不知道怎么回事就答应了，可能是对方开的价格令人心动吧。我那时候比别人强的地方是openVMS系统比较熟悉，于是先在操作系统层面检查了一下。没想到从操作系统上就看出了PAGEFILE使用率接近100%，系统换页很严重。于是很快就发现SGA配得太大，导致了数据库一启动系统就开始换页了。最后把BUFFER_CACHE减小了一半，问题就解决了，这是我做数据库服务的第一笔收入。
目前我们面临的情况和三十年前面临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也没问题。
