浅谈关于SQL优化的思路

零、为何要优化

• 系统的吞吐量瓶颈每每出如今数据库的访问速度上
• 随着应用程序的运行，数据库的中的数据会愈来愈多，处理时间会相应变慢
• 数据是存放在磁盘上的，读写速度没法和内存相比

1、观察

MySQL优化≠SQL语句优化，理解这一点很是重要，虽然大部分时候咱们都在调优SQL语句。

然而，MySQL的优化倒是始于观察，并且有时候观察几分钟，几小时就能得出结论的，可能要观察一天以上。

这么作的目的很明显，就是为了帮助咱们定位问题所在。 好比：MySQL的负载会在固定的某个时间节点忽然暴涨，或者一请求某几个页面就产生了较为明显的延迟，甚至影响了随后的各个请求等。

观察的手段有多种多样，阿里云有强大的RDS控制台，也能够自建一套监控平台，最次的就是临时跑个shell脚本，收集MySQL运行情况。 观察的指标也不尽相同，最知名的 show status 命令列出的指标就能不下200个，因此观察也要有所取舍。 常常受人关注的指标有当前链接数以及最大链接数，当前运行的线程数，慢查询数量等。

2、分析

将观察的结果作进一步分析，也就造成了不一样的解决思路。

多是某个时间节点缓存失效，致使MySQL的负载激增，能够设法将缓存失效的时间节点尽量均匀的分摊在一天24小时中，或者找个访问量较少的时段刷新缓存。

多是SQL语句存在潜在问题，在某些状况下会有性能问题，能够用 show full processlist 定位是哪一个库，也能够开启慢查询，直接定位到有问题的SQL语句，使用explain分析语句执行计划。可能加个索引能解决问题，也有可能join太多表，须要拆分查询，也有可能单表体量过大，要拆表了。

多是机器自己性能问题，所谓“巧妇难为无米之炊”，这个时候要考虑扩容了。

3、解决

在分析阶段已经说起了大部分解决手段了，最后总结一下：

一、引入缓存，固然，这是一把双刃剑，要想用的恰如其分，仍是须要必定的功力。缓存也分两方面的，一方面是MySQL的内部缓存机制，MySQL提供了多种缓存参数的配置，好比查询的结果集缓存，结果集排序的缓存，可根据实际状况进行调整。另外一方面是MySQL以外的缓存，好比Redis+MySQL的架构，开启了Hibernate（Mybatis）的缓存功能。缓存的引入无非是想减轻MySQL的查询负担，可是必须在性能稳定性与数据时效性之间取得平衡。

二、SQL语句有性能问题，这种状况时有发生，一般是上线以前未能作一个完整的基准测试，而只是简单的功能性测试。当数据量积累到必定程度以后，SQL性能问题就集中爆发出来了。因此，在写完SQL以后，要养成explain的习惯，将潜在的性能问题扼杀在萌芽中。固然，咱们也要避免“过分优化”，咱们要预见获得一张表是读取次数多，仍是更新次数多，数据量会不会爆发性增加，仍是增加十分缓慢。固然，写SQL语句也要遵循必定的原则，好比何时用IN查询，何时用EXISTS谓词，在JOIN以前是否是能够精简一部分表数据，创建的索引可否正确派上用场……

三、必要的时候，能够对机器进行扩容，固然系统的总体架构也能够考虑进行优化，搭建MySQL集群，可靠性和可用性都能获得大幅提高。

4、补充：SQL范式

1NF

每个份量必须是不可分的数据项。

特色：

• 有主键，且主键不能为空。
• 字段不能再分。

2NF

在范式一的基础上，且每个非主属性彻底函数依赖于码。

特色：

• 知足第一范式。
• 表中的每个非主属性，必须彻底依赖于本表码。
• 只有当一个表中，主码由两个或以上的属性组成的时候，才会出现不符合第二范式的状况。

3NF

在知足第二范式的基础上，且每个非主属性既不部分依赖于码也不传递依赖于码。

特色：

• 知足第二范式。
• 非主属性不能传递依赖于码。

** BCNF**

在知足第三范式的基础上，且不容许主键的一部分被另外一部分或其它部分决定。

特色：

• 知足第三范式。
• 全部非主属性对每个码都是彻底函数依赖。
• 全部的主属性对每个不包含它的码，也是彻底函数依赖。
• 没有任何属性彻底函数依赖于飞码的任何一组属性。

以上是对MySQL优化的框架性思考。