共 7 篇相关文章
作者在客户现场遇到一个性能糟糕的SQL查询，通过PL/SQL Developer执行时效率极低，影响了业务操作。他详细记录了整个排查与优化过程：首先定位到问题SQL，随后通过分析执行计划，发现表连接顺序不当与关键字段索引缺失是主要瓶颈。针对这两个核心原因，作者分别调整了连接顺序并补建了复合索引，最终使该查询的执行时间从数分钟缩短至毫秒级，优化效果显著。 这篇文章的价值在于它完整呈现了一个真实、典型的SQL性能问题从发现到解决的闭环思路。作者没有停留在简单的“加索引”建议，而是结合具体的执行计划与优化前后的数据对比，清晰展示了如何系统性地诊断和根治数据库查询性能问题。对于日常需要与数据库打交道的开发者和DBA来说，这种一步步分析问题的实战记录，比泛泛而谈的优化原则更具参考意义。
这篇讲的是通过一系列针对单表单索引的测试，系统总结了Oracle数据库中几种常见的Index访问方式。作者从实际的执行计划出发，用不同的hint组合，模拟了Oracle执行计划中几种典型的index访问路径。 测试核心聚焦于Hint对优化器选择索引访问方式的直接影响。文章展示了在相同数据和索引条件下，使用不同hint（如`INDEX`、`INDEX_FFS`等）后，执行计划中的代价、成本以及具体的I/O读取方式会发生怎样的变化。 有趣的是，文章没有去深究为什么每种路径的IO和成本会呈现这样的结果，而是直接给出了不同hint下的统计对比。它更像一份精心准备的“实验报告”，通过具体的执行计划统计，直观展示了hint对优化器选择index访问方式的直接影响。 其价值在于，它把经常让人困惑的`INDEX FULL SCAN`与`INDEX FAST FULL SCAN`等概念，放到了一个可观察、可对比的实验场景里。对于想理清“hint如何改变索引使用方式”这一具体问题的开发者，这份实测数据提供了一个清晰的参考起点。
这篇讲的是MySQL应用中那些看似不起眼、却在悄悄拖垮性能的操作习惯。 作者没有罗列常规的“如何优化”，而是从反面切入，系统梳理了那些会直接“杀死”性能的行为模式。比如不恰当的索引设计如何引发全表扫描、配置参数设置不当如何导致资源浪费，或者是一些看似便捷的SQL写法背后隐藏的执行计划陷阱。文章的价值在于，它帮开发者建立起一种“性能风险意识”——你不是在主动优化，而是在避免日常开发中无意识犯下的错误。 这种视角对于需要排查慢查询或系统卡顿的团队尤其有用。它提醒我们，性能问题的根源往往不在于缺少某个高级技巧，而在于基础操作中的疏漏。把这些“坑”提前识别并避开，本身就是最有效的性能保障策略。
这篇讲的是Oracle数据库中一个容易被忽略的索引特性演进。作者从Oracle 11g引入的“invisible index”（不可见索引）切入，指出其设计思想很可能更早源自“virtual index”（虚拟索引）的概念。文章对比了这两者的异同：不可见索引是数据库优化器能感知但不会使用的索引，主要用于评估索引变更的影响；而虚拟索引则更“虚”，可能不占用实际存储空间，常用于更早期的测试或特定工具链中。 核心差异在于它们与数据库优化器的交互程度和适用场景。不可见索引为DBA提供了一个安全的“试验沙盒”，可以在不影响线上性能的前提下，验证新索引的收益；虚拟索引则可能更多用于快速原型验证或特殊调试。文章并未止步于功能罗列，而是引导读者思考索引可见性管理背后的运维智慧——如何在保障系统稳定的同时，为性能优化保留灵活的探索空间。这种将新功能回溯至历史概念的分析视角，对理解Oracle的设计脉络很有帮助。
这篇讲的是作者对MySQL查询优化的一次观念刷新。他过去从SQL Server转向MySQL时，发现官方文档更推荐JOIN，而子查询用`EXPLAIN`分析常表现不佳，于是形成了“MySQL子查询效率差”的刻板印象，在项目中一律改用JOIN写法。 然而一次线上故障改变了他的看法。网站因访问缓慢被排查，管理员发现涉及几张小表的查询平均耗时高达40秒。作者拿到慢查询日志，发现正是典型的JOIN写法，且`EXPLAIN`结果显示使用了临时表和文件排序。常规添加索引并未奏效，在尝试将JOIN改写为`IN`子查询后，执行计划瞬间变为使用索引，查询效率恢复正常。 作者随后对网站近10条类似语句进行了优化，网站整体速度得到显著提升。这个案例生动地说明了，数据库查询优化不应拘泥于固定的教条或过往的经验，必须针对具体的引擎版本、数据规模和执行计划进行实测与分析。MySQL的查询优化器在不同场景下对JOIN和子查询的选择可能存在差异，实践出真知。
这篇讲的是作者在一年内完成超过百项Oracle性能优化的实践复盘。从体系架构的改造、缓存策略的应用，到具体实现方式的调整，乃至添加提示、建立索引等细节调优，文章系统梳理了这些形形色色的案例。作者并未停留在罗列技术点，而是着重提炼了进行有效优化所必须具备的思维与执行路径：如何诊断瓶颈、选择正确的优化层次（是架构、代码还是SQL），以及如何评估改动带来的实际效果。 文章的核心在于将零散的实战经验沉淀为可复用的方法论。它没有泛泛而谈理论，而是基于“解决真实生产问题”这一主线，穿插了具体的优化措施与背景。例如，如何权衡架构改动带来的长期收益与短期风险，或者一个简单的索引变更背后需要考虑哪些因素。对于面临类似挑战的数据库工程师或开发者来说，这篇总结提供了宝贵的实践视角和决策参考。
这篇文章从一个典型的运维场景出发：当你在 statspack 报表中发现逻辑读、物理读极高的 SQL，分析过表统计信息且执行计划已走索引时，该如何进一步判断其是否真正优化？作者没有停留在表面指标，而是深入探讨了在“看似合理”的表象下，如何验证索引选择的效能与 SQL 语句执行质量之间的深层关联。 文章的核心在于提供一种系统性的诊断思路，而不仅仅是工具使用教程。它引导读者超越“是否走了索引”这个二元判断，去追问索引类型（比如是否是覆盖索引）、访问路径（如回表次数）、以及索引效率与数据分布的实际匹配度。通过对这些细节的剖析，文章旨在帮助读者建立一套从性能现象反推至设计根源的完整优化逻辑。 读完能感受到，真正的优化工作往往从那些“看起来已经优化过了”的地方开始。它教会我们如何拆解一个“标准答案”，并在实际业务场景中做出更精准、更有效的判断，这对于任何需要与数据库性能打交道的工程师来说，都是一次扎实的思维训练。
