起因

近期公司打算把之前项目中的c3p0数据库连接池更换为druid，在给出替换方案前，需要先给出测试数据证明druid性能优于c3p0，于是便写了个demo进行对比测试。
一开始先要确定配置的没有问题，起码先要可以操作数据，就运行了一下测试方法。由于运行的时候其他事耽误了一下，就跑了10min，然后插入了86万条数据到sybase数据库中。
在正式测试之前我打算把表中原有数据清空，然后便遇到了数据库卡死的情况，使用delete、drop均是如此。
在解决这个卡死的问题时，又发现了原本思路上的问题，总结大致如下。

问题分析

要进行两个连接池组件的对比测试，就需要保证数据库的前提条件是一样的，起码要相似，我一开始想的就是清空数据，清空数据的操作是delete，但是这个思路存在两个问题

问题一

delete操作删除数据并不会清除之前占用的空间，如果真的这样做了，那么测试的前提条件实际上是不一样的。

解决办法

因此，在我这次测试的场景中，清空数据的操作应该使用truncate，这个操作不仅会清空数据，还会清空这些数据占用的空间以及相应索引占用的空间。
只有这样才能更好的保证连接池组件测试前，数据库条件更接近，使外部环境的影响降低到更小。

问题二

但是，即便清空了数据表的数据，也清空了数据表的空间和索引占用的空间，还是存在着一个问题，那就是数据库日志的问题。
sybase在进行insert操作的时候会写日志，那么如果日志一直在增加，势必降低日志写入的性能，也就整体上降低了数据入库操作的性能，所以还应该每一次测试前都在清空数据的同时，也清空日志。
那么日志的问题，也是导致一开始所说删除86万数据使sybase卡死的主要原因了。
sybase在delete操作时，也会写日志，而这个日志的大小是有默认值的，并且不会自动释放。
由于我之前对数据库进行了很多操作，长达几个月的操作都没有清过日志，所以导致这一次insert八十多万数据后日志空间不足，然后再delete时sybase卡死。

解决办法

对于日志空间不足的问题，有两种解决办法，一是扩容，二是清日志，我这次选择的就是第二种，因此也只记录一下第二种。
首先，需要确定是否真的是日志空间不足，查询的命令如下：

sp_spaceused syslogs

如果确定了确实是日志空间不足了，那么就可以再使用如下命令清除历史日志：

dump transaction dbname with truncate_only

清除日志的操作并不唯一，上述清日志的命令是比较安全的，会进行一些事物检查，因此性能就不如下边这条操作，而下边这条性能会变快，但是相对而言就没有那么安全，相当于是强制删除。

dump transaction dbname with no_log