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

从上面的“数据价值密度、实时性”来看,传统关系型数据库适合于价值密度更高、实时性要求更高的场景(这也就不难理解类似账户、金额类信息都是保存在传统关系型数据库中)；MPP架构的NewSQL次之,MPP架构的NoSQL更适合于低价值、实时性要求不高的场景.

从下面的“数据规模”来看,传统关系型数据库适合保存的大小限制在TB级别,而后两者可在更大尺度上(PB、EB)级保存数据.

从下面的“典型场景”来看,传统关系型数据库适合于OLTP在线交易系统；MPP架构的NewSQL适合于OLAP在线分析系统；而NoSQL的使用场景较多(利于KV型需求、数据挖掘等均可以考虑).

最后从“数据特征”来看,前两者适合于保存结构化数据,后者更适合于半结构化、乃至非结构化数据的保存.

归纳一下,不同技术有其各自特点,不存在谁代替谁的问题.传统关系型数据库有其自身鲜明特点,在某些场合依然是不二选择.而作为其主要交互语言,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优化的问题.可以有很多种方式去看待它.下面列举一二.

（编辑：ASP站长网）