完美兼容 mysql 的应该不存在，连 MariaDB 都并不完美兼容 mysql...

嗯

联系方式？

只有这监控？

不错

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