背景：有一套应用，数据库是Mysql 5.7.31，
在一次优化配置上线中，Druid配置开启PS Cache，配置如下：
<property name="poolPreparedStatements" value="true" />
<property name="maxOpenPreparedStatements" value="20" />
问题：开启之后，会有性能问题，现象就是库有行锁，information_schema.processlist里头看到很多sql执行耗时过长，但并不是有死锁，就是事务执行周期长；
本身sql是没问题的，走索引，执行计划都OK，而且库记录的slow query是没有的。
解决办法：应用端Druid配置关闭PS Cache，去掉这两行配置，重启应用，就恢复正常了。
经过请教和搜索资料得知：PS Cache只针对存储过程有效，能提升性能，mysql基本不考虑开启；oracle的话，如果有存储过程可以开启，如内存允许就可以把maxOpenPreparedStatements设置大一点，不如到100。
疑问：为啥会造成这种性能上的影响呢，按说最多就是性能没有提升嘛，请各位网友大佬帮忙解解惑。
缓存本质上是空间换取时间。当占用大量空间但缓存命中率低且命中若没有收益，那么就不推荐使用缓存了。
mysql的PS Cache是Connection级别的，当相同的sql被不同的Connection执行时，也不会共享彼此的Connection连接（会在新的Connection重新维护一份）。而执行sql从连接池中获取连接都是无规则的，（同一个会话中开启事务管理器除外），也就是同样的SQL在不同的连接中被使用是十分正常的事情。
即使每个元素在PS Cache占用的内存不多，但因为是Connection级别，当存在大量分库分表的场景下，会产生大量的Connection连接。累积下就会占用大量的内存。
你通过druid监控看一下命中率，如果命中率很低，那就别开启了，没有意义
评论
有用 1
给自己备注个！！
2.3 mysql以及大量分库分表不推荐使用PS Cache
缓存本质上是空间换取时间。当占用大量空间但缓存命中率低且命中若没有收益，那么就不推荐使用缓存了。
mysql的PS Cache是Connection级别的，当相同的sql被不同的Connection执行时，也不会共享彼此的Connection连接(会在新的Connection重新维护一份)。而执行sql从连接池中获取连接都是无规则的，(同一个会话中开启事务管理器除外)，也就是同样的SQL在不同的连接中被使用是十分正常的事情。
即使每个元素在PS Cache占用的内存不多，但因为是Connection级别，当存在大量分库分表的场景下，会产生大量的Connection连接。累积下就会占用大量的内存。
max-pool-prepared-statement-per-connection-size设置的过小，会导致命中率很低，基本没有什么作用。但设置的过大(例如200)会占用大量内存。而且即使命中中了，因为mysql不支持游标，效果不是很好。
综上所述：mysql的druid连接池没必要开启ps cache。
2.4 其他数据库是否开启PS Cache
此处讲述的主要是MySQL及其JDBC的PS Cache的部分问题，在实际的场景中可以作为参考避免一些不必要的问题发生(也未必会遇得到)，这些糟点在其他数据库上未必是适用的，例如Oracle在SQL Parser有：Hard Parser和Soft Parser，Soft Parser的就是语法树结果，它存放在Oracle一个单独的共享区域中，并非Session级别，所以不同的Connection之间可以共享同样的SQL语句，Oracle针对所有的SQL语句都会使用LRU算法进行Cache，单从本文提到的PS Cache来讲在Oracle上体现的效果会更好一些。
原文链接：https://blog.csdn.net/weixin_33420201/article/details/113262882
评论 有用 0
墨值悬赏