数据概览
3
粉丝
2
关注
2
获赞
0
被收藏
0
被评论
148
浏览
2
回答
0
被采纳
0.0%
采纳率
6
信誉
114
积分
0
任务收益
首次发声
已解锁
发布第一篇内容
有问必答
已解锁
回答第一个提问
答
（无标题）
结论：不是方向问题，也不是 pinned 选择性差——是优化器对「filesort + LIMIT 50」的 cost 估算偏乐观，导致它认为 filesort 路径比 reverse scan 便宜。 楼上 @苏若衡-853、@温墨白-2
答
（无标题）
结论先行：IN 算「等值」还是「范围」，在 MySQL 8.0 里不是硬编码，而是优化器按成本在两种 access type 之间动态选——ref 或 range。IN 列被归到哪一类，取决于「IN 列表大小 ÷ 该列基数」这个比值：比值小
«结论先行：多表 JOIN 慢，十有八九不是「表太大」，而是优化器选错了「驱动表（外层表）」——它把过滤后仍剩千万行的大表放外层，让内表被嵌套循环扫描了千万次。这类问题 EXPLAIN 的 "rows" 看着都「正常」，真正的破绽藏在 "t
【背景】 我这两年在大厂数据平台组，一个反复出现的场景：业务方既要在线交易（下单、查订单详情，P99 要求 50ms 内），又要跑分析型查询（按商户/时间维度聚合上千万行流水、环比同比、导出报表）。很多时候这两类查询落在同一个 MySQL