mysql 表记录超过十万条后,查询速度特别慢?
Posted
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了mysql 表记录超过十万条后,查询速度特别慢?相关的知识,希望对你有一定的参考价值。
在mysql数据库中。我有一个表。他里面的记录数已经有二十多万条了。查我在里面查询的时候速度特别慢。我把里面的记录删了二十万以。速度就很快了。有没有什么办法。在不删除记录的情况下。让他快起来?
参考技术A 是不是考虑在你要查询的列上建立个索引,20万数据按照目前主流机器的配置来说应该不会很慢的,看看你的my.ini的配置使用的内存等资源是不是太少了 参考技术B 建立常用字段的索引,优化查询语句,尽量少使用长字符串的比较,多利用数字类型的字段,比如id、价格之类的。 参考技术C 优化查询语句吧,比如说在模糊查找时尽量不要用“%keyword%”这种前面有%的形式,这样数据库就要对每条记录进行比对 参考技术D 即使你做优化也是没法避免这种问题的,因为你记录了之后查找时的记录集也大了,话的时间肯定要变长mysql查询速度慢
sql如下,要8秒钟,哪位能改写或者是优化mysql的设置
select * from interrelated i,userbaseinfo u, resoucetongjiinfo r,restype re ,restyperecord res
where
re.typecode=03
and re.typeid= res.typeid
and i.id= res.OBJID
and u.userid=i.userid
and r.resourceid=i.id
order by i.time
limit 0,4
我们先来看第一个阶段,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慢的诊断思路。
from interrelated i,
userbaseinfo u,
resoucetongjiinfo r,
restype re,
restyperecord res
where re.typeid = res.typeid
and i.id = res.OBJID
and u.userid = i.userid
and r.resourceid = i.id
and re.typecode = 03
order by i.time limit 0, 4
好像没啥好办法本回答被提问者采纳 参考技术B SELECT *本身就慢,
还有,如果数据量大,就不要一次性提取,那不合理。
凡是提取出来的数据,填充到缓存里,这样以后检索重复数据的时候,
就不需要再次让数据库引擎执行查询,而是直接从内存中提取。 参考技术C 建索引 参考技术D 哇。。。。5表查询
太霸道了
以上是关于mysql 表记录超过十万条后,查询速度特别慢?的主要内容,如果未能解决你的问题,请参考以下文章