主要遇到的有5种情况：

1、由于合并操作导致sql执行失败的问题

这个问题在一个写入频繁系统中比较常见，之前也讲过怎么导致合并的。

在oceanbase合并期间，需要把内存中的数据落入到磁盘中，为了保证数据的一致性，会将正在执行的sql kill掉，但是sql并不是立刻kill，会保留100ms的时间给这个sql去执行，如果说执行不完成，就会被kill，哪怕是101ms。这时候就会导致sql执行失败。

2、由于sql执行时间超时，导致sql执行失败。

这个问题在所有的数据库中都会有，因为不可能放由一个sql无限时间去执行，ob数据库默认执行超时时间为10s，超过时间就会被系统kill。

3、事务执行超时，导致sql执行失败。

在应用中，一个事务可能由一个或者多个sql组成，有时候会发现，单条sql执行时间并没有超过10s，但是被系统kill了，为什么？

因为ob不单在单条sql上做了限制，而且会在整个事务的时间上做限制，默认事务超时时间为100s，如果这个事务有n个sql组成，这n-1个sql执行的时间加起来如果超过了100s，或者接近100s，那么最后一个sql可能刚开始执行就被kill，也可能执行的机会都没有，就将整个事务kill了。

4、由于memstore打满，导致sql执行失败。

这个原因也是由于合并操作导致的，在合并过程中，后续的写入操作会被记录到memstore里面，如果memstore在合并过程中写满，但是合并操作还没有完成，那么这个时候sql就会写入不进来，报错memstore已用满。

5、合并期间，location cache没有及时更新导致sql执行失败。

如果一个sql涉及多server执行，ob数据库的合并方式是轮训合并，每台server一次合并。那么再合并期间，或者合并完成后的一会，会导致sql执行失败，原因就是因为location cache没有更新到最新的，为了保证数据的一致性，ob会将这个sql杀死。

这是最近遇到的关于ob系统会将sql kill的几个常见的情况~，如果以后还遇到会及时补充。