查询表很快,查询相应的视图很慢为什么

查询表很快,查询相应的视图很慢为什么,第1张

表之间连接的字段创建联合索引了么?另外连接条件的先后顺序也很重要。那个连接条件可以过滤掉不符合条件的数据那个字段连接条件应该在最后。如果数据量比较大,而且对数据的实时性要求不高,那么建议用oracle的物化视图来做。物化视图是介于普通视图和表之间的一种oracle专有对象,物化视图会将查询的数据缓存起来,同时可以对物化视图进行修改、查询、删除和添加 *** 作。而且可以设置物化视图定时更新,但是定时的时间一定要大于数据查询的时间。

我们先来看第一个阶段,MySQL慢的诊断思路,一般我们会从三个方向来做:

第一个方向是MySQL内部的观测

第二个方向是外部资源的观测

第三个方向是外部需求的改造

1.1 MySQL 内部观测

我们来看MySQL内部的观测,常用的观测手段是这样的,从上往下看,第一部分是Processlist,看一下哪个SQL压力不太正常,第二步是explain,解释一下它的执行计划,第三步我们要做Profilling,如果这个SQL能再执行一次的话, 就做一个Profilling,然后高级的DBA会直接动用performance_schema ,MySQL 5.7 以后直接动用sys_schema,sys_schema是一个视图,里面有便捷的各类信息,帮助大家来诊断性能。再高级一点,我们会动用innodb_metrics进行一个对引擎的诊断。

除了这些手段以外,大家还提出了一些乱七八糟的手段,我就不列在这了,这些是常规的一个MySQL的内部的状态观测的思路。除了这些以外,MySQL还陆陆续续提供了一些暴露自己状态的方案,但是这些方案并没有在实践中形成套路,原因是学习成本比较高。

1.2 外部资源观测

外部资源观测这部分,我引用了一篇文章,这篇文章的二维码我贴在上面了。这篇文章是国外的一个神写的,标题是:60秒的快速巡检,我们来看一下它在60秒之内对服务器到底做了一个什么样的巡检。一共十条命令,这是前五条,我们一条一条来看。

1.uptime,uptime告诉我们这个机器活了多久,以及它的平均的负载是多少。

2.dmesg -T | tail,告诉我们系统日志里边有没有什么报错。

3.vmstat 1,告诉我们虚拟内存的状态,页的换进换出有没有问题,swap有没有使用。

4. mpstat -P ALL,告诉我们CPU压力在各个核上是不是均匀的。

5.pidstat 1,告诉我们各个进程的对资源的占用大概是什么样子。

我们来看一下后五条:

首先是iostat-xz 1,查看IO的问题,然后是free-m内存使用率,之后两个sar,按设备网卡设备的维度,看一下网络的消耗状态,以及总体看TCP的使用率和错误率是多少。最后一条命令top,看一下大概的进程和线程的问题。

这个就是对于外部资源的诊断,这十条命令揭示了应该去诊断哪些外部资源。

1.3 外部需求改造

第三个诊断思路是外部的需求改造,我在这里引用了一篇文档,这篇文档是MySQL的官方文档中的一章,这一章叫Examples of Common Queries,文档中介绍了常规的SQL怎么写, 给出了一些例子。文章的链接二维码在slide上。

我们来看一下它其中提到的一个例子。

它做的事情是从一个表里边去选取,这张表有三列,article、dealer、price,选取每个作者的最贵的商品列在结果集中,这是它的最原始的SQL,非常符合业务的写法,但是它是个关联子查询。

关联子查询成本是很贵的,所以上面的文档会教你快速地把它转成一个非关联子查询,大家可以看到中间的子查询和外边的查询之间是没有关联性的。

第三步,会教大家直接把子查询拿掉,然后转成这样一个SQL,这个就叫业务改造,前后三个SQL的成本都不一样,把关联子查询拆掉的成本,拆掉以后SQL会跑得非常好,但这个SQL已经不能良好表义了,只有在诊断到SQL成本比较高的情况下才建议大家使用这种方式。

为什么它能够把一个关联子查询拆掉呢?

这背后的原理是关系代数,所有的SQL都可以被表达成等价的关系代数式,关系代数式之间有等价关系,这个等价关系通过变换可以把关联子查询拆掉。

上面的这篇文档是一个大学的教材,它从头教了关于代数和SQL之间的关系。然后一步步推导怎么去简化这句SQL。

第一,MySQL本身提供了很多命令来观察MySQL自身的各类状态,大家从上往下检一般能检到SQL的问题或者服务器的问题。

第二,从服务器的角度,我们从巡检的脚本角度入手,服务器的资源就这几种,观测手法也就那么几种,我们把服务器的资源全部都观察一圈就可以了。

第三,如果实在搞不定,需求方一定要按照数据库容易接受的方式去写SQL,这个成本会下降的非常快,这个是常规的MySQL慢的诊断思路。

1.建立索引,尽可能把索引建立到你你经常比较的字段上,如select a,b,c,d from a where 索引字段=值,这个索引字段最好是数值型数据

2.慢有更多情况,

情况1:远程查询,其实可能查询不慢,由于数据量大,传输过程慢

情况2:WHERE 后面的比较数据太多,比如 like 类的语句

情况3:需要哪个字段只取那个字段就行了,比如select * from a与select b,c,d from a速度是有差距的

3.数据库定期维护,压缩,把不常用的数据备份后放入备份库里,查询时查备份库等

问题补充:

.第一条:建立索引,怎么建立,我也听说过,但不知道怎么使用

答:每种数据建立索引的方法有差异,比如SQL SERVER 2000中可对多个字段进行索引,比如SQL SERVER2000中有命令

CREATE INDEX

为给定表或视图创建索引。

只有表或视图的所有者才能为表创建索引。表或视图的所有者可以随时创建索引,无论表中是否有数据。可以通过指定限定的数据库名称,为另一个数据库中的表或视图创建索引。

语法

CREATE [ UNIQUE ] [ CLUSTERED | NONCLUSTERED ] INDEX index_name

ON { table | view } ( column [ ASC | DESC ] [ ,...n ] )

[ WITH <index_option >[ ,...n] ]

[ ON filegroup ]

<index_option >::=

{ PAD_INDEX |

FILLFACTOR = fillfactor |

IGNORE_DUP_KEY |

DROP_EXISTING |

STATISTICS_NORECOMPUTE |

SORT_IN_TEMPDB

}

第三条:数据库定期维护,压缩:怎么个压缩法?及时备份数据到备份库查询备份库,那查询时不是还慢吗?

答:这个有压缩工具,基本上每种数据库都有自己的压缩数据库的工具


欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/zaji/6187760.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023-03-17
下一篇 2023-03-17

发表评论

登录后才能评论

评论列表(0条)

保存