mysql从库应用负载_线上MySQL数据库高负载的解决思路--再次论程序应用索引的重要性...
前言：过去的笔记整理而得，未免丢失，发布个人博客。[2012年的资料笔记]
场景：数据库的负载飙升，CPU高达99%。
查看进程。通过猜测推理，定位了一些select语句
363478427 | apps_read | 192.168.1.113:48945 | apps | Query | 1 | Sending data | select * from category_doc_info
where (doc_title = '???') |
| 363478430 | apps_read | 192.168.1.113:48948 | apps | Query | 1 | Sending data | select * from category_doc_info
where (doc_title = '??????') |
| 363478434 | apps_read | 192.168.1.113:48952 | apps | Query | 1 | Sending data | select * from category_doc_info
where (doc_title = '?????????') |
| 363478437 | apps_read | 192.168.1.113:48955 | apps | Query | 1 | Sending data | select * from category_doc_info
where (doc_title = '????????') |
| 363478462 | apps_read | 192.168.1.113:48957 | apps | Query | 1 | Sending data | select * from category_doc_info
where (doc_title = '???????') |
| 363478500 | apps_read | 192.168.1.113:48960 | apps | Query | 1 | Sending data | select * from category_doc_info
where (doc_title = '????') |
| 363478511 | apps_read | 192.168.1.113:48963 | apps | Query | 0 | Sending data | select * from category_doc_info
where (doc_title = '??????') |
| 363478518 | apps_read | 192.168.1.113:48964 | apps | Query | 1 | Sending data | select * from category_doc_info
where (doc_title = 'T2??') |
| 363478535 | apps_read | 192.168.1.113:48965 | apps | Query | 0 | Sending data | select * from category_doc_info
where (doc_title = '???') |
| 363478540 | apps_read | 192.168.1.113:48968 | apps | Query | 1 | Sending data | select * from category_doc_info
where (doc_title = '??') |
| 363478613 | apps_read | 192.168.1.113:48971 | apps | Query | 0 | Sending data | select * from category_doc_info
where (doc_title = '???') |
| 363478630 | apps_read | 192.168.1.113:48975 | apps | Query | 0 | Sending data | select *
查看此表的数据库表结构如下：
---------------------------------------------------------------------------------------------------------------------------------------------------------
| category_doc_info | CREATE TABLE `category_doc_info` (
`id` int(10) unsigned NOT NULL auto_increment,
`category_id` int(10) unsigned NOT NULL COMMENT
`doc_title` varchar(255) NOT NULL COMMENT
`category_show` tinyint(1) unsigned NOT NULL COMMENT
`category_Coordinate` tinyint(1) unsigned NOT NULL default '2'
`category_order` tinyint(1) unsigned NOT NULL default '0'
PRIMARY KEY (`id`),
UNIQUE KEY `INDEX_SEARCH` (`category_id`,`doc_title`),
) ENGINE=InnoDB AUTO_INCREMENT=343502 DEFAULT CHARSET=utf8 |
---------------------------------------------------------------------------------------------------------------------------------------------------------
发现只有一个组合索引。但是完全没有用到。
现实场景：都是where (doc_title = '???') 的语句
查看具体的一条SQL语句的执行计划，如下:
mysql> explain select * from category_doc_info where (doc_title = '独出新裁');
+----+-------------+-------------------+------+---------------+------+---------+------+--------+-------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+-------------------+------+---------------+------+---------+------+--------+-------------+
| 1 | SIMPLE | category_doc_info | ALL | NULL | NULL | NULL | NULL | 232717| Using where |
+----+-------------+-------------------+------+---------------+------+---------+------+--------+-------------+
可以发现都是全表查询，并且是高并发的访问上述语句。
经过分析，修改生产环境的表结构，如下:
| category_doc_info | CREATE TABLE `category_doc_info` (
`id` int(10) unsigned NOT NULL auto_increment,
`category_id` int(10) unsigned NOT NULL,
`doc_title` varchar(255) NOT NULL',
`category_show` tinyint(1) unsigned NOT NULL,
`category_Coordinate` tinyint(1) unsigned NOT NULL default '2',
`category_order` tinyint(1) unsigned NOT NULL default '0',
PRIMARY KEY (`id`),
UNIQUE KEY `INDEX_SEARCH` (`category_id`,`doc_title`),
KEY `idx_category_title` (`doc_title`) //新添加的表索引
) ENGINE=InnoDB AUTO_INCREMENT=343502 DEFAULT CHARSET=utf8 |
让上述的程序应用走索引，数据库的负载恢复正常，性能恢复正常。
mysql从库应用负载_线上MySQL数据库高负载的解决思路--再次论程序应用索引的重要性...相关推荐
- mysql爆内存_线上MySQL数据库机器内存爆掉原因分析与解决
本文主要向大家介绍了线上MySQL数据库机器内存爆掉原因分析与解决,通过具体的内容向大家展现,希望对大家学习MySQL数据库有所帮助. 现象: 阿里金融某业务的MySQL机器的内存每隔几天就会增长,涨 ...
- mysql内存爆_线上MySQL机器内存爆掉原因分析与解决
现象: 阿里金融某业务的MySQL机器的内存每隔几天就会增长,涨上去后,却不下来.累积后内存爆掉. 分析: 此业务是间隔的对MySQL有大访问,其它时间几乎无访问.排查发现,内存涨时,一般会有MySQ ...
- MySQL线上优化_线上MySQL千万级大表，如何优化？
前段时间应急群有客服反馈,会员管理功能无法按到店时间.到店次数.消费金额进行排序.经过排查发现是 SQL 执行效率低,并且索引效率低下. 图片来自 Pexels 应急问题 商户反馈会员管理功能无法按到 ...
- mysql 测试快生产慢_生产上MySQL慢查询优化实战，SQL优化实战
之前看了饿了么团队写的一篇博客:等等!这两个 Spring-RabbitMQ 的坑我们已经替你踩了.深受启发,一定要取个能吸引读者眼球的标题,当然除了响当当的标题以外,内容也要是干货.为什么会想取这样 ...
- window服务器cpu过高的排查_服务器CPU使用率过高排查与解决思路
发现服务器的cpu使用率特别高 排查思路: -使用top或者mpstat查看cpu的使用情况 mpstat -P ALL 2 1 Linux 2.6.32-358.el6.x86_64 (linux- ...
- mysql 同步失败_线上MYSQL同步报错故障处理方法总结
前言 在发生故障切换后,经常遇到的问题就是同步报错,下面是最近收集的报错信息. 记录删除失败 在master上删除一条记录,而slave上找不到 Last_SQL_Error: Could not e ...
- java mysql死锁_记一次线上mysql死锁分析(一)
记录一次比较诡异的mysql死锁日志.系统运行几个月来,就在前几天发生了一次死锁,而且就只发生了一次死锁,整个排查过程耗时将近一天,最后感谢我们的DBA大神和老大一起分析找到原因. 诊断死锁 借助于我 ...
- 在线分析mysql死锁详解_记一次线上mysql死锁分析(一)
记录一次比较诡异的mysql死锁日志.系统运行几个月来,就在前几天发生了一次死锁,而且就只发生了一次死锁,整个排查过程耗时将近一天,最后感谢我们的DBA大神和老大一起分析找到原因. 诊断死锁 借助于我 ...
- 线上MYSQL同步报错故障处理总结 实现同步不一致进行邮件报警
线上MYSQL同步报错故障处理总结 公司使用腾讯云数据库,今天在从库上面查询相关数据时候,显示没有任何记录,登录后 show slave status\G 查看到状态中报1032错误,这里把相关主从同 ...
最新文章
- NCEPU：线下组队学习周报（011）
- 持志助中华 九州初志开创国内集群存储新时代
- 面试总结-百度（1）
- table选项卡从A页面点击进入B页面指定版块
- 常用电子接口大全，遇到不认识的，就翻出来对照辨认！
- 3 数组中的重复数字
- matlab7.0 run,新手求救啊！！！matlab7.0在win7启动后命令窗口出现大段代码！
- 我，对安全研究专家下手的黑客！
- 使用 matlab 数字图像处理（九）—— 去卷积（deconvolution，逆滤波复原）
- Luogu5280 [ZJOI2019] 线段树 【线段树】
- 最简单的Officescan快速卸载
- c语言程序32位,turbo c语言下载
- python一百行代码的项目_用python一百行代码实现xss扫描工具
- python文件查重_海量文件查重SimHash和Minhash
- js室内地图开发_微信小程序室内地图导航开发-微信小程序JS加载esmap地图
- Beautiful Soup官方手册
- 树形加法器（Brent-Kung加法器）
- Android攻城狮 progressBarprogressDialog
- 【Vmware】打开虚拟机时提示“无法连接虚拟设备，因为主机上没有响应的设备”
- 如何用linux搭建简单的论坛