应只SELECT必要字段、WHERE条件勿误放ON中、用覆盖索引避免回表、小表驱动大表且驱动表需有索引。SELECT 中只写真正需要的字段,别用 *用 * 看起来省事,但数据库得把整行所有字段从磁盘读出来、经过网络传给客户端、再被应用层丢弃掉------这些字段哪怕你压根没用,也全程参与了 I/O、内存、网络开销。尤其当表里有 TEXT、JSON、BLOB 或宽字段(比如 50 列)时,性能下降会非常明显。实操建议:JOIN 前先列清楚业务逻辑真正要什么:是只需要 user.id 和 order.total?那就只 SELECT 这两个如果用 ORM,确认它生成的 SQL 没偷偷加 * 或冗余字段(比如 Django 的 .values() / .only() 要显式指定)对宽表 JOIN,宁可多写几遍字段名,也别依赖 SELECT * ------ 后续加字段时,* 会无声无息拖慢查询WHERE 条件写在 JOIN 后,别错放到 ON 里过滤主表ON 是定义关联逻辑的,WHERE 才是最终筛选结果的。把本该在 WHERE 的条件(比如 user.status = 'active')误塞进 ON,会导致 LEFT JOIN 变成隐式 INNER JOIN,或漏掉本该保留的左表记录------这不是字段多不多的问题,是逻辑错误。常见错误现象:LEFT JOIN users u ON u.id = o.user_id AND u.status = 'active' → 如果用户 status 不是 active,这条 user 记录就"消失"了,哪怕你只想查订单,也拿不到对应用户信息正确做法是:LEFT JOIN users u ON u.id = o.user_id WHERE u.status = 'active'(注意:这会让 LEFT JOIN 失效,等价于 INNER;若真要保留左表空值,WHERE 应写成 WHERE (u.status = 'active' OR u.status IS NULL))用覆盖索引避免回表,让 SELECT 字段全落在索引里如果 SELECT 的字段都能被某个索引"覆盖",MySQL/PostgreSQL 就不用回主键索引捞数据------直接从二级索引里读完走人。这对 JOIN 尤其关键:每多一次回表,就是多一次随机 I/O。 通义听悟 阿里云通义听悟是聚焦音视频内容的工作学习AI助手,依托大模型,帮助用户记录、整理和分析音视频内容,体验用大模型做音视频笔记、整理会议记录。
相关推荐
兵慌码乱14 小时前
面向桌面端的资产管理系统分层架构设计与核心模块实现hboot15 小时前
AI工程师第三课 - 机器学习基础顾林海20 小时前
Agent入门阶段-编程基础-Python:流程控制呱呱复呱呱1 天前
Django CBV 源码解读:一个请求是怎么找到你的 get() 方法的Nturmoils1 天前
订单列表慢查询,先看 WHERE、ORDER BY 和 LIMIT曲幽1 天前
刚部署的 LibreTranslate 频频翻车?我掏出了 20 年前的 StarDict 词典,用 FastAPI 搭了个本地词典翻译 API渣波1 天前
拒绝 SQL 焦虑!手把手带你用 NestJS + Prisma + DTO 写出“防弹”级后端代码荣码1 天前
用Streamlit给AI应用套个界面,10行代码出Web页面兵慌码乱2 天前
基于Python+PyQt5+SQLite的药房管理系统实现:事务一致性与界面解耦全流程解析金銀銅鐵2 天前
[Python] 体验用欧几里得算法计算最大公约数的过程