Eric_Lian 结论：指令长度其实和性能关系不大。重点是在索引算法。 如果实在想调的话，自己弄个性能检测工具，查看查询计划，针对查询计划里的慢查询建索引。 然后，这么长的指令不是人写的，是查询中间件一层一层套进去的。这样的好处是插件也能够更好地干预 flarum 的行为，而不用进行巨大的改动。属于是灵活性导致产生这么长的 sql 语句的。
封启 Nodeloc 等2.0吧…可以测测2.0，虽然还在beta，非官方插件装不上。但支持sqlite和postgres，挺不错的…我尝试过postgres，但是不知道怎么将数据从mysql迁移到postgres。
几于道 Nodeloc 不客气，其实Flarum的SQL很难优化，要有一定的技术开发能力，还要比较熟悉Flarum的代码结构什么的。 再或者之前我想过一套思路，那就是把数据和UI分离开，自己搞一套缓存，不搞优化，直接替换，比如用redis把每个页面和用户存起来，有数据再更新
Nodeloc jock12 没有用的。使用meilisearch只是优化了搜索的查询，但使用meilisearch后，从meilisearch返回flarum的那个大sql比任何一个其它地方的都要恐怖。
Nodeloc 封启 2.0一样，Flarum的性能问题其实在Laravel，Laravel太优雅，导致开发容易性能优化很难。比如现在首页的主题列表，原本只是一个简单的查询，但安装几个拓展以后，就变成一个涵盖了多个全表扫描的查询，当主题数较多时，效率非常低。