只有这监控?
不错
2021 年了,还有人用 mongodb?
只影响第一次加载?
我信了!你重启一下试试
Hotwire™
如果你的返回结果集已经很少了就没必要用这种方法了。你直接 count 也不会慢到哪里去。这种场景是查返回值会很大的那种 count 的
7000w?误差多少?
不需要 select count(*),直接用 select *
只要 basecamp 还赚钱就问题不大,以 dhh 的影响力招人应该不成问题
为什么是 php
好久没这么热闹了,开心,撒花! +1
好吧
我对 TiFlash 感兴趣,打算来试试分析类场景的应用。
一定不完全准确,但只要你的 vacuum 执行正常,我观察下来,表越大误差越低。
一个小时的误差还真赶不上这种,有了新的过滤条件还要维护,在索引里的一般误差不是很大,这种方案的前提是表大并且更新频繁,auto vacuum 就会运行的频率高,数据也就准了
摆脱 UI 驱动是 GQL 的一个优势,普通接口你需要先有页面设计,再开发接口。GQL 的话,你完全可以根据 DB、Model 直接自省出 Type,写出接口。少部分页面比如 landing page 之类,才需要和前端去沟通格式。想省时间吃饭 GQL 还真管用。
之前的一个自动化的实践:
这个是表记录条数,不能加条件的,实际就没什么用了。
快如⚡
cool
这种方法很通用,几乎解决了我遇到了所有复杂拼接问题
感觉不需要 find by sql 的
user = User.find(x)
done_products = user.evaluations.where(xx).select(:product_id)
Product.select("products.*").joins("JOIN (#{done_products.to_sql}) AS dp ON dp.producct_id = products.id").where(xx).page(xx)
Product.select("products.*").joins("LEFT JOIN (#{done_products.to_sql}) AS dp ON dp.producct_id = products.id").where("dp.product_id is null").page(xx)
这篇文章首先提出一种稍微复杂的查询场景,在这种场景下,Rails 提供的查询方法已经无法轻易地组装查询逻辑,这个时候用原生的 SQL 语句反而简单许多。
这个例子还有点简单,但结论我觉得恰恰是 Rails 查询封装结合 SQL 的方式在解决复杂过滤和分页需求更适合。
心动了
u 盘
pagy
Have a great day!
又炸了
补个图
magic