mysql 视图 多表 性能_使用explain分析及优化由多表（三个以上）组成的视图性能...

视图如下图： create or replace view FLOW_SUBMITPROCESS_V as select pi.START_USER_ID_,pir.STARTUSERID,pi.PROC_INST_ID_,pir.PROCESSINSTID,pir.CURRENTTASKINSTID as TASKID,pir.PROCESSSTARTER as SUBMITUSERJSON_,ta.NAME_ from ACT_HI_TASKINST ta,

视图如下图：

create or replace view FLOW_SUBMITPROCESS_V as

select pi.START_USER_ID_,pir.STARTUSERID,pi.PROC_INST_ID_,pir.PROCESSINSTID,pir.CURRENTTASKINSTID as TASKID,pir.PROCESSSTARTER as SUBMITUSERJSON_,ta.NAME_

from ACT_HI_TASKINST ta,ACT_HI_PROCINST pi,FLOW_PROCESSINST_RELA pir

where ta.ID_=pir.CURRENTTASKINSTID and pi.PROC_INST_ID_=pir.PROCESSINSTID;

1、使用从表索引字段作为查询条件

用从表的一个字段作为查询条件(从表中的这个字段已经是索引字段)，从下图的效果可以看到，type中有一个ALL，全表检索，证明从表的索引字段对查询并没有帮助

将查询字段换成使用主表的StartUserID (这个字段是索引字段)

2、使用视图中与主表关联的字段查询的性能

下图，查询的字段与主表的主键PROCESSINSTID相关联，效率依然是有一个全表检索

使用主表的主键字段进行查询，则性能有所优化

总结：

1、建立多表(三个表或以上)关联视图时，如果是主表和副表都有的字段，尽量使用主表的字段(特别是主表的主键)

2、副表的字段(无论是普通字段还是主键、索引字段)作为查询条件对查询都没有帮助，都需进行全表检索

explain各个属性的含义

id

select查询的序列号

select_type

select查询的类型，主要是区别普通查询和联合查询、子查询之类的复杂查询。

table

输出的行出自哪张的表。

type

重要的性能指标，联合查询所使用的类型。

type显示的是访问类型，是较为重要的一个指标，结果值从好到坏依次是：

system > const > eq_ref > ref > fulltext > ref_or_null > index_merge > unique_subquery > index_subquery > range > index > ALL

System(表中仅有一行，即常量表)，

const(单表中最多有一个匹配行)，

eq_ref(对于前面的每一行,在此表中只查询一条记录)，

ref(使用普通的索引)，

ref_or_null(和ref类似，但是条件中包含对于NULL查询),

index_merge(索引合并优化),

unique_subquery(in的后面是一个查询主键字段的子查询),

index_subquery(类似unique_subquery，主要是in的后面是查询非唯一索引字段的子查询), range(单表中的范围查询),

index(对于当前的每一行，都通过查询索引来得到数据),

all(对于当前的每一行,都通过全表扫描来得到数据))

一般来说，得保证查询至少达到range级别，最好能达到ref。

possible_keys

指出MySQL能使用哪个索引在该表中找到行。如果是空的，没有相关的索引。这时要提高性能，可通过检验WHERE子句，看是否引用某些字段，或者检查字段不是适合索引。

key

显示MySQL实际决定使用的键。如果没有索引被选择，键是NULL。

key_len

显示MySQL决定使用的键长度。如果键是NULL，长度就是NULL。文档提示特别注意这个值可以得出一个多重主键里mysql实际使用了哪一部分。

ref

显示哪个字段或常数与key一起被使用。

rows

这个数表示mysql要遍历多少数据才能找到，在innodb上是不准确的。

Extra

Distinct 一旦MYSQL找到了与行相联合匹配的行，就不再搜索了

Not exists MYSQL优化了LEFT JOIN，一旦它找到了匹配LEFT JOIN标准的行，就不再搜索了

Range checked for eachRecord(index map:#)没有找到理想的索引，因此对于从前面表中来的每一个行组合，MYSQL检查使用哪个索引，并用它来从表中返回行。这是使用索引的最慢的连接之一

Using filesort 看到这个的时候，查询就需要优化了。MYSQL需要进行额外的步骤来发现如何对返回的行排序。它根据连接类型以及存储排序键值和匹配条件的全部行的行指针来排序全部行

Using index 列数据是从仅仅使用了索引中的信息而没有读取实际的行动的表返回的，这发生在对表的全部的请求列都是同一个索引的部分的时候

Using temporary 看到这个的时候，查询需要优化了。这里，MYSQL需要创建一个临时表来存储结果，这通常发生在对不同的列集进行ORDER BY上，而不是GROUP BY上

Using Where 使用了WHERE从句来限制哪些行将与下一张表匹配或者是返回给用户。如果不想返回表中的全部行，并且连接类型ALL或index，这就会发生，或者是查询有问题

如果此信息显示Using filesort或者Using temporary的话会很吃力，WHERE和ORDER BY的索引经常无法兼顾，如果按照WHERE来确定索引，那么在ORDER BY时，就必然会引起Using filesort，这就要看是先过滤再排序划算，还是先排序再过滤划算。

本文原创发布php中文网，转载请注明出处，感谢您的尊重！