-
我的订单列表页慢得离谱,抓 SQL 一看一个请求里竟然发了一百多条几乎一样的查询,我对着 ORM 懒加载在循环里逐个触发的 N+1 查询这个坑排查了大半天的复盘
一个让我对 ORM 方便的代价彻底警醒的数据库坑,隐蔽在代码读起来非常优雅面向对象毫无破绽,我只是访问了一下每个订单的用户名,可这行无辜的属性访问背后 ORM 悄悄发了上百条数据库查询。订单列表页要显示每个订单和下单用户名字,我用 ORM 写 orders = Order.query.all() 然后 for order in orders: order.user.name。页面慢得离谱,抓 SQ…- 2
- 0
-
我的列表页明明感觉只查了一次数据库,慢查询日志里却冒出几百条 SQL,页面慢得像蜗牛,最后揪出是 ORM 的 N+1 查询在背后疯狂打库的深度复盘
我用 ORM 做订单列表页,查出订单后遍历,用 order.getUser().getName() 显示用户名,代码里只写了一句查询。可页面慢得要命,慢查询日志里竟冒出几百条几乎一样的"按 id 查用户"的 SQL——一条订单对应一条!深究才懂这是经典的 N+1 查询:ORM 懒加载在查订单时没带出 user,直到我在循环里访问 getUser() 才偷偷各发一条 SQL,N …- 0
- 0
-
数据库 N+1 查询完全指南:从一次"列表页慢到几秒、数据库 QPS 莫名暴涨"看懂 ORM 的隐藏查询风暴
2022 年我做一个后台管理系统有个订单列表页把订单查出来每一行显示订单号金额还有下单人的名字用 ORM 取关联数据这件事我压根没多想第一版我做得很省事ORM 用着真方便我要下单人的名字不就是点一下 order.user.name 循环里一行行拼每行点一下把名字取出来就完事了本地开发时真不错我库里就造了几十条订单列表页刷一下就出来几行代码搞定我心里很踏实可等这个系统真正上线订单涨到几万几十万条一串…- 0
- 0
N+1查询
-
￥优惠劵使用时效：无法使用使用时效：
之前
使用时效：永久有效优惠劵ID：×