记一次pgsql数据库cpu较高的事故

接了一个小需求，是将一些用户操作记录入到我们的数据库中。观察到入库的接口平均响应时间比较差大概在几秒左右，当时没多想，就觉得是先查询是否存在，再插入这个过程中查询是否存在比较耗时（因为操作记录表比较大），但是后面发现有10%，20%的入库接口响应时间甚至达到了十秒，并且pgsql数据库cpu变高了很多，波段性的高峰存在。老样子，先查询是否存在慢sql，耗时3秒以上的sql查询load出来后发现原来是查询是否存在的这个过程出了问题。我是通过一个联合索引来查询是否存在的，他们分别是(公司id，店铺id，xxid)，通过explain该sql语句发现并没有走这个联合索引，而是走了(公司id，店铺id)这个索引。而这个索引扫出来的结果并没有区分度，因为一个公司的某一个店铺可以有很多的操作记录。让我们来思考一下联合索引的定义，它满足最左前缀匹配原则，mysql的查询优化器会自动将你代码中乱序的查询条件组装成联合索引去查询，进而通过联合索引来计算查询成本。但是最左前缀匹配原则是要求越有区分度的字段应该放在左边，我误以为sql的查询优化会自动帮我把联合索引的区分度字段往左边移动。这次事故的原因主要是因为我对最左前缀匹配原则理解的不深刻，下次应该尽可能的将具有区分度的字段放在联合索引的左边。