-
编辑 删除
左右SQL执行计划妙招 ⑧ ——执行计划SQL写法差异改变【rowid 的影响】
分区条件的有无直接决定了查询的执行效率。在分区表查询中，即使业务逻辑上某些条件是冗余的，但从性能优化角度考虑，明确指定分区键条件仍然是必要的。这种看似"多余"的条件实际上是分区表查询优化的关键所在...
-
编辑 删除
左右SQL执行计划妙招 ⑦——执行计划SQL写法差异改变【rownum实体化】
本文介绍了利用ROWNUM实体化技术优化Oracle复杂SQL查询性能的方法。通过一个运营商系统真实案例，展示了子查询导致的笛卡尔积问题：原SQL执行需30秒，而仅注释子查询部分可在1秒完成。分析发现优化器错误执行顺序导致无关联表间产生笛卡尔积。解决方案是在子查询中添加ROWNUM字段，强制优化器先完成内部表连接，避免与外层表产生笛卡尔积。优化后查询时间从30秒降至1秒，性能提升30倍...
-
编辑 删除
左右SQL执行计划妙招 ⑥ ——执行计划SQL写法差异改变【rownum分页】
本文深入解析Oracle数据库ROWNUM分页查询的性能优化策略。通过对比实验发现，将ROWNUM限制条件置于内层查询可触发COUNT STOPKEY机制，使查询在达到指定行数后立即终止扫描，性能提升显著（从1048缓冲区降至5个）。文章详细剖析了COUNT STOPKEY的工作原理、触发条件及适用场景，并提供了标准分页模板和实际应用案例，强调排序字段索引和分页大小控制的重要性，帮助开发者避免常见误区，实现高效分页查询。
-
编辑 删除
左右SQL执行计划妙招 ⑤ ——执行计划利用设计特性改变【并行度影响】
本文分析了Oracle数据库中并行度设置对执行计划的影响。通过实验对比串行和并行执行的性能表现，展示了并行执行计划的结构变化，包括PX协调器、并行数据发送等组件的出现。文章重点指出表级并行属性设置的风险，建议通过SQL级别的parallel hint精确控制并行度，避免资源消耗失控。最佳实践包括...
-
编辑 删除
左右SQL执行计划妙招 ④ ——执行计划SQL写法差异改变【insert all】
本文探讨了Oracle数据库中INSERT ALL语句与普通插入语句在执行计划上的差异及其对性能的影响。通过实验对比，发现INSERT ALL语句通过MULTI-TABLE INSERT操作，减少了源表的扫描次数，降低了I/O操作和锁竞争，提高了事务一致性。虽然在简单场景下性能提升不明显，但在复杂生产环境中，INSERT ALL展现出显著优势。理解不同SQL写法对执行计划的影响，是数据库性能优化的重要技能...
-
编辑 删除
左右SQL执行计划妙招 ③ ——执行计划SQL写法差异改变【with子句】
传统写法存在多次全表扫描和重复计算的问题，导致资源消耗较高。而使用WITH子句后，聚合函数的结果被临时存储并复用，减少了全表扫描次数，从而...
-
编辑 删除
左右SQL执行计划妙招 ②——Hint无效原因
很多DBA和开发人员都曾遇到这样的情况：我们根据分析添加了看似完美的HINT，却发现执行计划完全没有变化，好像Oracle优化器完全忽略了我们的建议...
-
编辑 删除
左右SQL执行计划妙招 ①——子查询的应用范围
不仅需要懂执行计划，如果还可以左右SQL的执行计划，那就更厉害了....当SQL如同迷宫，执行计划成为谜题，你是束手待毙还是掌握破局之道？三种控制子查询执行计划的隐秘技巧，如同三把钥匙，让你在数据海洋中自如穿行。从查询块内的精准控制，到全局别名的巧妙引用，再到神秘的qb_name魔法...这场与优化器的博弈，才刚刚开始...
-
编辑 删除
数据处理进化史之小明历险记④（大结局）：AI数据库开启智能新纪元
"从Excel到集中式数据库，从分布式架构到融合平台，再到AI数据库，我们见证了数据处理技术的四次革命。但技术进化永不停歇。"他指向未来规划图，"我们已经看到下一代数据技术的雏形——自主进化的数据生态系统，它不仅能自我管理、自我优化，还能自我进化，创造出我们尚未想象的数据价值...
-
编辑 删除
数据处理进化史之小明历险记③：融合一体数据库崛起
"所有测试环境的JSON查询都没问题，为什么生产环境会崩溃？"凌晨2点的紧急会议上，CTO的声音透着疲惫和困惑。整个技术团队已连续工作18小时，"潮购"平台的搜索功能仍时断时续。工程师们尝试了各种应急方案：增加数据库实例、优化索引、重写查询语句，但成效有限...
-
编辑 删除
数据处理进化史之小明历险记②：分布式数据库破局
夜已深，大多数同事已离开，小明正整理分布式数据库的运行报告。忽然，监控系统发出刺耳的警报声...
-
编辑 删除
基于达梦的SQL等价改写优化案例精选第三部【顺势而为】(大结局）② 等价改写中的陷阱
在SQL优化中，"顺势而为"不仅要求我们遵循数据库引擎的工作原理，还需要尊重数据的本质特性，包括类型特征和NULL值语义。只有全面理解这些概念，才能进行既正确又高效的SQL等价改写。记住：改写不仅要追求性能，更要确保语义的真正等价...
-
编辑 删除
基于达梦的SQL等价改写优化案例精选第三部【顺势而为】① 列的类型转换
SQL优化的第三部分中，我们强调了“顺势而为”的原则，即遵循数据库引擎的工作原理来编写查询语句。核心思想是保留列的纯洁性，避免对列进行函数操作或类型转换，以提高查询性能。通过实际案例展示了在WHERE子句中对日期字段使用TO_CHAR函数的问题，包括无法利用索引、类型不匹配和语义不清晰等。优化方案建议直接...
-
编辑 删除
数据处理进化史之小明历险记①：从Excel困局到集中式数据库的飞跃
凌晨2点，办公室只剩下键盘敲击声和电脑风扇的嗡鸣。小明第47次点击"保存"，Excel再次弹出"程序无响应"的灰色对话框。距离老板要求的"明早9点必须看到数据报表"只剩7小时，而这份包含十万行销售记录的文件，此刻就像一颗定 时 炸 弹...
-
编辑 删除
基于达梦的SQL等价改写优化案例精选第二部【精兵简政】④ 多余写法
在我们探讨"精兵简政"系列的最后一篇，我们将聚焦于SQL中常见的"多余写法"问题。冗余代码不仅影响可读性，更会导致数据库做许多不必要的工作，从而影响性能。让我们通过实际案例来学习如何精简SQL，让代码更加高效。## 案例8 一个有着多处多余写法的经典脚本```sqlselect * from (select rownum num, h.*&nbs
-
编辑 删除
基于达梦的SQL等价改写优化案例精选第二部【精兵简政】③ 有困难先将需求最小化
SQL优化不仅仅是技术层面的改进，更是思维方式的转变。当我们面对复杂问题时，不要急于堆砌复杂的代码，而是应该先问自己："这个问题的本质是什么？有没有更简单直接的解决方案？"往往，最优雅的解决方案也是最简单的那个...
-
编辑 删除
基于达梦的SQL等价改写优化案例精选第二部【精兵简政】② 无脑复制粘贴
本案例揭示了SQL开发中一个常见但危险的习惯——通过复制粘贴来处理看似类似的逻辑。这种方式看似方便，实则带来了性能负担和维护困难。在"精兵简政"的理念下，我们应当始终寻求更优雅、更高效的解决方案...
-
编辑 删除
基于达梦的SQL等价改写优化案例精选第二部【精兵简政】① 莫名其妙的行列转换
在数据分析和报表生成过程中，行列转换是一个常见需求。然而，开发人员常常在实现这类需求时走弯路，创建了不必要的复杂查询。今天我们要分析的案例就是这样一个典型示例...
-
编辑 删除
基于达梦的SQL等价改写优化案例精选第一部【一统天下】④ or 与 union all的优化交响
在SQL开发中，我们经常会遇到这样的情况：需要组合多个相似但略有不同的查询结果。大多数开发者本能地使用UNION/UNION ALL来解决，这种方式直观易懂，但在特定场景下却隐藏着巨大的性能浪费。本案例将从执行原理层面，深入剖析为什么在某些情况下，OR条件能比UNION ALL带来质的性能提升。的聚合艺术
本文展示了如何通过SQL的GROUP BY与CASE WHEN结合，将复杂的UNION查询优化为单一查询，减少表扫描次数，提升性能...
