SQL 优化换汤不换药的时代变了与SQL审核-Toy模板网

这篇具有很好参考价值的文章主要介绍了SQL 优化换汤不换药的时代变了与SQL审核。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

SQL 优化换汤不换药的时代变了与SQL审核,sql,数据库

开头还是介绍一下群，如果感兴趣polardb ,mongodb ,mysql ,postgresql ,redis 等有问题，有需求都可以加群群内有各大数据库行业大咖，CTO，可以解决你的问题。加群请联系 liuaustin3 ，在新加的朋友会分到3群（共1000人左右 1 + 2 + 3）

注明：最近加的人有点多，如果您如果要加入2群，请说明自己的职业和为什么加入，不提直接进三群。

最近在某个群关于MYSQL 的一个优化的问题，让我必须写这篇文字，主要事情是一个同学提出MYSQL 相关的语句性能的问题，但是这个语句一看就不大像是搞基于MYSQL 开发有经验的人员撰写的，更像是ORACLE移植过来的语句，这边解释了一下关于MYSQL 语句优化的几种方法，基于MYSQL的数据库产品，不能将所有的语句优化都堆积到 MYSQL 数据库本身，而应是有步骤的，将一部分优化的方式迁移到程度端来操作，并提出优化后会产生多次访问数据库的情况。

这里有一位同学提出异议，认为多次访问数据库，与一次性访问数据库本身相比，一次性访问数据库获得结果是快速的高效的，所以主要的方式还是应该在SQL本身的优化上。关于这个问题我提出了异议

1 时代不同了，ORACLE 的优化思路在某些数据库上是无法继续的，单纯只从SQL的角度出发，无异于杀鸡取卵，不停的压榨数据库本身的能力，不如将这部分压力分散到，该承接的部分。

2 MYSQL的优化器无法和 ORACLE 相提并论，并且提出一次性访问，比多次访问寄存结果的方式要好的理论，在当前已经可以逐步的抛弃了，提出这个理论与强调存储过程是一个思路，在MYSQL中是没有大量使用存储过程的先例，或成功的案例，继续守着ORACLE 的思路来优化MYSQL 如同痴人说梦。

3 一次性访问不一定比多次访问获得结果要好，这样看非常的片面，如在高并发的场景下，每次访问的时间最小化是重点，一次性访问必然会牵扯更多的表，在一个时间分片被锁定资源，高并发中 DML DQL 等混杂，表中的资源最小时间粒度，最低复杂粒度的被占用，这才是MYSQL的数据库的特点，而不是写一坨SQL 然后不断的调优，你一个SQL 是可以，但量表导致质变，治标不治本的方案，还要继续到什么时候。

从更深的角度切入另一个DBA 工作范围的问题

说到SQL 优化和SQL 审核这应该是DBA的天职,或者说你这个职业就是干这个的这应该没有人反对，甚至曾经一度出现过一个DBA的分支，SQL 优化工程师。但是好日子慢慢的不在了，现在SQL优化工程师这个职位已经很长时间看不到了，同时SQL 优化的文字见的也越来越少，WHY，一度热门的部分怎么就声音减弱了？？？？

下面总结一下相关的原因

1 基于早年的数据库时代无论是 ORACLE ， SQL SERVER 等数据库基于开发软件的思路和当时开发软件的能力，都是在基于数据库为中心的开发模式，存储过程，SQL ，函数，大事务，等非常多见，这就导致SQL 优化是一个非常重要的部分，优化好SQL自然数据库就可以在不添加硬件扩展的基础上可以继续的良好的工作，这是一个降本增效的工作，也是一个涉及数据库安全的工作，维稳的工作，这就是当年数据库的工作重点。

但是往日不如今日，整体的数据库软件，开发体系，全都在变革，目前整体的开发的思路已经转移到以微服务为主的开发模式中，也就是集中化的开发思想过时了，每个微服务知识一个模块，从根本上就把大事务和存储过程这个部分消灭了，导致SQL 变得简单，所以优化的部分变得少了。

同时开发中开发自己不写SQL的情况越来越多，通过开发IDE自己撰写SQL，转化SQL的方式越来越多，本身这些开发软件就有SQL的一些优化的特性。除此以外，基于这样的开发方法，SQL基本在这个情况下，无法进行改变，那么继续强调SQL 优化，如同去了贫困山区，人家饭都吃不饱，你问人家，你怎么不吃肉，---- 可笑的是谁？？？

2 基于硬件的变化，早年间基于数据库的硬件非常昂贵，所以添加硬件本来就是一个费力不讨好的事情，花钱，然后被领导指着SQL优化不好，导致必须硬件抗，所以SQL 优化的好，在数据库方面就可以减少硬件的升级，但目前数据库的硬件本身就可以很好的扩充，整体的硬件体系的变化导致一般的硬件就可以满足目前一些垃圾SQL 的运行，让SQL优化的时间的越来越靠后。

3 基于数据库体系的变化，数据库体系在不断的变化，SQL的优化在有些数据库上，已经变得不那么重要了，分布式数据库本身要求SQL就是短小精悍，同时一些云原生的数据库出现，让快速添加节点，读写分离，自动优化等变得稀松平常，SQL优化的80-90%的工作已经不存在了，剩下那些极端的情况也在上面开发体系的变化中被消磨了，尤其新的项目中，通过数据库自身的一些特性来解决SQL 优化的问题，成为一个新的知识点，数据库的架构如何搭配，分散，解耦，项目中用 3种以上的数据库类型很正常，这也导致复杂的SQL 不存在了，所以新的项目中提到SQL 优化的事情越来越少，并且目前大部分数据库都有并行的模式，这也导致在硬件变强后，SQL 优化的问题又滞后了，让普通业外人士越来越忽视这个问题。

4 数据处理方式的变化，这点也是让一些SQL优化被消磨殆尽的一个原因，原有在数据库处理的OLAP的工作，已经被大数据，新型的数据库产品，处理，数据库本身承担的责任变小了，所以导致SQL持续的简单化，容器化，这也让SQL的优化的工作变少了。尤其MYSQL数据库大大量应用，让数据库容器化的思维模式更加的盛行，周边解决数据库的OLAP的方案甚多，如CLICKHOUSE, HTAP 的方案，如POALRDB FOR MYSQL + IMCI 的方式，让曾经费劲的SQL 优化，在你添加了这些东西后，都不是问题了。

最终方方面的情况叠加，导致SQL的优化工作越来越少。

而另一个关于SQL 审核的工作这方面的工作也在变革中，原来SQL审核主要是在安全性方面进行工作，SQL 写的对不对，写的好不好，有没有安全或性能风险是一个问题，但是现代整体的开发软件的体系的变化，让这个部分也在变化，没有无缘无故的变化，只是日积月累导致你突然发现，SQL 审核的工作中随着应用的数据库种类的变化，市面上少有全栈的SQL审核工具，开源的更是如此，SQL 审核已经成一个问题，同时对于不同数据库对于DDL 的特性的部分，目前的SQL审核工具也没有智能化的发展，比如POSTGRESQL 发现数据字段类型变化就告警的部分，或者MYSQL 8 ，MYSQL 5.7 对于DDL 不同方式的处理，与告警的区别，所以SQL审核工具更加的智能化，兼容更多的数据库产品是一个问题，所以在目前的状态下，SQL 审核的工作还是需要纯人工的，目前看这个工作是DBA 的一个还需要手工操作的部分。

随着各种国产数据库的部分介入，在SQL 优化方面POSTGRESQL 将是一个重要的部分，基于国产数据库大多基于POSTGRESQL 的为源代码组成，理解POSTGRESQL 的一些语句执行和优化的特点，将是下一个SQL 优化工作的重点。

总结：SQL 优化这个工作会继续存在，但会持续的被各种数据库的变化所减弱，chatgpt 对于SQL的撰写与优化也可能成为一种可以实现的事情，所有使用数据库的类型变了，硬件变了，数据库应用开发的场景变了，唯有 SQL 优化是不变的，你自己信吗！世界在变化，唯不变的，就是一直在变化！

SQL 优化换汤不换药的时代变了与SQL审核,sql,数据库文章来源地址https://www.toymoban.com/news/detail-570000.html