一直比较困惑我的问题,因为后台表格通常包含的信息比较多,有很多关联信息,比如一个评论,可能关联:文章,用户,回复的用户等等。
后台表格一般会有非常多的筛选项,比如:搜索文章,搜索用户,搜索用户类型,搜索回复用户,筛选回复量等。并且排序也有可能是多个的,比如:按发布时间排序,热度值排序,回复数量排序。
对于前台的接口可以通过特定的索引优化,但是后台场景太复杂了,一般的处理方式或者优化方式是什么?
一直比较困惑我的问题,因为后台表格通常包含的信息比较多,有很多关联信息,比如一个评论,可能关联:文章,用户,回复的用户等等。
后台表格一般会有非常多的筛选项,比如:搜索文章,搜索用户,搜索用户类型,搜索回复用户,筛选回复量等。并且排序也有可能是多个的,比如:按发布时间排序,热度值排序,回复数量排序。
对于前台的接口可以通过特定的索引优化,但是后台场景太复杂了,一般的处理方式或者优化方式是什么?
2 回答4.2k 阅读✓ 已解决
4 回答4.2k 阅读
2 回答1.7k 阅读✓ 已解决
4 回答2.5k 阅读✓ 已解决
7 回答1.8k 阅读
1 回答4.1k 阅读✓ 已解决
2 回答2.1k 阅读✓ 已解决
即然名为优化,那就一定要跟着需求走。
数据库优化基本上还是走索引。索引就将就命中率。整一堆索引,用不上,浪费空间和计算资源。后台数据很多,关联的行为也很多,但并不是所有数据都是常用的,偶尔一次不走索引,只要数据量不太大,用户不太急,多跑一会儿也没关系。
我的经验是先把明显需要用到的字段添加索引,然后根据业务方的需求和 slow sql 进行调整。一段时间后就跑顺了。