昨天渠道推了一波用户，大概用户新增3~4w左右，网站基本上动不了了，分析过他的流量后发现不是流量暴增或者黑客攻击引起的。
登录服务器发现CPU 爆满，mysql 占 %100 ~ %100 上下，登录 mysql 发现查询根本进行不下去，平均一个 sql 运行 2s+。
用 show processlist 查看mysql正在执行的线程。发现大量的sleep和超时的线程，kill掉所有sleep的或者超时的线程。但发现连接数马上又暴增。仔细观察一些超时的连接所执行的 SQL 语句，发现跟它的user表相关的查询超时的情况特别多。 使用check table user发现表并没有损坏。
查看 QPS 和 TPS 发现不是很高，以现在服务器的配置完全可以支撑的
# QPS - Queries Per Second（每秒查询处理量） 同时使用与innoDB和myISAM
use information_schema;
select VARIABLE_VALUE into @num_queries from GLOBAL_STATUS where VARIABLE_NAME ='QUESTIONS';
select VARIABLE_VALUE into @uptime from GLOBAL_STATUS where VARIABLE_NAME ='UPTIME';
select @num_queries/@uptime;
# TPS - Transactions Per Second（每秒传输的事物处理个数） 仅限于innoDB
use information_schema;
select VARIABLE_VALUE into @num_com from GLOBAL_STATUS where VARIABLE_NAME ='COM_COMMIT';
select VARIABLE_VALUE into @num_roll from GLOBAL_STATUS where VARIABLE_NAME ='COM_ROLLBACK';
select VARIABLE_VALUE into @uptime from GLOBAL_STATUS where VARIABLE_NAME ='UPTIME';
select (@num_com+@num_roll)/@uptime
接下来查询 mysql 慢日志 ，发现有一条 SQL 运行特别慢，用 explain 查看这条 SQL 语句的执行计划，因为是组合索引，所以命中率不高，还有全表扫描，接下来修改 SQL 索引类型 ，限制没必要的全表查询，CPU 降下来到 %70 左右。
读写比,优化数据库的重要依据,读的多就去优化读,写的多就去优化写 ,开启查询索引
查看查询缓存情况：
mysql> show variables like ‘%query_cache%’;
（query_cache_type 为 ON 表示已经开启）
+------------------------------+----------+
| Variable_name | Value |
+------------------------------+----------+
| have_query_cache | YES |
| query_cache_limit | 1048576 |
| query_cache_min_res_unit | 4096 |
| query_cache_size | 20971520 |
| query_cache_type | ON |
| query_cache_wlock_invalidate | OFF |
+------------------------------+----------+
如果不是ON，修改配置文件以开启查询缓存：
vi my.cnf
[mysqld]中添加：
query_cache_size = 64M
query_cache_type = ON
然后重启生效
查看缓存使用情况：
mysql> show status like ‘qcache%’;
开启查询缓存后 CPU 总算降下来了~