这里写的是一个系列，这是系列的第三篇，这个系列主要是针对SQL优化，前两篇的地址下文字的下方。

接上次，上次提到了SQL 优化的原理与理论，实际上SQL 优化的原理是离不开两个模型与数据存储的， 整体SQL 优化的核心也在于两个模型和数据存储。简化的说明这两个模型

1  数据访问成本模型

2  数据访问算法

3  物理数据存储单元与逻辑数据存储单元

我们先看看数据访问成本模型，成本模型分为两类，（以下的解释来自于ORACLE 官网，基于这一方面的优势，还是来看看ORACLE对于这两种方式的解释）

1 cost-based optimizer 

cbo 是目前主流的数据库执行计划的模式，根据数据库中的统计信息（实际上是每个表中的统计信息）来根据数据库中的cbo计算引擎来计算出多个执行的可能性，并从中选择一个总成本低的。

2  Rule based optimizer

这个是初数据库的执行器的执行方式，他根据一定的预定的规则来产生执行计划，而产生的执行计划是无法获知其成本的，只是按照预定的设计来执行，RBO的执行方式基本上已经从先进的商业数据库中剔除，或正在剔除，保留的原因是，基于CBO的方式中如果无法获得准确的统计分析信息，则RBO在执行中还是一种可以使用的执行方式。

基于以上的描述，与之有关的内容包含了 表和索引的状态（如果索引受损或失效），系统的状态（这里指的包含的硬件系统的状态），数据库中锁的状态，事务的状态，事务的隔离型（对隔离型type）, 数据库系统，乃至操作系统的一些参数的设置， 以上这些统统都会影响一个SQL的运行以及效率。

所以多说一句，SQL优化恰恰是在不考虑以上的状态的一种行为，所以SQL优化是有局限性的，很多不入行或开发人员，一贯的认为SQL优化就是拯救一个烂系统的救命绳，其实这样的想法是很外行的思维方式，DBA必须予以纠正，否则要不你就是救世主，要比你就是整个“公司” 的罪人和无能者。

2 数据访问算法（模型）

在我们获得了执行计划后，我们就的去执行，而执行中就会提到另一个模型或者说是算法，举例我们在提取数据的时候是在提取数据后，将符合条件的数据保留，并汇聚，在进行计算后得出结果，还是直接将大范围的数据放入内存后，在进行过滤和汇聚在进行计算得出结果，这对硬件资源的影响是不同的，例如CPU  与内存。 部分开源数据库中有采用直接提取数据，在进行过滤的方式，典型的就是之前的MYSQL  5.X ，准确的说是5.6之前的MYSQL ，在没有条件下推的方法下，查询效率是比较低的，后续MYSQL 提供了 IRR 则缓解了一部分查询性能低的问题。

3  数据存储结构

数据的存储结构对于数据提取的性能是有影响的，数据库存储的结构和组织结构，主要有以下几种，HEAP 堆表结构， PG采用的就是这样的数据存储方式，BTREE 数据存储结构，MYSQL 存储数据的方式，还有LSM TREE 的方式一些新型的数据库采用这样的方式进行数据的存储。

这些存储结构会影响数据的提取的方式和性能。同时在存储数据的页面中，保留多少预留的空间为多次数据的变化做充足的准备，降低页分割的情况出现也是提高数据库性能的注意点。

综上所述，SQL运行的效率与很多因素都有关，并不是简单的添加索引提高性能那么简单，并且但从某一种方式去思维SQL 优化也并不是一件稳定或有确定性的工作。

前两期

POSTGRESQL SQL优化 重优化轻设计对不对与优化需要掌握的知识类别

https://mp.weixin.qq.com/s?__biz=Mzg4NDA0NTEwNA==&mid=2247494440&idx=1&sn=7eaf6a22b78f8229376fa8c4a3f48bc6&chksm=cfbc8f77f8cb0661a2db86558b347ee654a31284934cccd69cb3451968c3b4c47563d61802a7&token=160431904&lang=zh_CN#rd

postgresql SQL 优化 -- 理论与原理

https://mp.weixin.qq.com/s?__biz=Mzg4NDA0NTEwNA==&mid=2247494506&idx=1&sn=61dfd3d8a7ccaba32321bb2f5a61d665&chksm=cfbc8f35f8cb0623728dcef8dbb6c1dd46ad884e7f370dfd04e66117de779dce15c80b76a541&token=2088516272&lang=zh_CN#rd