前言
等待事件是排查数据库性能的指标之一。简单理解，cpu在处理业务时由于业务逻辑，和不可避免的数据库其他原因造成的前台进程等待，这里的等待事件包含buffer类，io类，以及网络类等等，当我们遇到等待事件，这往往说明数据库性能存在问题，当然也要通过KWR报告去分析，等待事件占用DBtime的时间占比。这样能大概得出数据库整体运行状况。我们希望cpu在处理sql花费时间都用在数据库时间上，而当cpu花费了一部分时间在等待事件上，这样就对sql处理效率大打折扣。
记住这个公式：cpu time+前台进程非空闲等待=DB time。
elapsed time(自然逝去时间，也就是快照间隔)*逻辑cpu核数>db time ，如果elapsed time远远大于db time 说明数据库性能良好。反之，需要注意了，数据库负载过大。
也就是说cpu花费在数据库上的时间= DB time/(elapsed time逻辑cpu核数 )100%。这不包括后台进程花费的时间。这样判断数据库整体负载。
等待事件含义
buffer_content
lwlock:buffer_content当一个会话正在等待读取或写入内存中的数据页而另一个会话锁定该页以进行写入时，会发生该事件。
发生场景：300并发单条insert 。
实际上这是一个轻量级的内存锁，他保证了内存中数据的完整性，我理解，可能类似于oracle中的buffer pin锁。
为了读取或操作数据，数据库通过共享内存缓冲区访问它。要从缓冲区读取，进程在共享模式下获取缓冲区内容上的轻量级锁 (LWLock)。要写入缓冲区，它会在独占模式下获得该锁。共享锁允许其他进程同时获取该内容的共享锁。排他锁可防止其他进程获得任何类型的锁。
( lwlock:buffer_content)BufferContent事件表明多个进程正在尝试获取特定缓冲区内容的锁。
分析等待事件增加的原因
1.增加对相同数据的并发更新
更新 the same buffer content内容的查询的并发会话数可能会增加。这种争用在具有大量索引的表上更为明显。
2.工作负载数据不在内存中
当活动工作负载正在处理的数据不在内存中时，这些等待事件可能会增加。这种效果是因为持有锁的进程在执行磁盘 I/O 操作时可能保持锁持续更长时间。
3.过度使用外键约束
外键约束会增加进程持有缓冲区内容锁的时间。这种影响是因为读取操作在更新外键时，在外键上需要获取一个 shared buffer content lock 。
解决
1.提高内存效率
为了增加活动业务数据在内存中的可能性，比如根据服务器可用内存增加shared_buffer大小。表太大则进行分区表规划。
2.减少外键约束的使用
对于大量lwlock:buffer_content( BufferContent) 等待事件以使用外键约束的工作负载。删除不必要的外键约束。
3.删除未使用的索引
对于大量lwlock:buffer_content( BufferContent) 等待事件的工作负载，未使用的索引并将其删除。而且索引也是需要维护，占用磁盘空间。