共 4 篇相关文章
这篇讲的是如何快速解读 MySQL EXPLAIN 执行计划，抓住性能优化的关键。对于 DBA 和后端开发者来说，EXPLAIN 是诊断 SQL 性能的必备技能，但面对输出结果中的众多字段，很容易抓不住重点。 文章从实战出发，提炼出了最需要关注的几列信息：type、key、key_len、rows 和 Extra。作者特别详细地梳理了 `type` 字段的取值，将其从最差的 `ALL`（全表扫描）到最好的 `system`（系统表）进行了清晰排序，比如解释了 `index` 类型可以避免回表，`const` 则意味着基于主键的唯一查询。 除了查询类型，文章也点明了其他几个要素的优化含义：`key` 列告诉你是否命中了索引；`rows` 值越小代表预计扫描行数越少，查询越高效；而 `Extra` 中的 `Using filesort` 和 `Using temporary` 则是需要警惕的性能隐患信号。 掌握这几个核心要素，你就能在面对慢查询时，快速从 EXPLAIN 结果中定位到瓶颈所在，为索引优化和查询改写提供明确方向。
这篇讲的是从Oracle 10g/9i升级到11gR2时，可能因新特性默认启用而“惹祸”的那些事儿。作者指出，像自适应游标共享（Adaptive Cursor Sharing）、自动串行直接路径读（Automatic Serial Direct Path Read）、延迟段创建（Deferred Segment Creation）以及GC相关的新特性等，在实际中可能并不适合许多国产应用，会给原本稳定的系统带来执行计划波动等不确定风险。 文章的核心是一份可直接操作的“排雷清单”。作者汇总了一系列优化器和其他相关特性的隐藏参数，提供了一套通过设置参数来选择性禁用这些新特性的方法。其背后的逻辑很务实：如果你的应用没有条件或时间对这些新特性进行充分测试，不如主动禁用它们，让数据库在11gR2的架构上退回到类似于10gR2（10.2.0.4）的稳定行为模式。 作者也解释了“禁用新特性是否还有升级必要”的疑问。他强调，这并非全盘否定，而是给出了一份可选的选项列表。熟悉且已验证的特性可以保留，不熟悉的则可以选择关闭，从而在享受新版本其他益处的同时，规避因未经测试的优化器行为变更带来的潜在故障。对于那些需要手动开启才会生效的特性（如Flashback Archive），则不受此列表影响。
这篇讲的是如何看懂 MySQL 的查询执行计划，把数据库的“黑盒”决策过程变成可分析的“白盒”逻辑。作者从 `EXPLAIN` 命令入手，深入拆解了执行计划中 `type`、`key`、`rows` 等关键字段的含义。比如，`type` 字段从效率最低的 `ALL`（全表扫描）到最优的 `const`（常量查找），清晰展示了不同访问方式的性能阶梯；`rows` 则是优化器基于统计信息预估的扫描行数，是衡量查询代价的重要参考。 文章的核心价值在于教你如何利用这些信息定位性能瓶颈。当你发现查询走了 `ALL` 或者实际扫描行数远大于预期时，就可能需要考虑优化索引或调整查询语句。它把优化器“选择哪条路”的逻辑，和你“该不该铺路（建索引）”的决策直接联系了起来，从“会用 SQL”进阶到“会优 SQL”，提供了切实的诊断路径。
这篇讲的是MySQL查询优化器中的存取类型，作者从“下篇”延续上文，聚焦于第七部分“存取类型”的深入解析。文章系统对比了ALL、index、range、ref、const等常见存取类型，详细阐述了它们各自的技术含义和性能差异。例如，ALL代表全表扫描，通常效率最低，适用于数据量极小的场景；而const则通过主键或唯一索引直接访问，效率最高，适合精确查询。作者通过实际案例和EXPLAIN输出示例，展示了如何识别查询的存取类型，并针对不同场景给出优化建议。比如，在范围查询中，range类型比index更
