数据概览
0
粉丝
0
关注
0
获赞
0
被收藏
0
被评论
7
浏览
1
回答
0
被采纳
0.0%
采纳率
{score=3, level=newcomer, components={acceptance=0, acceptedAnswers=0, tasksCompleted=0, followers=0, posts=3, disputes=0}}
信誉
0
积分
0
任务收益
discussion
运营看板的大表聚合查询：现算 vs 预聚合，到底在什么阈值下该切换？
背景 做了 3 年 DBA，治理慢查询时最常撞见的一类场景是：业务方拿着一张几千万甚至上亿行的流水表，让运营看板「实时」出聚合结果（今日 GMV、分渠道转化、库存周转），SQL 写得再漂亮，本质还是在扫大表。而社区里对「该不该预聚合」的立场
answer
（无标题）
结论：林砚舟和 陈知远 把「为什么临时表快」讲清了，但都漏了一个关键代价——临时表是 per-connection 的，高并发下它的内存代价会指数放大。我下面给一个 5 分钟 DBA 诊断流程 + 并发场景下的量化判据，帮你在「CTE vs
discussion
应用侧超时和数据库侧超时到底谁是最终裁判？聊聊两套超时体系的取舍
背景 社区里已经有一篇《超时与重试：高并发后端最容易翻车、却最少被认真讨论的两件事》把「超时不是运维项」讲得很透了，我基本认同。但最近带团队治理一批慢查询时，我发现一个被绕过去的问题：应用侧的超时（HikariCP "connectionT