search 2013 adfgs

上一片介绍了 Oracle Sharding 介绍系列II(特性优势),这里再介绍一下 Oracle Sharding 与其他产品进行一下横向对比。

1、Oracle Sharding 与RAC

  • Oracle RAC和Active Data Guard的组合为OLTP和分析应用程序提供了透明的横向扩展和可用性,并且可以满足99 +%的用例需求。 使用Oracle RAC,所有事务可以对数据库中的任何数据起作用,没有必要分区数据或关注多分片操作的性能,所有RAC实例共享对同一物理数据库的直接访问。
  • Oracle Sharding牺牲了透明性,为定制设计的OLTP应用程序提供了巨大的可扩展性和高可用性。 使用Oracle Sharding,应用程序被设计为使更新事务对单个分片中的数据起作用。 跨越多个分片的事务不会受益于与单分片事务相同的性能和可伸缩性。

问:在什么场景下使用Oracle Sharding 而不是RAC

答:有以下两种情况:

  1. 当Oracle Enterprise Architect或客户决定Oracle RAC无法解决当前或未来的可扩展性和可用性要求时,Oracle Sharding会成为首选解决方案;
  2. 当应用程序被明确地设计用于分片数据库时。

注意,分片和Oracle RAC不是互斥的。分片可以使用Oracle RAC或RAC One节点代替复制HA。第一个版本的Oracle Sharding的唯一注意事项是RAC必须手动配置; Oracle Sharding不提供使用DEPLOY命令自动部署RAC配置,就像Data Guard / Active Data Guard和Oracle GoldenGate一样。正在考虑在将来的版本中自动部署RAC配置。

2、Oracle Sharding 与多租户 Oracle多租户是SaaS和其他数据库应用程序的整合解决方案;

Oracle Sharding是高容量OLTP系统的可扩展性和高可用性解决方案。 Oracle Multitenant支持用于SaaS应用程序的DBaaS以及私有、公共和开发/测试云。它提供了将数据库联合在一起成为逻辑数据库的基础设施,以实现对应用程序透明的所有数据的高性能查询。 Oracle Multitenant通过为Oracle数据库提供最高的整合密度以及将多个集成为一体的简单性,为降低资本和运营成本提供了独特的优势。 Oracle Sharding为定制设计的OLTP应用程序提供了巨大的可扩展性和高可用性。更新事务必须指定分片密钥,并对单个分片中的数据执行操作,以便受益于分片式数据库架构承诺的高性能和可用性。支持多分片操作或非分片键访问,但性能降低。这样的事务包括简单的聚合,报告等 – 理想地小于分片数据库的总工作负载的10%。

问:Oracle Sharding是否支持多租户?

答:Oracle Sharding(12.2.0.1)的初始版本不支持Oracle Multitenant。 计划在将来的版本中支持单租户容器数据库,支持多租户容器数据库。

问:有同时包含Oracle Sharding和多租户的场景案例吗?

答:有, 当提供对Oracle Multitenant的分区支持时,每个分片将是一个PDB,并且将受益于Multitenant提供任何其他PDB的敏捷性的相同优势。

示例包括:

  • 简单地通过从其当前CDB拔出并将其插入到更高版本的CDB中来简化多租户架构中的分片。
  • 迁移到Oracle Cloud和从Oracle Cloud迁移的简单性。 可以拔除作为PDB的内部部署分片,然后插入Oracle云。
  • 碎片的PDB克隆。

3、Oracle Sharding 与Oracle MAA

Oracle Sharding是Oracle MAA的自然演进,旨在解决针对定制开发的OLTP应用程序的大规模可扩展性和完全故障隔离的特殊用例。 适用于Oracle数据库的所有Oracle MAA原则也适用于包含SDB的各个分片。 将扩展Oracle MAA最佳实践,以解决SDB配置和管理的任何独特注意事项。

4、Oracle Sharding 如何与Oracle集成系统相关? Oracle Sharding是与大多数其他功能一样的硬件平台,属于Oracle MAA可扩展性和可用性解决方案的保护范围。 Oracle Sharding将受益于底层硬件平台提供的数据库工作负载的任何优势。 这意味着Oracle集成系统提供的数据库性能,可用性和可管理性的所有常见优点也会使在此类系统上运行的分片数据库受益。

 

承接上一篇文章Oracle Sharding 介绍系列I(什么是Oracle Sharding)

这里再介绍下 Oracle Sharding 更多的特性,为什么会受到如此多的关注

Oracle Sharding是响应客户对数据库架构的需求,可以提供线性可扩展性和完全故障隔离的组合,而无需共享存储或损害Oracle数据库的企业质量:严格的一致性,SQL的全部功能,开发人员敏捷性 具有JSON,安全性,高可用性,备份和恢复,生命周期管理等。

Oracle Sharding不仅仅将Oracle的企业质量扩展到分片式数据库架构, 并且通过使用自动化来简化生命周期管理,高级分区方法来解决各种各样的场景案例以及数据相关的路由,以实现卓越的运行时性能。 与竞争性分片解决方案或定制部署相比,这些功能为客户提供了显着的优势。

1、Oracle Sharding 在12.2版本中的新特性

Oracle 12.2在Sharding方面增加了许多新的优势:

  • 具有完全故障隔离的线性可扩展性。用于Oracle分区的OLTP应用程序可以在任何平台上弹性扩展(数据,事务和用户)到任何级别,只需在额外的独立服务器上部署新的分片。由于计划外中断或计划维护而导致的碎片不可用或减速只影响该碎片的用户,但不会影响其他碎片用户的应用程序的可用性或性能。每个分片可以运行不同版本的Oracle数据库,只要应用程序与最早运行的版本向后兼容即可 – 从而在执行数据库维护时轻松维护应用程序的可用性。
  • 全球数据分布,为消费者带来数据和数据主权,以满足数据隐私法规。
  • 多生命周期管理任务的自动化简化,这些任务包括:自动创建分片和复制,系统管理分区,单一命令部署和细粒度重新平衡。
  • 使用智能、数据相关的路由,实现卓越的运行时性能。
  • 在不牺牲企业RDBMS功能的情况下实现分片的所有优点。包括:关系模式,SQL和其他编程接口,复杂数据类型,在线模式更改,多核可扩展性,高级安全性,压缩,高可用性, ACID属性,一致性读取,开发人员与JSON的敏捷性等。

2、设计Oracle Sharding 的意义

Oracle Sharding使用用于部署和管理分片式数据库架构的全面解决方案来替代本地的分片方法。
Oracle分片提供了跨分片分布表分区的新自动化,自动部署分片式数据库,包括HA和数据保护的复制,高性能路由,负载平衡和完整的生命周期管理。

Oracle Sharding还针对分片用例显式优化了Oracle数据库经过时间验证的企业功能。 包括Oracle分区、Data Guard、Active Data Guard、GoldenGate、JDBC / OCI / ODP.NET连接池、DBCA、OEM、Oracle RAC等。

应用程序使用Oracle Sharding需要有哪些前提呢?

并非所有应用程序都可以利用分片数据库。 Oracle Sharding适用于为分片式数据库架构显式设计的OLTP应用程序。需满足以下条件:

  • 应用程序必须有一个明确定义的数据模型和数据分布策略(散列,范围,列表或复合),主要通过某个键访问数据。 密钥的示例包括客户ID,帐户号,country_id等。
  • 所有需要高性能的事务必须是单分片事务。 这些事务为高性能路由提供了一个分片键,通常访问10或100行。 例如,查找和更新客户的记帐记录,查找和更新订户的文档等
  • 支持多分片操作或非分片键访问,但性能会降低。 这种交易包括简单的聚合,报告等 – 通常小于总工作量的10%

这是关于 Oracle Sharding 方面系列文章的第一篇,从 Oracle 12.2 开始,不仅有多租户场景,多数据中心架构,还有云部署模型。下面就是关于 Oracle Sharding介绍系列第一篇,大部分内容来自 Oracle 文档。

这篇文站首先介绍下什么是 Oracle Sharding。

Oracle Sharding是Oracle数据库为在线交易类型的应用程序定制设计的一种可扩展、支持高可用功能的架构,可以在不具有共享硬件或软件的数据库池中分发和复制数据。 数据库池作为单个逻辑数据库展现给应用程序,应用程序通过在池中添加额外的数据库(分片),可以在任何平台上弹性扩展(数据,事务和用户)到任何级别, 使用Oracle数据库12.2.0.1的第一个版本支持扩展到1000个分片。

1、Oracle Sharding 的优点

与使用类似的可伸缩性方法的本地部署相比,Oracle Sharding提供了卓越的运行时性能和更简单的生命周期管理;还提供了企业DBMS的优势,包括:关系模式,SQL和其他编程接口,支持复杂数据类型,在线模式更改,多核可扩展性,高级安全性,压缩,高可用性,ACID属性,一致性 阅读,使用JSON的开发人员敏捷性等等。

Oracle分片使用水平分区在分片之间分布数据,通过分片分割数据库表,以便每个分片包含具有相同列但行的不同子集的表。

  • 从数据库管理员的角度来看,SDB由可以集中或单独管理的多个数据库组成。
  • 从应用程序开发人员的角度来看,SDB看起来像一个单一的数据库:分片的数量和跨越它们的数据的分布对数据库应用程序是完全透明的。 应用程序发出的SQL语句不引用分片,也不取决于分片数及其配置。

2、Oracle Sharding 的架构设计

OLTP应用程序必须从最初就设计好使用Sharding的架构方案,才能体现扩展性和可用性的优势。 因为者完全不同于基于Oracle RAC的高可用架构,RAC的实现对于应用程序来说是完全透明的。 但分片数据库的应用程序必须具有明确定义的数据模型和数据分发策略(一致的哈希,范围,列表或组合),主要通过分片键访问数据。 分片键的示例包括customer_id,account_no,country_id等。Oracle Sharding还支持数据放置策略(机架和地理位置感知)以及所有部署模型:内部部署模式和公共云或混合云。

有极高性能要求的事务必须是通常访问10行或100行的单分片事务。例如,查找和更新客户的记帐记录,查找和更新订户的文档等。在用于高性能事务的分片之间没有通信或协调。

当然还支持多分片操作和非分片键访问,但可能会对性能产生影响。这种交易包括简单的聚合,报告等 – 通常小于总工作量的10%。

3、Oracle Sharding 在高可用、可扩展性方面的实现

在上述的设计考虑的基础上,在分片数据库架构上运行的应用程序可以实现更高级别的可伸缩性和可用性。Sharding 数据库的性能会随着池中分片的增加而线性增长,因为每个分片之间是彼此独立的。每个分片通常使用本地存储、闪存和内存,为客户进行性能优化提供了相对低的成本。第一个版本的Oracle Sharding旨在扩展到1,000个分片。分片之间彼此独立意味着一个分片的中断或性能较差不会影响在其他分片上执行的事务的可用性或性能。

单个分片的高可用性(HA)由数据库复制的自动部署提供。默认配置是具有自动数据库故障转移的单向Data Guard物理复制,其实现起来非常简单。还可以自动部署Active Data Guard(复制打开只读)或Oracle GoldenGate(双向复制,所有副本均为打开读写)。碎片可以在数据中心内和跨数据中心进行复制,复制是使用Oracle Sharding支持的数据放置策略的数据中心和机架感知实现的,当然也可以手动配置Oracle RAC以提供Shard HA。

碎片是由一组称为Shard Director的复制侦听器作为路由器的前端。 Oracle客户端(JDBC,OCI和ODP.net)和Oracle通用连接池(UCP)已得到增强,可识别连接字符串中指定的分片键,并通过控制每个分片允许的最大连接数确保可用性。连接层中的分片路由缓存(由分片的初始请求填充)用于将请求直接路由到数据所在的分片,以实现最佳运行时性能。如果对分片数据库进行任何更改(例如自动重新平衡或添加/删除分片),则会自动刷新分片路由缓存。

接着上一篇 MySQL 数据库性能优化之SQL优化,这是 MySQL数据库性能优化专题 系列的第五篇文章:MySQL数据库性能优化之存储引擎选择

离上一篇文章已经有很长时间没有更新这个MySQL数据库性能优化专题了,时间太紧加上人之惰性,今天这里将之前就规划好的关于存储引擎选择方面的内容更新出来,希望对大家有所帮助吧

MySQL 的存储引擎可能是所有关系型数据库产品中最具有特色的了,不仅可以同时使用多种存储引擎,而且每种存储引擎和MySQL之间使用插件方式这种非常松的耦合关系。

由于各存储引擎功能特性差异较大,这篇文章主要是介绍如何来选择合适的存储引擎来应对不同的业务场景。

  • MyISAM
    • 特性
      1. 不支持事务:MyISAM存储引擎不支持事务,所以对事务有要求的业务场景不能使用
      2. 表级锁定:其锁定机制是表级索引,这虽然可以让锁定的实现成本很小但是也同时大大降低了其并发性能
      3. 读写互相阻塞:不仅会在写入的时候阻塞读取,MyISAM还会在读取的时候阻塞写入,但读本身并不会阻塞另外的读
      4. 只会缓存索引:MyISAM可以通过key_buffer缓存以大大提高访问性能减少磁盘IO,但是这个缓存区只会缓存索引,而不会缓存数据
    • 适用场景
      1. 不需要事务支持(不支持)
      2. 并发相对较低(锁定机制问题)
      3. 数据修改相对较少(阻塞问题)
      4. 以读为主
      5. 数据一致性要求不是非常高
    • 最佳实践
      1. 尽量索引(缓存机制)
      2. 调整读写优先级,根据实际需求确保重要操作更优先
      3. 启用延迟插入改善大批量写入性能
      4. 尽量顺序操作让insert数据都写入到尾部,减少阻塞
      5. 分解大的操作,降低单个操作的阻塞时间
      6. 降低并发数,某些高并发场景通过应用来进行排队机制
      7. 对于相对静态的数据,充分利用Query Cache可以极大的提高访问效率
      8. MyISAM的Count只有在全表扫描的时候特别高效,带有其他条件的count都需要进行实际的数据访问
  • InnoDB
    • 特性
      1. 具有较好的事务支持:支持4个事务隔离级别,支持多版本读
      2. 行级锁定:通过索引实现,全表扫描仍然会是表锁,注意间隙锁的影响
      3. 读写阻塞与事务隔离级别相关
      4. 具有非常高效的缓存特性:能缓存索引,也能缓存数据
      5. 整个表和主键以Cluster方式存储,组成一颗平衡树
      6. 所有Secondary Index都会保存主键信息
    • 适用场景
      1. 需要事务支持(具有较好的事务特性)
      2. 行级锁定对高并发有很好的适应能力,但需要确保查询是通过索引完成
      3. 数据更新较为频繁的场景
      4. 数据一致性要求较高
      5. 硬件设备内存较大,可以利用InnoDB较好的缓存能力来提高内存利用率,尽可能减少磁盘 IO
    • 最佳实践
      1. 主键尽可能小,避免给Secondary index带来过大的空间负担
      2. 避免全表扫描,因为会使用表锁
      3. 尽可能缓存所有的索引和数据,提高响应速度
      4. 在大批量小插入的时候,尽量自己控制事务而不要使用autocommit自动提交
      5. 合理设置innodb_flush_log_at_trx_commit参数值,不要过度追求安全性
      6. 避免主键更新,因为这会带来大量的数据移动
  • NDBCluster
    • 特性
      1. 分布式:分布式存储引擎,可以由多个NDBCluster存储引擎组成集群分别存放整体数据的一部分
      2. 支持事务:和Innodb一样,支持事务
      3. 可与mysqld不在一台主机:可以和mysqld分开存在于独立的主机上,然后通过网络和mysqld通信交互
      4. 内存需求量巨大:新版本索引以及被索引的数据必须存放在内存中,老版本所有数据和索引必须存在与内存中
    • 适用场景
      1. 具有非常高的并发需求
      2. 对单个请求的响应并不是非常的critical
      3. 查询简单,过滤条件较为固定,每次请求数据量较少,又不希望自己进行水平Sharding
    • 最佳实践
      1. 尽可能让查询简单,避免数据的跨节点传输
      2. 尽可能满足SQL节点的计算性能,大一点的集群SQL节点会明显多余Data节点
      3. 在各节点之间尽可能使用万兆网络环境互联,以减少数据在网络层传输过程中的延时

注:以上三个存储引擎是目前相对主流的存储引擎,还有其他类似如:Memory,Merge,CSV,Archive等存储引擎的使用场景都相对较少,这里就不一一分析了,如果有朋友感兴趣,后面再补充吧。

, , ,

接着上一篇 MySQL 数据库性能优化之索引优化,这是 MySQL数据库性能优化专题 系列的第四篇文章:MySQL 数据库性能优化之SQL优化

有人反馈之前几篇文章过于理论缺少实际操作细节,这篇文章就多一些可操作性的内容吧。

注:这篇文章是以 MySQL 为背景,很多内容同时适用于其他关系型数据库,需要有一些索引知识为基础

  • 优化目标
    1. 减少 IO 次数
      IO永远是数据库最容易瓶颈的地方,这是由数据库的职责所决定的,大部分数据库操作中超过90%的时间都是 IO 操作所占用的,减少 IO 次数是 SQL 优化中需要第一优先考虑,当然,也是收效最明显的优化手段。
    2. 降低 CPU 计算
      除了 IO 瓶颈之外,SQL优化中需要考虑的就是 CPU 运算量的优化了。order by, group by,distinct … 都是消耗 CPU 的大户(这些操作基本上都是 CPU 处理内存中的数据比较运算)。当我们的 IO 优化做到一定阶段之后,降低 CPU 计算也就成为了我们 SQL 优化的重要目标
  • 优化方法
    1. 改变 SQL 执行计划
      明确了优化目标之后,我们需要确定达到我们目标的方法。对于 SQL 语句来说,达到上述2个目标的方法其实只有一个,那就是改变 SQL 的执行计划,让他尽量“少走弯路”,尽量通过各种“捷径”来找到我们需要的数据,以达到 “减少 IO 次数” 和 “降低 CPU 计算” 的目标
  • 常见误区
    1. count(1)和count(primary_key) 优于 count(*)
      很多人为了统计记录条数,就使用 count(1) 和 count(primary_key) 而不是 count(*) ,他们认为这样性能更好,其实这是一个误区。对于有些场景,这样做可能性能会更差,应为数据库对 count(*) 计数操作做了一些特别的优化。
    2. count(column) 和 count(*) 是一样的
      这个误区甚至在很多的资深工程师或者是 DBA 中都普遍存在,很多人都会认为这是理所当然的。实际上,count(column) 和 count(*) 是一个完全不一样的操作,所代表的意义也完全不一样。
      count(column) 是表示结果集中有多少个column字段不为空的记录
      count(*) 是表示整个结果集有多少条记录
    3. select a,b from … 比 select a,b,c from … 可以让数据库访问更少的数据量
      这个误区主要存在于大量的开发人员中,主要原因是对数据库的存储原理不是太了解。
      实际上,大多数关系型数据库都是按照行(row)的方式存储,而数据存取操作都是以一个固定大小的IO单元(被称作 block 或者 page)为单位,一般为4KB,8KB… 大多数时候,每个IO单元中存储了多行,每行都是存储了该行的所有字段(lob等特殊类型字段除外)。
      所以,我们是取一个字段还是多个字段,实际上数据库在表中需要访问的数据量其实是一样的。
      当然,也有例外情况,那就是我们的这个查询在索引中就可以完成,也就是说当只取 a,b两个字段的时候,不需要回表,而c这个字段不在使用的索引中,需要回表取得其数据。在这样的情况下,二者的IO量会有较大差异。
    4. order by 一定需要排序操作
      我们知道索引数据实际上是有序的,如果我们的需要的数据和某个索引的顺序一致,而且我们的查询又通过这个索引来执行,那么数据库一般会省略排序操作,而直接将数据返回,因为数据库知道数据已经满足我们的排序需求了。
      实际上,利用索引来优化有排序需求的 SQL,是一个非常重要的优化手段
      延伸阅读:MySQL ORDER BY 的实现分析MySQL 中 GROUP BY 基本实现原理 以及 MySQL DISTINCT 的基本实现原理 这3篇文章中有更为深入的分析,尤其是第一篇
    5. 执行计划中有 filesort 就会进行磁盘文件排序
      有这个误区其实并不能怪我们,而是因为 MySQL 开发者在用词方面的问题。filesort 是我们在使用 explain 命令查看一条 SQL 的执行计划的时候可能会看到在 “Extra” 一列显示的信息。
      实际上,只要一条 SQL 语句需要进行排序操作,都会显示“Using filesort”,这并不表示就会有文件排序操作。
      延伸阅读:理解 MySQL Explain 命令输出中的filesort,我在这里有更为详细的介绍
  • 基本原则
    1. 尽量少 join
      MySQL 的优势在于简单,但这在某些方面其实也是其劣势。MySQL 优化器效率高,但是由于其统计信息的量有限,优化器工作过程出现偏差的可能性也就更多。对于复杂的多表 Join,一方面由于其优化器受限,再者在 Join 这方面所下的功夫还不够,所以性能表现离 Oracle 等关系型数据库前辈还是有一定距离。但如果是简单的单表查询,这一差距就会极小甚至在有些场景下要优于这些数据库前辈。
    2. 尽量少排序
      排序操作会消耗较多的 CPU 资源,所以减少排序可以在缓存命中率高等 IO 能力足够的场景下会较大影响 SQL 的响应时间。
      对于MySQL来说,减少排序有多种办法,比如:

      • 上面误区中提到的通过利用索引来排序的方式进行优化
      • 减少参与排序的记录条数
      • 非必要不对数据进行排序
    3. 尽量避免 select *
      很多人看到这一点后觉得比较难理解,上面不是在误区中刚刚说 select 子句中字段的多少并不会影响到读取的数据吗?
      是的,大多数时候并不会影响到 IO 量,但是当我们还存在 order by 操作的时候,select 子句中的字段多少会在很大程度上影响到我们的排序效率,这一点可以通过我之前一篇介绍 MySQL ORDER BY 的实现分析 的文章中有较为详细的介绍。
      此外,上面误区中不是也说了,只是大多数时候是不会影响到 IO 量,当我们的查询结果仅仅只需要在索引中就能找到的时候,还是会极大减少 IO 量的。
    4. 尽量用 join 代替子查询
      虽然 Join 性能并不佳,但是和 MySQL 的子查询比起来还是有非常大的性能优势。MySQL 的子查询执行计划一直存在较大的问题,虽然这个问题已经存在多年,但是到目前已经发布的所有稳定版本中都普遍存在,一直没有太大改善。虽然官方也在很早就承认这一问题,并且承诺尽快解决,但是至少到目前为止我们还没有看到哪一个版本较好的解决了这一问题。
    5. 尽量少 or
      当 where 子句中存在多个条件以“或”并存的时候,MySQL 的优化器并没有很好的解决其执行计划优化问题,再加上 MySQL 特有的 SQL 与 Storage 分层架构方式,造成了其性能比较低下,很多时候使用 union all 或者是union(必要的时候)的方式来代替“or”会得到更好的效果。
    6. 尽量用 union all 代替 union
      union 和 union all 的差异主要是前者需要将两个(或者多个)结果集合并后再进行唯一性过滤操作,这就会涉及到排序,增加大量的 CPU 运算,加大资源消耗及延迟。所以当我们可以确认不可能出现重复结果集或者不在乎重复结果集的时候,尽量使用 union all 而不是 union。
    7. 尽量早过滤
      这一优化策略其实最常见于索引的优化设计中(将过滤性更好的字段放得更靠前)。
      在 SQL 编写中同样可以使用这一原则来优化一些 Join 的 SQL。比如我们在多个表进行分页数据查询的时候,我们最好是能够在一个表上先过滤好数据分好页,然后再用分好页的结果集与另外的表 Join,这样可以尽可能多的减少不必要的 IO 操作,大大节省 IO 操作所消耗的时间。
    8. 避免类型转换
      这里所说的“类型转换”是指 where 子句中出现 column 字段的类型和传入的参数类型不一致的时候发生的类型转换:

      • 人为在column_name 上通过转换函数进行转换
        直接导致 MySQL(实际上其他数据库也会有同样的问题)无法使用索引,如果非要转换,应该在传入的参数上进行转换
      • 由数据库自己进行转换
        如果我们传入的数据类型和字段类型不一致,同时我们又没有做任何类型转换处理,MySQL 可能会自己对我们的数据进行类型转换操作,也可能不进行处理而交由存储引擎去处理,这样一来,就会出现索引无法使用的情况而造成执行计划问题。
    9. 优先优化高并发的 SQL,而不是执行频率低某些“大”SQL
      对于破坏性来说,高并发的 SQL 总是会比低频率的来得大,因为高并发的 SQL 一旦出现问题,甚至不会给我们任何喘息的机会就会将系统压跨。而对于一些虽然需要消耗大量 IO 而且响应很慢的 SQL,由于频率低,即使遇到,最多就是让整个系统响应慢一点,但至少可能撑一会儿,让我们有缓冲的机会。
    10. 从全局出发优化,而不是片面调整
      SQL 优化不能是单独针对某一个进行,而应充分考虑系统中所有的 SQL,尤其是在通过调整索引优化 SQL 的执行计划的时候,千万不能顾此失彼,因小失大。
    11. 尽可能对每一条运行在数据库中的SQL进行 explain
      优化 SQL,需要做到心中有数,知道 SQL 的执行计划才能判断是否有优化余地,才能判断是否存在执行计划问题。在对数据库中运行的 SQL 进行了一段时间的优化之后,很明显的问题 SQL 可能已经很少了,大多都需要去发掘,这时候就需要进行大量的 explain 操作收集执行计划,并判断是否需要进行优化。

, ,