视图查询优化 |
您所在的位置：网站首页 › 查询sql语句优化怎么写 › 视图查询优化 |
视图查询优化
|
最近接到一个数据库优化的任务，生产环境中一个数据库视图查询，开始还挺快，但是随着数据越来越多，查询时间越来越长。 经过梳理，已知信息如下： 1. 数据库是MySQL； 2. 视图 SQL 语句； SELECT `rycrjl`.`EDM` AS `UID`, `ryxx`.`DM` AS `DM`, `ryxx`.`XM` AS `XM`, `ryxx`.`RYLB` AS `LB`, `rycrjl`.`JCLX` AS `LX`, `zjxx`.`MC` AS `ZJMC`, `zjxx`.`BKDW` AS `LDMC`, `rycrjl`.`TGSJ` AS `SJ`, `zjxx`.`MC` AS `DD` FROM (( `t_rycrjl` `rycrjl` LEFT JOIN `t_ryxx` `ryxx` ON (( `rycrjl`.`PNO` = `ryxx`.`PNO` ))) LEFT JOIN `t_zjxx` `zjxx` ON (( `rycrjl`.`ZJDM` = `zjxx`.`DM` )))试一下视图查询
这... 5000 条数据竟然需要 10 秒+ ！！！ 优化过程 1、查看视图执行计划。
2、分析执行计划，rows 表示每条记录查询基础表会被分别检索20566和104次，而且随着基础表数据增长而增长。这就导致查询非常耗时。 我们再看下 type 访问类型，all 表示遍历全表匹配。 补充下 TYPE ，执行效率优秀至垃圾依次顺序： system > const > eq_ref > ref > fulltext > ref_or_null > index_merge > unique_subquery > index_subquery > range > index > All常见访问类型：system > const > eq_ref > ref > range > index > All 类型 说明 system 表只有一行记录（等于系统表），这是const类型的特例，平时不会出现，这个也可以忽略不计。 const 表示通过索引一次就找到了，const用于比较primary key或则unique索引。因为只匹配一行数据，所以很快。如将主键置于where列表中，MySQL就能将该查询转换为一个常量。 eq_ref 唯一性索引扫描，对于每个索引键，表中只有一条记录与之匹配。常见于主键或唯一索引扫描。 ref 非唯一性索引扫描，返回匹配某个单独值的所有行。本质上也是一种索引访问，它返回所有匹配某个单独值的行，然而，它可能会找到多个符合条件的行，所以它应该属于查找和扫描的混合体。 range 只检索给定范围的行，使用一个索引来选择行。key列显示使用了哪个索引。一般就是在你的where语句中出现了between、、in等的查询。这种范围扫描索引扫描比全表扫描要好，因为它只需要开始于索引的某一点，而结束于另一点，不会扫描全部索引。 index Full Index Scan，index与All区别为index类型只遍历索引树。这通常比All快，因为索引文件通常比数据文件小。（也就是说虽然all和index都是读全表，但index是从索引中读取的，而all是从硬盘中读的） all Full Table Scan，将遍历全表以找到匹配的行。问题找到了，那就开始优化。 3、给基础表添加索引，分别给 t_zjxx 字段 DM 和 t_ryxx 字段 PNO 添加索引。
再次查看执行计划，发现基础表每次只索引1条记录。 最后试一试视图查询，效果很明显！
本文来自博客园，作者：七月的枫丶 ，部分内容摘自互联网，转载请注明原文链接：https://www.cnblogs.com/easybook/p/16348386.html |
【本文地址】
今日新闻 |
推荐新闻 |