前言
非常抱歉，这是一个非常非常严重的生产事故，写下来的主要目的是让自己铭记于心，防止下次发生。（PS：可能也还会发生）
具体过程
事故原因是这样的，偶然一个寂静无声的夜晚，大概十点半的时候，突然，现场反馈没有办法使用了，我丢，啥情况呀。 各种查询都很慢， 提交几十K数据也要十来秒的时间。 当时，误以为是点位不够导致的数据查询慢，压根也没有想到去优化代码，然后扯个谎，让现场多加点空闲点位。 然后，偷偷摸摸的重启了数据库服务，让其恢复正常。 整个过程一丝不苟非常完美。 客户夸夸点赞。
当时没有放在心上，第二天晚上又出现相同的问题，而且也是相同的个时间段。
当时分析：
（1）上线了由于之前都是在客户现场做开发，很多没有加索引，现在运行起来数据量大了，就导致了大量慢查询。
（2） 由于在现场开发，开发测试都是都一个人，很多东西逻辑混乱， 很多必要的引用。
（3） 数据库和程序是部署在同一台服务器上的，数据库没有设置最大的内存限制，数据库会一直执行并将查询的数据保存在内存中。
优化：
（1） 再忙都要进行压力测试。
（2） 避免忘记加索引， 建议在每张表的高频查询上都加上索引，不论数据量是多还是少等等。
（3） 前端高频操作，需要做节流限制，避免短时间多次点击，造成后台资源浪费
（4）代码层面上循环里一定！一定！一定！不要做数据库查询，除非不得已情况
（5） 高频次数据一次性查询添加到缓存中，设置过期阈值。
（6）减少不必要的引用，不需要的统统删除。
（7） 设置数据库最大内存限制，根据平时时间正常运行的值去设置。
（8） 升级服务器 （后面做了双机热备，内存比之前整整多了一倍）
最后
感谢客户领导以及同事的帮助与支持，不然我也没有那么好的一次人生经验！