排查 cpu 飙升到500%

当执行SQL 默认10s设置的时间，就被认为是慢查询

慢查询->explain->index 慢查询日志show variables like '%slow_query_log_file%';

SQL 性能优化 explain 中的 type：至少要达到 range 范围级别，要求是 ref 普通的索引级别，

当 type=index 时，索引物理文件全扫，速度非常慢。

考虑接口返回值 前端送参数为空 或者格式不正确 类型不正确等送参数容错机制

cpu 飙升到500%

1是不是mysqld 占用导致的

2showprocesslist，看看里面跑的 session连接 情况

加索引、改 sql、改内存参数/说限制连接数等

优化

恰当使用缓存reids

一主多从集群部署

服务器优化（增加 CPU、内存、网络、更换高性能磁盘）

路由策略

负载均衡策略 nginx 代理服务器 所有请求根据路 径匹配路由到对应的网关系统上

定期淘汰历史日志

JVM 是否调优

海量数据模糊搜索的数据导入 ES

服务降级策略

特殊业务场景中添加图片验证码，比如登录请求、注册请求、下单请求中答题通过才能继续请求

增加基础服务部署节点，应用做成集群部署

多线程

接口性能优化 数据量比较大，批量操作数据入库

耗时操作考虑异步处理

保证接口的稳定性， 代码的健壮性方面

服务保护的层面（限流降级）

全局异常处理

优化

分页 防止sql注入 #{}"， 预编译处理对象，被解析为"?

inner join 、left join、right join，优先使用inner join

尽量避免使用 select *，返回无用的字段会降低查询效率

尽量避免使用 in 和 not in 用 between 代替

对于索引字段 or 或者 in 的效率基本一致，非索引字段 in 的效率优于 or

控制字段长度

添加必要的索引，避免 SQL 命中不到索引的情况

先过滤 where，后分组grounp by

避免在where子句中使用 or 来连接条件

使用union联合查询

静态化技术，把文章的详情生成静态页面，降低数据库和服务器的压力

垂直分库、水平分表