数据库生态圈（RDB & NoSQL & Bigdata）——专注于关系库优化（Oracle&Mysql&PG&SQL Server ）

三种连接方式的伪码实现，记录于此，仅供同行和自己学习参考。

几天前，接到某用户现场的求助，说数据库非常慢，insert几百条数据，需要等几十分钟，根据他们说的情况，告诉他们需要收集相关信息，OS配置没问题，OS资源情况没问题。。。，一路排查下去，最后发现，数据库的性能确实有问题，根据获取的信息，告诉用户处理措施，下面是分析时参考的主要信息，大家可以参考学习，禁止转载： 需要说明的是，该系统配置相对较高，负载也不高，就是慢，大家想想，应该有个大体

昨天，正好有点空时间想看看书，结果，刚打开书，没看几个字儿，接到用户电话说：一个库有问题，希望能帮忙看下。因为我知道他们那边也有自己的专职DBA，于是问：没让人给看看吗？答：能找的人都找了，也调了好久，又是操作系统，又是数据库的，调了很多天了，还是感觉很慢，他们最后给出的意见是改SQL代码，那么多哪里改的过来？想远程看看，但用户似乎挺着急：拖了这么久了，现在很着急，没办法才找到你的，你赶紧过来吧。

本文对《高性能SQL调优精要与案例解析》一书读者的疑问做了解答，并对SQL调优（SQL TUNING或SQL优化）话题进行了讨论，记录于此，供各位和自己研究学习。

今天在看崔华老师所著SQL优化一书时，看到他解决SQL性能问题的一个案例，崔华老师最终成功定位问题并进行了解决。这里，在崔华老师分析定位的基础上，做进一步分析和推理，以供大家学习讨论，记录于此，仅供大家和自己今后参考研究。

本文分享一次SQL调优经历中的一个美丽而巨大的计划美图，希望各位在欣赏美图的同时，能从中有所启发，记录于此，供同行及自己今后学习研究。

今天接到用户的需求，某程序十几个小时没出结果了，很纳闷儿，于是让相关人员取了explain plan等信息，拿到explain plan后，搂一眼，就知道问题出在了哪里，explain plan跑偏了，看了下统计信息，不算陈旧，但还是重新收集了，但explain plan依然跑偏，因为用户急于跑这个程序，时间有些紧迫，于是只能通过加hint搞定，很简单的两个hint，当然，还有很多其他的方法，用户

今天帮用户做了一个SQL TUNING，原来为1个多小时不出结果，tuning后为几秒，图片为我调优时参考的explain plan，隐去某些具体信息，虽然通过该计划，不能完全确定SQL慢的原因，但稍微仔细观察下，基本能确定问题所在了，大家可以参考学习，禁止转载。

本人讲述了一次数据库优化的过程，主要涉及到过程逻辑修改和建索引问题，虽然简单，但效果非常好，反响也非常好，记录于此，以供同行和自己今后借鉴。

本文记录了一次sql优化的过程，通过和用户间的详细沟通和优化过程的陈述，说明了sql优化的方法和详细步骤，关键是能体现sql优化的思路，记录于此，望和广大同行朋友共勉。

该文中记录了一次帮人SQL TUNING的过程，因为是REMOTE，且不能连接对方的库，只是通过简单的询问相关信息，支持对方完成了一个SQL TUNING，同时，因不能全面了解对方数据等多方面信息，也许还有很多更进一步优化的缺憾，但只想通过本文说明SQL tuning的过程和思路，以期和同行共勉。

本文介绍了Oracle中pq_distribute提示的使用，记录于此，供同行及自己今后参考或学习。

新书发售，敬请关注。。。

《高性能SQL调优精要与案例解析》样章，欢迎各位关注下载。

本文主要阐述和探讨了各主流关系库中的索引机制，希望对《高性能SQL调优精要与案例解析》一书读者有所帮助，也希望其他同学多多获益。

本文简要介绍了各主流关系库获取SQL语句执行计划的方法，以及对执行计划内容和信息的正确理解，以帮助广大读者对《高性能SQL调优精要与案例解析》一书中内容和精髓有更好的理解和掌握，记录于此，供广大读者和自己学习研究。

应各位读者要求，现将《高性能SQL调优精要与案例解析》中《10.4 SQL语句改写》部分整理成电子文档，供各位读者及同学下载。

ContentsOverview and IntroductionHow Analytic Functions WorkThe SyntaxExamplesCalculate a running TotalTop-N Queries    Example 1    Example 2Windows    Range Windows    Compute average salary for def...

本文转自：https://www.cnblogs.com/xuanzhi201111/p/4175635.html在日常工作中，我们会有时会开慢查询去记录一些执行时间比较久的SQL语句，找出这些SQL语句并不意味着完事了，些时我们常常用到explain这个命令来查看一个这些SQL语句的执行计划，查看该SQL语句有没有使用上了索引，有没有做全表扫描，这都可以通过explain命令来查看。所以我们...

本文转自：https://www.cnblogs.com/gomysql/p/3720123.html在工作中，我们用于捕捉性能问题最常用的就是打开慢查询，定位执行效率差的SQL，那么当我们定位到一个SQL以后还不算完事，我们还需要知道该SQL的执行计划，比如是全表扫描，还是索引扫描，这些都需要通过EXPLAIN去完成。EXPLAIN命令是查看优化器如何决定执行查询的主要方法。可以帮助我们深入...

本文转自：https://blog.youkuaiyun.com/u010061060/article/details/52473244explain select * from userexplain extended select * from userid SELECT识别符。这是SELECT的查询序列号 select_type SELECT...

本文通过实例的方式，给大家提供一个SQL TUNING时经常用到、效果显著的一个技巧，该技巧实践中用途广泛，通过巧妙的利用index的有序性，省去了大量的资源消耗，也极大地提升了SQL效率和用户满意度，但在实施该技巧的过程中，可能会遇到一些问题，本文也提出了相应的解决方案，在此分享给大家，抛砖引玉，共同学习，共同提高。

oracle11g中最重要的特点之一——Adaptive Cursor Sharing (ACS)，几乎完美的解决了之前版本不绑定不行，绑定也不行的尬尴问题，今天有机会对此特点再次进行研究和查阅资料，并将主要内容总结成文，记录于此，以便今后学习使用，也希望对各位朋友有所帮助。

之前这些Oracle11g的新特性都了解过，但当时都没做归纳和总结，以至随着时间的推移，很多都有点忘记了，这几天正好有时间，重新复习下这些知识点，并对资料和文档做了归纳和总结，记录于此，希望对自己今后的学习和工作有帮助，也希望对各位朋友有所帮助。

今天刚清闲点，在网上看些资料，这时，用户QQ上发来求助，说一个更新数据的SQL语句很慢，都一个小时了也不出结果，于是，了解下具体的情况，略施小计，5s出结果，下面是我分析该SQL时用到的执行计划，略去部分细节，大家可以参考学习，禁止转载：

和一个小朋友聊天，小朋友愁眉苦脸，不爱说话，我问怎么了，他说：经理交代的一个任务完成不了。我问：什么任务？他说：程序里的一个功能对应的SQL，太慢了。我问：现在性能是什么样？他说：一分钟。我问：达到什么标准？他说：5s以内。接着，我了解了些具体的信息，心里有数了，说：这个还是比较容易滴。略施小计，SQL再跑，1s出结果，小朋友大悦说：这下我可以交差了，改来改去都好几天了。下面是该SQL调整之前的计

本文介绍了如何排查数据库锁与性能问题的思路，通过实例，说明了如何一步步排查锁等待与性能问题，以及如何解决性能问题的步骤和方法，抛砖引玉，仅供参考学习研究。

通过参照分析SQL和执行计划，通过SQL改写进行调优，该文中涉及性能问题为现实中一典型的SQL性能调优问题，望各位能通过执行计划的分析，有所收获。

本文通过一个典型SQL性能问题的诊断和调优过程，详细、深入的说明了SQL TUNING的方法和思路，尤其是，当我们面对一个涉及分区表的SQL TUNING时，我们应该考虑的因素及解决问题的步骤等，本文中给出了很好的示范，望能抛砖引玉、举一反三，供大家学习参考。

昨天，正忙着，一个用户来电，说一个系统非常缓慢，导致整个系统无法正常使用，必须马上处理，先看系统资源，通过用户反馈的信息，内存，IO没问题，CPU资源严重紧张，idle持续为零，堆积任务达几百个，系统几近挂掉，通过分析用户反馈的数据库信息，最终确定一条SQL为整个事件的罪魁祸首，该语句阻塞达上百个，告知用户后，用户分析后确定，先kill掉相应会话，然后组织人员修改该SQL，kill掉相应会话并调整

前天，收到用户的邮件，说某应用某模块的数据不出来了，而且特别慢，通过了解，该模块为报表数据，所查的数据都是提前算出来的，了解了基本情况后，通过用户获取了系统资源信息和数据awr报告，通过分析发现，服务器IO资源紧张，导致IO性能差，通过awr报告，跟踪到是两个问题过程导致了该问题的发生，暂时调整了数据库的内存参数，问题得到部分缓解，通知研发优化两个存储过程，同时，我提供了优化建议，下面是分析时用到

本文通过简单的例子，完整而详细的说明了oracle11g中新特点——SQLPA的使用，该功能在实际工作中有着非常广泛的实用价值，尤其在数据库升级和迁移过程中，非常有用，现整理记录于此，以供大家学习和今后自己参考。

Oracle12c中的自适应查询优化有一系列不同特点组成。像自适应计划（AdaptivePlans）功能可以在运行时修改执行计划，但并不允许计划中连接顺序的改变。自动重优化基于先前执行和反馈到优化器信息的学习，因此，语句下次解析执行时将会生成一个较好的计划。1.   统计信息反馈(势反馈)势反馈（Cardinalityfeedback）在Oracle11r2中被引进。当优化器产生一个执行计划时，统...

Oracle11g中，为了改善DBMS_STATS包收集统计信息时的唯一值计数功能，增加了 APPROX_COUNT_DISTINCT函数，但文档中并未记载。Oracle12c文档中包括了该函数，因此，我们现在可以在应用中随意使用它。本文通过实例对该新函数进行了说明，并测试了对性能的改善，记录于此，以供今后同行及自己参考学习。

Oracle12c作为和之前版本相比有着重大变化的版本，推出了诸多的新功能和特性，而除了可插拔数据库新特性外，oracle12c性能方面的新功能和特性也是一个重大改变和特性，本文详尽的对优化器新特性SQL计划指令进行了陈述，并通过实际例子进行了测试和解释说明，记录于此，以供同行和自己今后学习和参考。

前几天，一个用户找到我，说查一个小表的时候非常慢，我问有多慢，他说最快也得半个小时才能出结果，有时干脆不出结果，我说小表多大，他说就几十兆，有点疑惑，让他帮忙获取了相关信息，一看就明白了，原来所谓的小表是“假”的，下面是分析时参照的信息及分析的步骤。SQL语句：select * from t_rec where rec_date>trunc(sysdate-1);SQL计划：--------...

本文详细介绍了一次解决性能问题的过程，通过该过程，也说明了一个解决比较隐蔽性能问题的方法和思路，进而也说明了优化之路，抛砖引玉，仅供学习参考。

前几天，一个用户的研发人员找到我了，说他们有个SQL语句非常慢，我说多慢？他们说：半个小时也没出结果。于是问他们要了SQL语句和执行计划，SQL语句就不能再这里贴出来了，下面是调整前的执行计划（略去某些细节信息，如需了解细节，请到本人QQ空间浏览）：PLAN_TABLE_OUTPUT----------------------------------------------------------...

最近，处理了一个用户的数据库，据用户反映，数据库定时在每天晚上自动down掉，刚开始拿到用户提供的信息资料，简直不敢相信，从来没见过“变形”成这样的数据库，经过连续两天的排查，确定数据库服务器配置及数据库配置存在问题，当然，这得结合多方面的资料，最后给用户提出了方案，用户当晚立刻按照我的方案进行了实施，通过彻夜观察，数据库一直运行良好，没有再宕机。至今已经有一个多月，用户反映良好，大家看看当时数据

前几天，去一个用户那里解决些琐碎的事情，解决完主要问题，和一个小朋友闲聊，他有点愁眉不展、郁郁寡欢的样子，似乎没心情和我说话，之前，他的话是最多的，见此状，我就问：怎么了？小朋友？，他说，这几天应用人员说他的某个模块的性能很差，要几十秒甚至几分钟才能出结果，我问：那要多久才能满足要求呢？他说：几秒钟就好了。然后，我让他去了那个模块的SQL语句，取了下计划，我看了眼，然后告诉他：价格条件不行吗？。。