位置: 编程技术 - 正文

MySQL的一条慢SQL查询导致整个网站宕机的解决方法(mysql join 慢)

编辑:rootadmin

推荐整理分享MySQL的一条慢SQL查询导致整个网站宕机的解决方法(mysql join 慢),希望有所帮助,仅作参考,欢迎阅读内容。

文章相关热门搜索词:mysql in慢,mysql开启慢sql,mysql join 慢,mysql 速度慢,mysql in慢,mysql一条数据在多少kb,mysql慢sql优化五个原则,mysql慢sql优化五个原则,内容如对您有帮助,希望把文章链接给更多的朋友!

直接切入正题吧:

通常来说,我们看到的慢查询一般还不致于导致挂站,顶多就是应用响应变慢不过这个恰好今天被我撞见了,一个慢查询把整个网站搞挂了先看看这个SQL张撒样子:

# Query_time: . Lock_time: 0. Rows_sent: Rows_examined: Rows_affected: 0# Bytes_sent: use js_sku;SET timestamp=;SELECT ss_id, ss_sa_id, ss_si_id, ss_av_zid, ss_av_fid, ss_artno,ss_av_zvalue, ss_av_fvalue, ss_av_zpic, ss_av_fpic, ss_number,ss_sales, ss_cprice, ss_price, ss_stock, ss_orderid, ss_status,ss_add_time, ss_lastmodifyFROM js_sgoods_skuWHERE ss_si_id = 0 AND ss_status > 0ORDER BYss_orderid DESC, ss_av_fid ASC;这里贴出来的就是 mysql slow log 的信息,查询时间用了高达 s!!看到慢查询我们一般第一反应是这个 语句没有用到索引? 或者是索引不合理么? 那我们会去看看执行计划:

mysql> explain SELECT -> ss_id, ss_sa_id, ss_si_id, ss_av_zid, ss_av_fid, ss_artno,-> ss_av_zvalue, ss_av_fvalue, ss_av_zpic, ss_av_fpic, ss_number,-> ss_sales, ss_cprice, ss_price, ss_stock, ss_orderid, ss_status,-> ss_add_time, ss_lastmodify-> FROM js_sgoods_sku-> WHERE ss_si_id = 0 AND ss_status > 0-> ORDER BY-> ss_orderid DESC, ss_av_fid ASC;+----+-------------+---------------+------+---------------+----------+---------+-------+---------+-----------------------------+| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |+----+-------------+---------------+------+---------------+----------+---------+-------+---------+-----------------------------+| 1 | SIMPLE | js_sgoods_sku | ref | ss_si_id | ss_si_id | 4 | const | | Using where; Using filesort |+----+-------------+---------------+------+---------------+----------+---------+-------+---------+-----------------------------+1 row in set (0. sec)

这个看起来似乎用到了索引,可是为什么扫描到行还是这么多呢? 那我们就去看看表结构了,期望能从中找到点有价值的东西:我们看到如下可用信息:KEY `ss_si_id` (`ss_si_id`,`ss_av_zid`,`ss_av_fid`) USING BTREE,`ss_si_id` int() unsigned NOT NULL DEFAULT '0' COMMENT '对应js_sgoods_info.si_id',

我们看到 索引似乎还能比较能够接受,但是我们看到 这个 ss_si_id 这个字段实际上是 goods_info 表的主键,也就是说它的离散程度应该是很大的,也就是区分度很大。其实到这一步我们基本上可以认为 是由于我们这个表里边有很多 ss_si_id=0 导致,不过我们可以进一步的来证实我们的猜想:

1. 首先我们可以先确定我们的统计信息没有问题2. 其次我们再count ss_si_id=0 的这个值有多少数据,来进一步验证我们的猜想。

那么我们先查看以下这个索引的统计信息:xiean@localhost:js_sku ::>show index from js_sgoods_sku;+---------------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+| Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | Index_comment |+---------------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+| js_sgoods_sku | 0 | PRIMARY | 1 | ss_id | A | | NULL | NULL | | BTREE | | || js_sgoods_sku | 1 | ss_si_id | 1 | ss_si_id | A | | NULL | NULL | | BTREE | | || js_sgoods_sku | 1 | ss_si_id | 2 | ss_av_zid | A | | NULL | NULL | | BTREE | | || js_sgoods_sku | 1 | ss_si_id | 3 | ss_av_fid | A | | NULL | NULL | | BTREE | | || js_sgoods_sku | 1 | IDX_ | 1 | ss_sa_id | A | | NULL | NULL | | BTREE | | |+---------------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+

那么可以看到以下问题:我们的ss_si_id 这个字段并没有我们表面上看到的 因为关联了某个表的主键,它的Cardinality 值就应该接近于 PRIMARY 的值。而是差别比较大的,难道是 索引的统计信息不准确? 那我们尝试重新收集下索引的统计信息:xiean@localhost:js_sku ::>analyze table js_sgoods_sku;+----------------------+---------+----------+----------+| Table | Op | Msg_type | Msg_text |+----------------------+---------+----------+----------+| js_sku.js_sgoods_sku | analyze | status | OK |+----------------------+---------+----------+----------+

but ,我们再次查看 这些索引的统计信息:xiean@localhost:js_sku ::>show index from js_sgoods_sku;+---------------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+| Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | Index_comment |+---------------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+| js_sgoods_sku | 0 | PRIMARY | 1 | ss_id | A | | NULL | NULL | | BTREE | | || js_sgoods_sku | 1 | ss_si_id | 1 | ss_si_id | A | | NULL | NULL | | BTREE | | || js_sgoods_sku | 1 | ss_si_id | 2 | ss_av_zid | A | | NULL | NULL | | BTREE | | || js_sgoods_sku | 1 | ss_si_id | 3 | ss_av_fid | A | | NULL | NULL | | BTREE | | || js_sgoods_sku | 1 | IDX_ | 1 | ss_sa_id | A | | NULL | NULL | | BTREE | | |+---------------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+

我们可以看到 ss_si_id 的离散程度(Cardinality) 没有增加反而有向下波动的趋势,因为这个信息是采集部分页的来的,而每个页上边数据分布是不一样的,导致我们这个索引收集的统计信息就回有所变化。

MySQL的一条慢SQL查询导致整个网站宕机的解决方法(mysql join 慢)

好吧,到这里我们可以认为我们的 统计信息没有失效,那么我们就看数据的分别情况咯:

+--------------++----------++------------------+| ss_si_id=0; || count(*) || / |+--------------++----------++------------------+| || || 0. |+--------------++----------++------------------+

额,不看不知道,一看吓一跳:我们这个表里边 存在有大量的 ss_si_id=0 的情况,占了整个表数据量的 % !!!

好吧问题找到了,那么接下来我们需要知道,为什么这个SQL语句会导致挂站呢?

我们通过观看应用程序服务器的监控看到一些信息:我们的 goods_service 这个服务异常:异常情况如下:

1. cpu 长期占用% + 2. jstatck pid 无法dump 内存堆栈信息,必须强制dump -F3. dump 出来的内存信息发现,这个进程里边所有线程 均处于 BLOCKED 状态4. 通过jstat -gcutil 看到 FGC 相当频繁,s左右就FGC一次5. 内存占用超过了分配的内存

那么最终的原因就是因为上边的慢查询 查询了大量数据(最多有w行数据),导致goods_service 内存暴涨,出现服务无法响应,进一步的恶化就是挂占

OK,知道了为什么会挂占,那么我们是如何解决这个问题的呢?既然我们知道是由于查询了 ss_si_id=0 导致的,那么我们屏蔽掉这个SQL不就好了么。屏蔽的办法可以有多种:1. 我们程序逻辑判断一下这类型的 查询 如果 有查询 ss_si_id=0 的一律封杀掉2. 我们改改SQL配置文件,修改SQL语句

我们发现DB服务器上存在大量的 这个慢查询,而且DB服务器负载已经从 0.xx 飙升到了 + 了,随之而来的连接数也飙升的厉害, 如果再不及时处理,估计DB服务器也挂掉了

那么我们最终采取以下处理办法:1.运维配合研发修改SQL语句 我们在这个WHERE 条件中添加了一个条件: AND ss_si_id <> 0 ,在MySQL之行计划层屏蔽掉此SQL;2.DBA 开启kill 掉这个查询语句,避免DB服务器出现down机的情况,当然这个就用到了我们的 pt-kill 工具,不得不说这个工具相当好用

总结(经验与教训):1.类似这种查询 default 值的 SQL ,我们应该从源头上杜绝这类查询2.限制查询结果集大小,避免因查询结果集太大导致服务死掉

MySQL复制出错 Last_SQL_Errno:的解决方法 背景:我们在做数据迁移或者拆分的时候,使用Tablespacetranscation这种解决方案时,很有可能就会遇到从库复制出错,报:Last_SQL_Errno:那么具体错误内

MySQL 常见数据拆分办法 在生产环境中,由于业务的增长或者业务的拆分,DBA经常需要拆库操作。那么我们常见的拆库手段有哪些呢?我这里提供几种解决办法:1.使用mysqldump把

MYSQL数据库数据拆分之分库分表总结 数据存储演进思路一:单库单表单库单表是最常见的数据库设计,例如,有一张用户(user)表放在数据库db中,所有的用户都可以在db库中的user表中查到。

标签: mysql join 慢

本文链接地址:https://www.jiuchutong.com/biancheng/347916.html 转载请保留说明!

上一篇:mysql数据库 主从复制的配置方法(mysql数据库主从数据不一致)

下一篇:MySQL复制出错 Last_SQL_Errno:1146的解决方法(mysql复制命令)

  • 增值税申报可以作废几次
  • 小规模纳税人开专票税率是1%还是3%
  • 委托外单位研发的研发费用加计扣除最新政策
  • 银企对账如何操作
  • 财务报表中负债率怎么算
  • 其它综合收益影响因素
  • 信用评估费用收费标准
  • 企业所得税中管理费用怎么填列
  • 增值税缴纳的罚款怎么算
  • 怎么计算收益率
  • 股东向公司借款需要股东会决议吗
  • 企业认购普通股100万股作为交易性金融资产管理
  • 社会保险与个人养老金的区别
  • 减免附加税还要计提吗
  • 劳务费发票可以含材料费吗
  • 房地产土地抵扣
  • 专票作废流程是什么意思
  • 自建房屋没有发票如何入账
  • t3不能增加二级科目
  • 升级设备属于什么科目
  • 公账的钱如何合法取出会计
  • 增值税年末结转是结转全年吗
  • mac老款设备怎样升级os14
  • 个体工商户需要年审吗
  • 开启自动备份注册表
  • 事业单位收到拨入的工资怎么做账
  • 坏账准备的方法
  • 保险中介市场现状和基本特点
  • 房地产公司土地在资产负债表列入
  • 烟草带来的损失
  • 开办费的具体内容有哪些
  • php echo js
  • 面试官:一千万是真的吗
  • 达摩院 2021
  • Stable Diffusion - API和微服务开发
  • js检查json是否合法
  • uniapp中uni.navigateTo传递变量
  • 利润表所得税费用怎么算
  • 再生资源增值税退税优惠政策
  • 商业银行贷款业务按担保形式分,可分为( )
  • vue+elementui
  • python的基本风格
  • 法人转钱入公户要交税吗
  • 停车费定额发票有效期是多久
  • 财政监制章专用收据可以税前扣除吗
  • 小微企业0税务报税流程
  • 申报缴纳上月税费的会计分录
  • 开发成本的会计科目编码
  • 嵌入式软件产品应纳税额
  • 事业单位公务卡额度多少
  • 未使用的固定资产计提折旧计入什么科目
  • 缴纳上月附加税怎么做分录
  • 报销餐费属于什么费用
  • 发票超过定额了怎么处理
  • 核定征收方式的小型微利企业可以享受
  • 营改增后工程项目计价规则也随之发生了改变对还是错
  • 银行日记账年底是0第二年年初怎么写
  • 交易性金融资产公允价值变动计入
  • mysql的密码忘了该怎么办
  • win8系统gho
  • liunx系统常用命令
  • 如何在安装未知应用中修改权限
  • win7系统桌面设置
  • CentOS救援模式实验笔记详解
  • linux 桌面系统
  • cmd指令让电脑乱码
  • win7中文显示问号
  • Manjaro Linux 0.8.13发布下载 可将系统装入SD卡
  • 用dos杀毒的一个软件
  • tf-idf例题
  • unity3d快捷键
  • python程序讲解
  • unity官方插件
  • javascript面向对象编程指南
  • 个人取得抽奖,购车抵用,需要缴纳个人所得税吗
  • 城建税教育费附加怎么做分录
  • 国家税务网上办税服务厅官网
  • 电子税务网没开通怎么办
  • 武汉市江岸区工商局咨询电话
  • 深圳机打发票查询
  • 免责声明:网站部分图片文字素材来源于网络,如有侵权,请及时告知,我们会第一时间删除,谢谢! 邮箱:opceo@qq.com

    鄂ICP备2023003026号

    网站地图: 企业信息 工商信息 财税知识 网络常识 编程技术

    友情链接: 武汉网站建设