数据库性能有问题 怎么解决

最近由于数据库性能问题，统计了一下慢查询，发现了一些问题，总结一下

1、由于业务的频繁修改有些表未创建索引
   最容易修复的，根据SQL检查慢查询的表，是否创建索引，重新创建索引即可
2、部分SQL查询方式有问题
   这个部分相对麻烦一点，有可能需要修改代码调整实现方式 
3、业务逻辑实现问题，未命中缓存频繁的查询数据库导至
   有的API本身是有缓存的，但是由于缓存机制实现有问题，需要修改缓存机制，相对容易修改，数据库查询失败时缓存一个空对像，让下次缓存能够命中即可

问题SQL举例

select * t_user where phone  like ?

根据电话查询用户，支持模糊查询，但是由于用过多，搜索特别慢，这个时候就需要做一个特殊处理，比如输入的手机号是一个正常手机号就应该需要"="对搜索

问题SQL举例
        select count(*) t_activity_user where activity_id  in (select id from t_activity where type = 1)

某一类型的活动参与用户人数。收到这样一个产品需求一上来就想用最简单的方法去实现，数据库正常的时候，很快就查出来了，由于雪崩所有sql都会变慢，但这种sql就极其的慢。优化的方法就是改一下统计策略；
使用的修改方法：
1. 可以在活动表中增加一个字段，user_count, 每次新增的时候user_count+1 ，type有索引的话统计也是很快，这种方法就是提前打点统计，代码修改也相对少

2. 使用其它方式打点,统计类SQL最好是使用一个统计表 提前打点，这个统计速度快 查询简单

分页列表

通常分页加载都是有两个方法
select count(*) from t_able
select * from t_table limit 1,20
    但这种方法读取起来应该是极慢的，这种应该改成游标的方式去读取，不给总页数
    第一页
    select * from t_table order by id desc limit 1,20
    第二页,每次把上一页最小的ID当作参数传递

    select * from t_table where id <pre_last_id order by id desc limit 1,20