奇怪，同样是函数导致MySQLCPU100%，为什么之前的系统挂了，这次连个报错都没有？

先讲结论：之前的MySQL函数执行耗时太多，执行一次平均6.3min，最长30min。然后引发重启，具体后面会展开讲。

上次是怎么挂的？

因为下面这个慢SQL,平时耗时6.3min，最慢有执行30min的。

select * from contact where MD5(mobile)=?

图片

图片

一个慢SQL为什么会挂？

SQL只有一个，但同时在MySQL上可以多个。譬如并必请求。

譬如上面这个SQL开始执行后的6.3min内，都与它是并发的，即同时在MySQL上执行。

服务持续不可用的具体过程是这样的：

MySql CPU利用率100%,会影响执行Sql的TPS/QPS，请求会越来越慢。 在流量不变的情况下，tomcat中的线程会用完，当K8s健康检查的http请求连续多次超时报错，K8s就会重启服务。【一个服务不可用了】 服务启动期间是不可用的，剩余的服务会收到更多请求，在MySQL处理能力不变的情况下，剩余的服务上的tomcat连接池只会更快被消耗掉，然后同样重启。【其它服务不可用了】 服务先是被重启，启动后因为MySQL慢导致tomcat连接池被快速消耗掉，然后服务再重启，相互踩踏，恶性循环。 服务一直不可用。 JackieTang，公众号：生活点亮技术千丈之堤，以蝼蚁之穴溃：一个慢SQL引发的雪崩

想进一步了解K8S健康检查？见文末

这次为什么没事？

这次的慢SQL，最慢的只有1.8s。

啥事没有，日志中一个数据库的报错都没有。

虽然MySQL CPU利用率持续高，但在MySQL的处理范围内。毕竟这些慢sql耗时平均只有1.08s,即使执行了2444次。

如果这次也是MD5函数呢？

稳如老狗。

相同的数据量，110万；

同类SQL, where md5(file_name)=?

在现在的库上执行最慢是8.935s。8.935s！！！！

耗时降了225倍。有钱真好

有钱真好。目前库是4C32G。

之前的库是2C16G的。这中间阿里云PollarDB这个SAAS估计也在不断迭代，能力也更强。

小结

系统稳定性很重要。

一方面要对请求做流控。

一方面要优化代码中的性能瓶颈。

一方面要配置SAAS的弹性伸缩。

一方面要配置告警。

什么是K8S的健康检查？

livenessProbe: # 存活探测的相关配置如下 httpGet: path: /ready port: http initialDelaySeconds: 180 periodSeconds: 10 # 每隔10s探测一次 timeoutSeconds: 1 # 如果/ready接口1s内没有返回，则判断失败 successThreshold: 1 failureThreshold: 3 # 连续失败3次，则判断pod异常。容器重启pod 唐成，公众号：生活点亮技术FullGC没及时处理，差点造成P0事故

图片