这里写的是一个系列，这是系列的第三篇，这个系列主要是针对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 优化也并不是一件稳定或有确定性的工作。
前两期