1 首先，一个很基础，但是发现还是有人忽略，导致问题也比较严重的问题。就是服务日志不能存到跟业务数据库里面，就算是分库也会受影响，最好就是完全隔离。存到独立的组件里面，业界比较流行就是ELK了，各种云服务也是在ELK上面改进而来。如果不这样做，首先日志存储到业务数据库里面，相当于变相人为给数据库加重几倍业务压力。通常一个业务请求有N条日志，也就是数据库承载了业务乘以N的压力。 第二，数据量大，也意味着空间大，浪费业务宝贵的存储空间，日志不需要太及时，也不需要长期存储，但是短期又要大量存储。第三，查询日志困难，统计类查询慢，日志里面有很多json格式数据查看比较难看出结果，查询慢卡顿，影响业务。
2. 慢查询，这种一般是比较容易发现的问题，通常添加索引即可。需要注意，多个条件查询要建立组合索引，因为尽管你每个字段单独建立索引，命中索引只会命中一个索引，其他条件查询里面特别是有排序的话，会产生filesort 这种耗时操作，如果索引有中包含了排序的字段，天然结果就是有序的。
3. 慢查询排除完了，但是CPU很高，甚至到90%。如果是业务增长了，快速的解决方法是升级硬件，云服务可以做到无缝升级配置而不影响业务，其他云服务有一个数据迁移的过程。
4. 快速升级完硬件，如果发现并发 show proceslist ，QPS不高，也没有慢查询，那当时cpu这么高，而且大部分都是select 查询，那么初步可以判断是select里面是扫描比较多的行数据，这个一般可以通过云服务的全量统计功能可以发现mysql的执行状况，主要看聚类sql模板，看哪一种占总耗时比较多，扫描行数比较多，平均耗时比较多。大部分的简单select 操作都是0.1毫秒级别的。通常就是一些join 连表查询里面，对应连接字段没有建立索引。因为mysql有执行计划，在本地数据量比较少的情况下，有可能只命中比较简单的索引，但是在数据量大的真实环境，如果你建立了组合索引，还是可以命中。目前的组合索引是 查询条件的字段在前，后面带上连表的字段，还有查询的字段。优化后，cpu也从40%降到了2%-3%. mysql.innodb_rows_read person second行读数，InnoDB缓存请求次数(mysql.innodb_buffer_pool_reads_requests)也跟着cpu 大幅度减少， 但是QPS，TPS保持不变。
5. 题外话, 有些人看到数据库慢，就加缓存，但是缓存使用场景，是被并发访问的数据才应该存在缓存里面，而且还注意是失效机制，以保证数据的一致性。并不能解决新来的请求慢的问题，主要是不能命中。如果把所有数据都存在缓存，是可以命中，但是命中率太低，而且后续要从数据库同步到缓存的工作比较大，人为增大了数据库的读操作，和缓存的写操作，同步慢，同步逻辑复杂，因为数据多了，各自数据对应关系也变得复杂，就意味着变化因素过多，缓存常处于一种失效状态，在不停更新状态，但是访问该缓存数据的频率又比较少，变相使得该缓存资源主要都是消耗在内部更新数据。