应只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助手,依托大模型,帮助用户记录、整理和分析音视频内容,体验用大模型做音视频笔记、整理会议记录。
相关推荐
forest_099 分钟前
多 Agent 协作第二课:交叉验证≠独立验证Decay__3 小时前
VMware 安装 SQL Server 双节点 AlwaysOn 可用性组教程 —— WSFC、AG 与侦听器完整部署(系列核心篇)databook3 小时前
时间序列数据,先拆规律还是先查异常茶栀(*´I`*)4 小时前
SQL 性能分析:从慢查询日志到执行计划的完整定位方法师夷长技以自愈4 小时前
手搓 AI Agent 第 8 篇:从手写循环到画流程图——LangGraph 封装艺杯羹4 小时前
1Panel 装好后 ufw 仍是 inactive:一次服务器安全盲区复盘jyOverQ4 小时前
从零学 JVM(六):垃圾回收算法详解——标记清除、标记复制与标记整理aifannihao5 小时前
Rust 1.100 的 DropGuard:用 Python 实测失败回滚与吞异常code2cat5 小时前
【随笔】MCP工具重试:任务已经创建,响应丢了怎么办用户019027581617 小时前
天勤 tqsdk 能做 A 股行情吗?期货强项与股票数据选型