DBA 有心眼，难搞的SQL实际案例分析--都是别人的错-优快云博客

本文链接：https://blog.youkuaiyun.com/liuhuayang/article/details/147290035

开头还是介绍一下群，如果感兴趣PolarDB ,MongoDB ,MySQL ,PostgreSQL ,Redis, OceanBase, Sql Server等有问题，有需求都可以加群群内有各大数据库行业大咖，可以解决你的问题。加群请联系 liuaustin3 ，（共2790人左右 1 + 2 + 3 + 4 +5 + 6 + 7 + 8 +9）(1 2 3 4 5 6 7群均已爆满，开8群260+ 9群)

Austindatabases公众号已经开启了，AI 文章分析，AI 文章问答，比如你想知道AustinDatabases 里面，说了多少种数据库，那些是讲 MySQL,那些是PostgreSQL, 那些是OB ，POLARDB ，MongoDB ,SQL Server, 阿里云的，问他他会列出来，同时如果有问题不明白，可以将文章的文字粘贴到公众号提供的专用AI ，公众号将通过众多文章（目前1300多篇）来进行尝试性的解释。使用方法，直接到微信公众号中点击服务，选择AI问答。如下示例

SQL的优化，DBA的方案大部分都是研究数据库执行SQL的原理，此后从SQL的撰写方法，SQL的索引的缺失，改写SQL，添加HINT等等各种技术手段来进行SQL的优化。经常有一些高手，在谈到SQL优化的时候，提到由于某些因素，我们将问题的SQL直接原地消失了。

今天我就拿出一个实际的案例，说说SQL是怎么消失的。SQL是数据库中最重要的部分，传统关系型数据库运行中最重要的增删改查，就是要通过SQL最终在数据库中实现。为什么会产生SQL的问题，最主要的原因我们要寻根溯源，混乱的业务，混乱的开发方式所导致的。

混乱的开发方式我们应该都有所体会，而混乱的业务需求，我们今天就来说说，混乱的业务需求。混乱的业务一般开始于没有理清的业务模式，一个新的业务模块，一个新的项目，都可能会产生这样的SQL，产品经理随意的一个想法，我们要让客户随时能查询到数据，我们要给他们制造图表，让他们时刻的查询到企业的销售额，利润，以及人耗，等等这些产品经理随口的想法，都是未来体现在数据库上的“灾难”。

这类SQL都有一个通病，违背传统数据库的运行规律，大量的产出即系OLAP的查询，这类查询因为是产品经理的一时兴起，或者客户的一个“大胆”的idea。我要知道我的企业的运营决策，我要更智能的用数据来指导我的业务，我要在每一分钟知道我的客户下单后，还有没有可能给他补单，我要知道客户下单后，他有没有可能复购，我复购的信息在什么时间推送给他。

是的老板们的想法，非常的天马行空，且自觉良好，仿佛此刻上帝的位置应该他来做，但这却苦了数据库，DBA。开发按照老板的想法，对数据库开始了蹂躏，各种在程序里面需要写几千行的代码，到了数据库几十行，几百行的SQL就是这些代码的替死鬼。因为老板要的急，程序员要体现价值，而锅就到了实现这个“梦想”的后端，也就是数据库。

此时一个好的数据库可能会救了你，当然MySQL这类的数据库产品你就不要指望了，而类似ORACLE, SQL SERVER,PG这类的数据库才是这类需求的受害者。开发人员会以，这些数据库的OLAP处理能力很强为借口，倒打一耙的将所有的问题都堆到 DBA的身上。

那么我们此时就要问一句，SQL有没有必要出现在系统里，我们从根源去解决问题，看似这个是一个不可能的任务，因为老板并不认识谁是这个单位的DBA，他要的是结果，而开发人员的地位一直比DBA高这也是人尽皆知的。

那么咱们就只能从SQL的几个点来去分辨这个SQL有没有可能消失或进行业务上的改造的可能性。

1 SQL 在没有主键的等值查询条件的情况下，有没有时间字段的范围

2 在捕捉到一些慢查询语句的情况下，这些语句的时间范围是多少，通过一些时间字段来推断这样的业务应该出现在数据库系统中与否。

3 从开发的嘴里去沟通，去寻找慢SQL的业务逻辑属性

4 从产品经理的嘴里，得知这个SQL的历史由来，也就是业务的由来，确认是否是核心业务，还是边缘业务。

在把这些问题都拿到后，DBA就可以下手了。

逻辑如下：

后面就是大家关心的如何进行去除这个SQL的问题：

1 告知业务部门，以及开发部门，这个SQL已经无法优化，原因是由于业务在设计初期未进行严格的讨论，对于整体数据未进行有效过滤导致，希望限定此语句涉及的数据容量，减少此SQL对企业核心业务的影响。

2 针对此问题可以给出架构解决方案，因为是非重要的SQL，那么此系统中有没有这类SQL大量的运行，我们可以找开发来共同解决问题，前提是这个问题是设计问题，是开发不当的问题（具体的从架构的角度去寻找漏洞），然后给出数据库解决方案，如上期，我们采用腾挪大法，将这些不重要的SQL和数据都迁移到另一个数据库产品中，如分析型数据库产品，通过CDC软件如TapData或类似的软件进行数据的实时复制。

最终这样的SQL很可能就被移动到其他的位置，或者在讨论中，开发给出我们可以在java 系统中解决数据查询和过滤的问题，而不是借用数据库来解决，这也是可以的，主要目的就是转移矛盾，把难以解决的SQL问题，直接甩出去，甩到其他的非重要的数据库，或者在其他的解决层面解决，我见过最厉害的一个DBA，和财务沟通，将财务撰写SQL的业务逻辑进行否定，最终将这个SQL彻底从系统中抹去，这是需要一个DBA除了有数据库的知识以外，沟通交流，业务知识，开发知识，架构知识，综合运用，解决棘手的问题，最终的目的只有一个，挨骂没有我，背锅没有我，都是你们的错。

注：前提是如果是可以优化的SQL，那就先用简单的技法先优化，以上的方案仅仅适用于一部分难缠的问题而已，千万别认为是通用方案。

置顶

MongoDB “升级项目” 大型连续剧(1)-- 可“生”可不升

美国知名大学开授China数据库理论，你没看错！

DBA 会架构，实际案例分析--“IT流氓”得下跪

数据库的 4月1日愚人节，我没有被愚弄！

搞 PostgreSQL多才多艺的人--赵渝强《PG数据库实战派》

追逐太阳的男人--林春《金融数据库转型实战》

数据库的 4月1日愚人节，我没有被愚弄！

数据库界的“申公豹”，带云DBA走出--救生筏困境！

阿里云DTS 产品，你真让我出离愤怒，3年了病还没治好？？？

让数据先“活”起来，如何实现数据在企业中的最大价值