首席DBA用SQL洪荒之力，造一把通向数据库的钥匙

对于大数据领域而言,各种技术层出不穷.但对于广大使用者来说,往往会存在一定的使用门槛,因此现在的一种趋势就是在大数据领域也引入“类SQL”,以类似SQL的方式访问数据.这对于广大使用者来说,无疑大大降低了使用门槛.

解答一些疑问：

1. NoSQL、NewSQL已经超越了传统数据库,SQL没有了用武之地!各种技术有着各自适合的不同场景,不能一概而论.SQL语言作为关系型数据库的主要访问方式,依然有其用武之地.
2. 以后都是云时代了,谁还用关系型数据库!对于价值密度高,严格一致性的场景,仍然适合采用关系型数据库作为解决方案.
3. 我编程都是用OR Mapping工具,从不需要写SQL!的确,引入OR Mapping工具大大提高了生产效率,但是它的副作用也很明显,那就是对语句的运行效率失去了控制.很多低效的语句,往往是通过工具直接生成的.这也是为什么有的Mapping工具还提供了原始的SQL接口,用来保证关键语句的执行效率.
4. 大数据时代,我们都用Hadoop、Spark了,不用写SQL啦!无论是使用Hadoop、Spark都是可以通过编写程序完成数据分析的,但其生产效率往往很低.这也是为什么产生了Hive 、Spark SQL等“类SQL”的解决方案来提高生产效率.
5. 数据库处理能力很强,不用太在意SQL性能!的确,随着多核CPU、大内存、闪存等硬件技术的发展,数据库的处理能力较以前有了很大的增强.但是SQL的性能依然很重要.后面我们可以看到,一个简单SQL语句就可以轻易地搞垮一个数据库.
6. SQL优化,找DBA就行了,我就不用学了!SQL优化是DBA的职责范畴,但对于开发人员来讲,更应该对自己的代码负责.如果能在开发阶段就注重SQL质量,会避免很多低级问题.
7. 我只是个运维DBA,SQL优化我不行!DBA的发展可分为“运维DBA->开发DBA->数据架构师…”.如果只能完成数据库的运维类工作,无疑是技能的欠缺,也是对各人未来发展不利.况且,随着Paas云的逐步推广,对于数据库的运维需求越来越少,对于优化、设计、架构的要求越来越多.因此,SQL优化是每个DBA必须掌握的技能.
8. 现在优化有工具了,很简单的!的确现在有些工具可以为我们减少些优化分析工作,会自动给出一些优化建议.但是,作为DBA来讲,不仅要知其然,还要知其所以然.况且,数据库优化器本身就是一个非常复杂的组件,很难做到完全无误的优化,这就需要人工的介入,分析.
9. 优化不就是加索引嘛,这有啥!的确,加索引是一个非常常用的优化手段,但其不是唯一的.且很多情况下,加了索引可能导致性能更差.后面,会有一个案例说明.

我们通过一个示例,说明一下理解SQL运行原理仍然很重要.

这是我在生产环境碰到的一个真实案例.Oracle数据库环境,两个表做关联.执行计划触目惊心,优化器评估返回的数据量为3505T条记录,计划返回量127P字节,总成本9890G,返回时间999:59:59.

从执行计划中可见,两表关联使用了笛卡尔积的关联方式.我们知道笛卡尔连接是指在两表连接没有任何连接条件的情况.一般情况下应尽量避免笛卡尔积,除非某些特殊场合.否则再强大的数据库,也无法处理.这是一个典型的多表关联缺乏连接条件,导致笛卡尔积,引发性能问题的案例.

从案例本身来讲,并没有什么特别之处,不过是开发人员疏忽,导致了一条质量很差的SQL.但从更深层次来讲,这个案例可以给我们带来如下启示：

1. 开发人员的一个疏忽,造成了严重的后果,原来数据库竟是如此的脆弱.需要对数据库保持一种”敬畏”之心.
2. 电脑不是人脑,它不知道你的需求是什么,只能用写好的逻辑进行处理.
3. 不要去责怪开发人员,谁都会犯错误,关键是如何从制度上保证不再发生类似的问题.

下面我们来看看常见的优化法则.这里所说的优化法则,其实是指可以从那些角度去考虑SQL优化的问题.可以有很多种方式去看待它.下面列举一二.

（编辑：应用网_丽江站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!