我先找个环境测试一下吧，远程意义不大，就是看操作一遍而已
上面的步骤是我已经在生产上都复现了的。。
，那我们分析一下
1 个赞
看了一下你的版本是v5.0.3，问一下你的 tidb-server 哪有什么配置嘛？
有这几个
server_configs:
tidb:
log.slow-threshold: 300
mem-quota-query: 12884901888
new_collations_enabled_on_first_bootstrap: true
oom-action: cancel
performance:
server-memory-quota: 8000000000
txn-entry-size-limit: 12582912
收到
1 个赞
不过刚发现一个问题，8000000000 才 7G 多？
这个是tidb server的配置，只限制的是tidb server的使用内存， 这个sql本来按执行计划是用几KB，然后日志中显示用了1.09G，都远没有到达这个7G
而且这个设置 如果达到限制，是随机kill 语句，现在的表现是tidb server重启，报错是不一样的
不过我可以测试下这个，但感觉不太可能是这个
可以提供一下 /tmp/1001_tidb/MC4wLjAuMDo0MDAwLzAuMC4wLjA6MTAwODA=/tmp-storage/record 这个文件吗
看起来，使用 hash agg 会导致 OOM，这里的 estimate 不是准确的；hash agg 会全量聚合所有数据，然后再执行 limit，所以这里是可能导致 OOM 的。
可能的解决方式是尝试使用 stream agg。
可以考虑在 main_post_id 字段上添加索引，然后看看计划能否产生 stream agg，如果可以的话应该可以把内存占用降下来
对这个字段加上索引就不会走tiflash了吧。。
对，不会走 tiflash 了，但是因为你有 limit，量不大的话也可以很快跑出来
这个表3个多亿。而且后续会有更多数据，另外我们的场景不只这一个sql，加了索引，对这个表的操作就都不会走tiflash了，对其他查询影响很大
并不会，添加索引之后只是这一条 SQL 不走 TiFlash 了，其他不使用这个索引的 query 会继续使用 TiFlash
如果优化器不够聪明，可以使用 optimizer hint，譬如强制不使用某个 index