以下只是我针对数据库查询慢这个问题想到的可能的原因和一些解决办法的简单罗列,每一个问题和解决办法都可以详细描述很多,后面的再针对每一个点进行谈论
一、应用的问题
- 数据库表设计不合理,应该加索引的字段没有加索引
- 查询sql语句是不是编写不合理,查询的时候没有加索引
- 查询sql语句的条件加了索引,但是查询的时候没有命中索引,比如:前缀匹配失效、条件字段做了类型转换或者使用了函数、使用了范围查询等;使用 explain 查看索引命中情况 ;参考
- join的表太多了???
- 数据库中的单表的数据量达到了多少?1000万?5000万?是不是考虑分库分表;参考
- 分库分表怎么选取分片键?
- 分库分表后怎么查询?
- 分库分表的算法?一致性hash环?
- 分库分表的节点个数怎么考虑
- 程序异常导致大量数据库连接不能释放,一直被占用?
二、数据库的问题
- 参数优化,连接池资源不够用了
- 数据库所在的硬件资源情况:当查询慢的时候,内存占了多少?mysql磁盘IO是不是被其它应用共享且占用高?cpu是不是有负载?
- 硬件资源本身不够>加资源
- 硬件资源因为和其它进程共享,导致资源不够,可以考虑做资源隔离
- 硬件资源性能不足,比如磁盘可以考虑换成SSD
- 网络资源
- 应用连接数据库的网络是不是抖动,延时较高
三、请求量太大
- 如果数据量真的炒鸡大,分库分表已经不能满足查询了,考虑将热点数据在redis做缓存
- 应用架构调整,把缓存模块加进去
- 如果已经加了缓存还是慢,会不会是缓存雪崩了?击穿了?缓存命中率低?
- 缓存任然不能满足查询要求,比如很多字段的查询,可以将查询字段放到ES等大数据组件中,先查ES,ES拿到数据主键id再到MySQL中查询
- 用户请求突然增加,导致查询变慢
- 上有系统出现bug,导致循环调用接口做查询,这个时候是不是考虑异常情况限流
- 用户请求真的是大量增加了,公司发展迅猛