-
我图省事把上万个 ID 一股脑塞进 SQL 的 WHERE id IN (...) 里去批量查询、小批量测的时候快得飞起,结果生产环境列表一大这条查询就慢成狗有时还直接报参数过多的错、DBA 看监控说这一条 SQL 把库都拖垮了,排查很久才搞懂一个在小规模下完美的 IN 写法放大到上万个值时会在解析执行计划缓存好几个地方同时崩坏的深度复盘
我有个需求要根据一批 ID 去数据库批量查记录、写得特别直白把所有 ID 拼进一个 IN 列表 SELECT * FROM orders WHERE id IN (1,2,3,...上万个)。开发测试时手头 ID 也就几十个查询飞快毫无问题顺利上线。可生产环境:某些场景 ID 列表上万个这条查询慢得离谱从毫秒飙到几秒十几秒、而同样表查单条飞快;某些数据库上 IN 列表超过某数量直接报错参数太多/表…- 2
- 0
-
PostgreSQL 索引与执行计划工程化完全指南:从一次"5 亿行订单表查询走全表扫 8 秒不出"看懂为什么加 B-tree 远远不够
2022 年我们公司有一套核心的订单库跑在 PostgreSQL 上数据量大概 5 亿行单库 30 多张表上线两年一直挺稳定直到某天产品突然要做一个卖家后台的查询页面要支持按订单状态时间范围金额范围客户名称等多个条件组合查询我心想 PostgreSQL 嘛加几个索引就完事顺手在 status time amount 上各加了个 B-tree 索引部署上线第二天卖家中心的接口接连超时业务那边把电话打…- 9
- 0
-
慢 SQL 优化完全指南:从一次"加了索引 EXPLAIN 也显示用了索引,查询却还是慢"看懂执行计划
2022 年我接手优化一个订单系统的慢查询运营后台有个订单列表页打开要十几秒怎么让它快起来这件事我压根没多想第一版我做得很顺手慢就是因为没索引嘛我看了一眼那条 SQLWHERE 条件里用到了 user_id 和 status 那我就给这两列各加一个索引改完一测真不错列表页快了我心里挺踏实SQL 优化嘛不就是看哪列没索引补上就行可等这优化上了生产数据量真正涨上来一串问题冒了出来第一种最先把我打懵我明…- 2
- 0
执行计划
-
￥优惠劵使用时效：无法使用使用时效：
之前
使用时效：永久有效优惠劵ID：×