早上一来公司，质量部小伙伴们就说，后台系统“订单管理模块”无法加载出数据了，不是网络问题不是网络问题！

好吧，DBA今日又请假，不能影响大家的测试，赶快排查下原因：

1、 查看下日志吧：

    进入k8s服务器，既然是订单模块加载数据出问题，那就找到对应的 订单微服务 ：order 服务

   ①、 k8s查看 找到我们的order微服务：kubectl get pods -o wide

   ②  、 查看order服务日志：   kubectl logs -f --tail 500  deploy-lovego-order-59857cc4-spz6q

        找到日志信息了，查看到日志抛出异常： xxxxxx    mysql    disk  full xxxxxxxxxxxx

     明显mysql磁盘没空间了，那就进入myslq服务器查看下空间使用情况

2、清理mysql空间：

    进入mysql服务器，我们环境mysql架构为：一主三从

    根据使用的场景，这个业务为获取订单数据，那么针对我们的mysql主从读写分离，应该是从3台从读写数据。分别查看           mysql各服务器的空间，果然，三台从库磁盘空间使用100%。 清理掉没用的数据文件。

3、确定清理的mysql磁盘空间数据--注意别乱清理：

   ①、 find 查找要清除哪些大文件，发现基本的大文件都是从库同步复制的“relay-bin”日志信息，每个400M左右，且数据文件较多达到100多个，磁盘空间基本都被这些信息占满，  数据可不能乱清除的，清除错误，将导致，从库数据无法正常同步主库数据（具体可了解mysql主从复制原理就清楚）

    ②、确定要清除的“relay-bin”相关数据。先show slave status\G 查看下我们的从库同步复制信息到哪个位置了！！

    从下图中可以看出，从库读取中继日志文件到了relay-bin.000031（之后的文件不准清理，否则从库数据和主库不同步）。 

    那我们可以确定，清除relay-bin.000031以前的所有 relay-bin 日志信息。

   同样，另外两台从库服务器也按照此方法进行清除。

    ps：此处应有自动清除脚本，自动清除已复制完成的日志文件~~

4、后台管理系统已能正常访问--但还需进一步排查优化。

     虽然经过以上清除操作后，后台“订单管理模块”已能访问了。但是订单首页默认加载的分页10条数据得20s以上才能显示出来，，慌得一匹的感觉。。。得尽快解决。

 ①、查看开发童鞋写的该模块代码，逻辑并不复杂，主要去mysql获取对应满足条件的数据处理展示。但是此处获取数据的sql一看就感觉性能肯定很低，如果数据少无所谓，，要是数据量多了，性能是个隐患。

②、监控mysql慢查询日志，发现一sql响应时间达到20s以上，正是该逻辑代码处理的sql。

③、对应sql 拉出来，测试响应时间达到28s以上

④、优化：查看到，使用不合理的group by，去掉对结果不产生影响。响应时间直接又28s下降到1s：

到此，排查优化后，数据能正常加载了，响应时间也从20多秒下降到1s左右了。

小伙伴们可正常工作了~~~

其实，这个sql效率还可以继续优化，explain查看执行计划，sql走order_sku进行全表扫描数据，可以在order_sku表加上合理的条件，但是要从业务层面去考虑具体场景了~~~

好久没写博客了，变得有点懒惰了~~

写博客是一种很好提升方式，一是对问题的一个总结，二是加强我们思考问题总结问题的能力，能帮助别人，也能提高自己。

不管啥问题，思路最重要~