因为后端慢大概率是被“数据库”拖累 所以性价比来讲 优化数据库比较明智
提升数据库速度有两个思路方向
减少query次数
数据库index效率提升
BTW “最新 5 笔资料”这个如何用数据库实现？思路是 “全员排序 取最前五名”用的代码是 limit原来limit是这个用法啊！
原来 ActiveRecord是用来“语言转换”用的啊？ 全靠它提高开发速度啊啊啊
不过它让撸代码简单了，却导致数据库查询速度下降啊啊啊
N + 1 query问题就是它带来的？！！
本地开发时，这个问题不明显，因为本地啊，网站打开以及数据库是一个机子。一旦变成正式开发环境，“数据库服务器”跟“Web server”不是同一部机子就慢到死
原来index也分门别类
居然面对不同数据类型 index的效率是不同的...好奇背后的原理
看这张说明 数据库排序速度 的图
我觉得应该是因为“字段”里的“数据类型”占内存空间的大小导致速度不同的，比如，用“DateTime”进行索引搜索比用“id”进行索引搜索慢很多，因为前者数据类别是“DateTime”后者数据类别是“integer”啊啊啊啊
BTW 图里直观看到 DateTime 跟 Date数据类别的具体细节不同
Counter Cache
这个方法听上去好像很高级很高深的样子 认真看了内容后感觉...
不就是因为SQL的count文法很拖累效能，而用select直接去定位比“当下去count”快多了，所以就增加一个字段，把常常要调用的数据放那个字段中
就是提前统计好经常用的数据，放在新增的字段里，等到调用时因为都“一早就统计好了” 就能直接用select进行调用 避免临时去count
我理解的是这样，不过好像它放数据的地方貌似比“内存”还“方便获取”，估计唯一区别是这个. 等等，不对，还有一个区别，添加了字段后之前的view代码不用改！这个区别比较厉害的样子哈哈哈哈
另一个灵感是，这方法名字里的counter原来是“统计者”的意思啊哈哈哈 全名是“将 count 快取起来”的意思啊哈哈哈 推测是因为这个方法大部分用于“统计”场景吧哈哈哈
侦测是否提升速度的 gem bullet 尝试记录
按照步骤安装完毕后， 打开网页有跳出提示，更详细版的提示可以去log/bullet.log找到
貌似这个USE eager loading是指我导致了 N + 1 Query的问题了
截图bullet log里面的详细版展示一下
我思考一下哈，要统计的是user数量，那么要去添加字段的表格是post表格，然后要加 counter_cache条件的是user.rb对吧？先实作一下吧
开了new branch的我无所畏惧 尝试代码的时候真心爱这个开支线的功能啊啊啊
嗯 没效果啊...
还有显示likes的统计导致的问题 尝试用counter_cache解决
也没有反应啊啊啊
夜深了，为了赶进度，这个gem的用法二刷的时候or实战建网站的时候再说吧...不是优先级别很高的gem
下次状态好的时候再尝试可以直接Google 关键字 "logdown bullet" 会找到相关资料的
进度比较重要啊啊啊
网友评论