只有这监控？

不错

2021 年了，还有人用 mongodb？

只影响第一次加载？

我信了！你重启一下试试

Hotwire™

如果你的返回结果集已经很少了就没必要用这种方法了。你直接 count 也不会慢到哪里去。这种场景是查返回值会很大的那种 count 的

7000w？误差多少？

不需要 select count（*），直接用 select *

只要 basecamp 还赚钱就问题不大，以 dhh 的影响力招人应该不成问题

为什么是 php

好久没这么热闹了，开心，撒花！ +1

好吧

我对 TiFlash 感兴趣，打算来试试分析类场景的应用。

一定不完全准确，但只要你的 vacuum 执行正常，我观察下来，表越大误差越低。

一个小时的误差还真赶不上这种，有了新的过滤条件还要维护，在索引里的一般误差不是很大，这种方案的前提是表大并且更新频繁，auto vacuum 就会运行的频率高，数据也就准了

• 1 减少请求数据是在多端情况去比的
• 2 落地页这种 gql 也不会一个请求返回所有数据，你也可以像普通 api 接口一样，为落地页单独做几个接口
• 4 这个绝对是 gql 的优点，你普通 api 接口删了返回字段就不报错吗，gql 是可以直接 detect 出 break change 的

摆脱 UI 驱动是 GQL 的一个优势，普通接口你需要先有页面设计，再开发接口。GQL 的话，你完全可以根据 DB、Model 直接自省出 Type，写出接口。少部分页面比如 landing page 之类，才需要和前端去沟通格式。想省时间吃饭 GQL 还真管用。

之前的一个自动化的实践：

• 数据库字段加 comment
• rake 从 rails model 生成 graphql type 自动读取数据库字段注释
• graphiql/graphql doc
• 自动 break change 通知

这个是表记录条数，不能加条件的，实际就没什么用了。

快如⚡

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