项目背景是这样的，我们给客户做一个业务系统，部署在客户现场的私有云服务器上，使用的数据库是私有云上的Mysql，由于项目涉及到的系统很多，所以私有云上的资源是有限的，不像公有云上的资源那么充足并且动态扩展。
系统运行初期，用户量不大，系统很稳定，这里的稳定是指响应很快，资源使用率也不高。由于系统被培训和宣讲，系统使用人数突然增加了很多，突然系统就响应很慢，导致新增的用户登录不进去，查看的服务日志发现应用服务器的日志里很多请求都在等待，积累了大量的等待线程。然后排查系统的业务日志发现里面很多获取不到数据库连接的错误，但是通过客户端工具可以连接到数据库上。项目人员通过日志监测发现Mysql的系统指标中CPU跑满到了100%，为了尽快恢复服务，云上先将Mysql的CPU核数扩大一倍，应用服务也重启一下，临时恢复了一段时间。查询Mysql的执行计划日志，发现很多慢SQL。分析了几个SQL发现是由于SQL语句太长而且嵌套了很多子查询。当时傻傻的问了一个问题：为什么系统里的SQL在Oracle上跑没问题，改造成Mysql的SQL在Mysql上跑会出问题？你们不是云吗？资源怎么会跑满？现在想想自己太年轻了。这就涉及到数据库执行引擎性能问题了。听了数据库专家的指点，瞬间醍醐灌顶，虽然还不甚了解，大概意思是：
一、SQL语句执行需要CPU计算和内存资源，当时的环境就是资源不是很充足
二、SQL语句在执行是Mysql需要做解析，语句太复杂解析会慢，导致执行也变慢
三、SQL里的语句包含太多的子查询和关联查询，Mysql优化的时候也会很慢，而且优化要消耗资源，又是一个开销
四、索引问题导致的，这个是查询没建好索引导致执行变慢
五、数据量问题，关联查询数据量多的话执行也会变慢，这块不是重点，因为数据量不大
六、频繁访问Mysql，Mysql的连接处理性能，针对这点后来改成缓存了，尤其是访问量比较多的语句
综上所述，不要太频繁的访问数据库，让SQL语句尽量简单，建好索引，数据量上面让dba保持关注，可以提前建好分表。最后还被活生生的鄙视了一下，不要以为ORACLE上跑的没问题的语句，改一下MYSQL版本满足需求但是不做SQL优化就没问题，不要问问什么，总之是自己写的语句的问题。
