最近在做新项目，那么必然涉及到技术选型。其中数据库连接池也是选型的一块内容，一开始我们选了 HikariCP ，用了一段时间后，我们最近也发现了一些问题，这个号称世界上最快的数据库连接池，监控实在是太差了。
接下来我们从功能、性能、监控三个维度，对比一下 Druid 和 HikariCP 的区别。
功能
如下图所示，Druid 的功能完胜 HikariCP，这个跟Druid 和 HikariCP 的设计理念是有很大关系的。
HikariCP的设计理念是尽可能地简单和轻量级，仅提供最基本的连接池功能，以获得最好的性能。
Druid 兼顾性能的同时，则注重提供更多的功能，例如连接池监控、SQL防注入等，以及更多的配置选项。
因此从功能上对比，Druid 完胜。
性能
性能上来说，HikariCP 号称世界上最快的数据库连接池，性能这块是毋庸置疑的。不过 Druid 也不遑多让，毕竟它是经过双十一验证过的。
下图是国外性能测试的结果图，为什么没有 Druid 呢？因为国外基本不用 Druid。从图中可以看出，HikariCP 的性能是远超其他数据库连接池的。
接下来晒一下第二张图：
这张图是 Druid 上一个好事者自己进行的性能测试，可以看出 HikariCP 的性能是要好一些的。不过 Druid 的作者也说，这块是因为 Druid 在实战过程中遇到了一些Bug，其中用了一些同步锁，所以性能会差一些。
所以性能这个环节对比：HikariCP 略胜一筹。
监控
Druid
首先说一下 Druid 的监控，不用多说，直接上图：
这是 Druid 自带的监控控制台，应有尽有，我们用的最多的有 数据源、SQL监控、Session 监控等。
HikariCP
再说一下 HikariCP ，不用说也知道，HikariCP 专注于做一个极致性能的数据库连接池，怎么会把这些杂七杂八的监控加进去呢，加进去性能估计还不如 Druid了。
不过 HikariCP 也提供了一些连接池自身的一些监控指标：
hikaricp_connections：总的连接数
hikaricp_connections_acquire_seconds_count：连接获取次数
hikaricp_connections_acquire_seconds_max：连接获取最大时间
hikaricp_connections_acquire_seconds_sum：连接获取时间求和
hikaricp_connections_active：激活的连接数
hikaricp_connections_creation_seconds_count：连接创建次数
hikaricp_connections_creation_seconds_max：连接创建时间最大值
hikaricp_connections_creation_seconds_sum：连接创建时间最小值
hikaricp_connections_idle：空闲的连接数
hikaricp_connections_max：最大连接数
hikaricp_connections_min：最小连接数
hikaricp_connections_pending：挂起的线程数
hikaricp_connections_timeout_total：连接超时次数
hikaricp_connections_usage_seconds_count：连接使用次数
hikaricp_connections_usage_seconds_max：连接使用时间最大值
hikaricp_connections_usage_seconds_sum：连接使用时间求和
不过这些指标相对于 Druid 就弱多了，如果我们想看下慢 SQL，都无法实现，还需要靠 数据库驱动的配置 + 其他的监控工具实现。
因此在监控这一点上，Druid 完胜。
总结
通过以上对比，我们最终放弃了 HikariCP，使用 Druid。相比于 HikariCP 不多的性能优势，Druid 提供的强大的能力对于生产环境故障排查等更加深得人心，更何况 Druid 是经过双十一验证过的，性能上绝对是没问题的。
而且 Druid 提供了除性能、监控外的其他非常多的功能，我们都可以在使用中收益，所以最终还是选择 Druid。