[zz]sql优化相关

Posted 2020-06-14

源地址：http://www.cnblogs.com/xuxiaoshuan/p/3831481.

了解优化前需要知道以下内容：

1 sql语法

2 sql操作执行顺序

3 数据库管理系统的查询优化器采用的优化方法

 4元操作：1数据的查找基本操作是 表扫描（table scan）， 2索引直接获取(index seek)  当然所以是建立在排序上的，如果索引的字段大部分都是重复值，那么索引效果也不会太3

Bookmark Lookup

 

限制性规则：

1 不要超过5个表以上的链接

2 视图嵌套不要超过2个

 

具体要点：

1 select 时，选择所需的列，而不是 select * . 原因： sql的执行过程是解析器，预处理器，优化器，查询执行引擎，存储过程。 如果是select * ,会导致优化器无法完成覆盖索引；返回内容的容量增加，会增加网络传输的开销 和IO的开销。

 

2 连接多个表时，列名前添加表名。 原因：这样可以减少字段解析的时间，并杜绝了以后扩展造成的歧义。

 

3 合理写 where子句。原因： 在join之后的一步就是where,如果在流水线的前期就尽量裁剪数据量，必定事半功倍。

 

4 减少数据转换，从表格设计方面杜绝。

 

5 使用临时表 和 表变量 避免 语句的复杂性。在一些情况下数据库会自动使用临时表

 

6in exists 是双层循环，IN适合于外表大而内表小的情况；EXISTS适合于外表小而内表大的情况。原因：区别在于 in时会有一个数值的相等检测，而这个检测可以用到外表的索引；而内表需要一个全表排序，所以不能太大。 exists时，是对外表进行表扫描，判断是否在内表中，此时内表可以走索引。

 

 

7 尽量避免对数据字段部分进行运算。原因：这样可以使用索引。

 

8 将OLAP OLTP模块分开。前者是联机分析处理，往往需要扫描整个表；后者是联机事务处理，往往只关系部分数据。

 

9 使用存储过程。原因：可以被缓存，

 

10 使用索引：单字段 组合 和 覆盖索引 。原因：前2者可以将表扫描变为索引获取，后者可以避免对表访问的Lookup过程。

 

11尽量避免在where子句中使用 != 原因： 不等会让引擎进行table scan

 

12 尽量使用Union 替代 or  原因： or会让引擎进行table scan。还有一个解释是 uniton的条件中比较对象的type是一个确定的类型，但是Or却是模糊的。

 

13  explain 分析 具体情况时根据结果修正

 14 数据库类型的选择是否合适（架构层次）：

 

关系型数据库的最大特点就是事务的一致性：传统的关系型数据库读写操作都是事务的，具有ACID的特点，这个特性使得关系型数据库可以用于几乎所有对一致性有要求的系统中，如典型的银行系统。

但是，在网页应用中，尤其是SNS应用中，一致性却不是显得那么重要，用户A看到的内容和用户B看到同一用户C内容更新不一致是可以容忍的，或者说，两个人看到同一好友的数据更新的时间差那么几秒是可以容忍的，因此，关系型数据库的最大特点在这里已经无用武之地，起码不是那么重要了。

面向高性能并发读写的key-value数据库：

key-value数据库的主要特点即使具有极高的并发读写性能，Redis,Tokyo Cabinet,Flare就是这类的代表

面向海量数据访问的面向文档数据库：

这类数据库的特点是，可以在海量的数据中快速的查询数据，典型代表为MongoDB以及CouchDB

面向可扩展性的分布式数据库：

这类数据库想解决的问题就是传统数据库存在可扩展性上的缺陷，这类数据库可以适应数据量的增加以及数据结构的变化。