MySQL通过添加索引解决线上数据库服务器压力大问题
发表于:2026-11-01 作者:千家信息网编辑
千家信息网最后更新 2026年11月01日,昨天3月26号线上应用反馈:晚上19:30-19:43以及 20:13到20:21两个时间段所有人包括他们自己建的教室都进不去,cla***oom B套无法登陆,主页无法访问,已有超过10个老师和学生
千家信息网最后更新 2026年11月01日MySQL通过添加索引解决线上数据库服务器压力大问题
昨天3月26号线上应用反馈:晚上19:30-19:43以及 20:13到20:21两个时间段所有人包括他们自己建的教室都进不去,cla***oom B套无法登陆,主页无法访问,已有超过10个老师和学生反馈进不去教室的问题
通过监控查看26号00:00到27号11:00之间的监控,查看出现问题时数据库服务器的cpu使用率,负载,内存使用,swap剩余量等状况,发现数据库当时压力特别大,
数据库慢查询日志中出现很多慢SQL,
查看慢查询日志,发现一个SQL在慢查询日志中频繁出现切执行时间较长
# User@Host: cms[cms] @ [172.17.43.24]# Query_time: 10.252490 Lock_time: 0.000052 Rows_sent: 1 Rows_examined: 2345869SET timestamp=1522065887;select participan0_.id as id19_, participan0_.conferenceid as conferen2_19_, participan0_.name as name19_, participan0_.phone as phone19_, participan0_.pin as pin19_, participan0_.email as email19_, participan0_.mobile as mobile19_, participan0_.valid as valid19_, participan0_.userdefine1 as userdefine9_19_, participan0_.userdefine2 as userdefine10_19_, participan0_.userdefine3 as userdefine11_19_, participan0_.userdefine4 as userdefine12_19_ from participant participan0_ where (participan0_.conferenceid=2680447 )and(participan0_.pin='1219' );# User@Host: cms[cms] @ [172.17.43.25]# Query_time: 10.297055 Lock_time: 0.000050 Rows_sent: 1 Rows_examined: 2345869SET timestamp=1522065887;select participan0_.id as id19_, participan0_.conferenceid as conferen2_19_, participan0_.name as name19_, participan0_.phone as phone19_, participan0_.pin as pin19_, participan0_.email as email19_, participan0_.mobile as mobile19_, participan0_.valid as valid19_, participan0_.userdefine1 as userdefine9_19_, participan0_.userdefine2 as userdefine10_19_, participan0_.userdefine3 as userdefine11_19_, participan0_.userdefine4 as userdefine12_19_ from participant participan0_ where (participan0_.conferenceid=2697493 )and(participan0_.pin='1492' );# User@Host: cms[cms] @ [172.17.43.25]# Query_time: 10.319839 Lock_time: 0.000048 Rows_sent: 1 Rows_examined: 2345869SET timestamp=1522065887;select participan0_.id as id19_, participan0_.conferenceid as conferen2_19_, participan0_.name as name19_, participan0_.phone as phone19_, participan0_.pin as pin19_, participan0_.email as email19_, participan0_.mobile as mobile19_, participan0_.valid as valid19_, participan0_.userdefine1 as userdefine9_19_, participan0_.userdefine2 as userdefine10_19_, participan0_.userdefine3 as userdefine11_19_, participan0_.userdefine4 as userdefine12_19_ from participant participan0_ where (participan0_.conferenceid=2680355 )and(participan0_.pin='9590' );# User@Host: cms[cms] @ [172.17.43.24]# Query_time: 10.163372 Lock_time: 0.000063 Rows_sent: 1 Rows_examined: 2345872SET timestamp=1522065887;select participan0_.id as id19_, participan0_.conferenceid as conferen2_19_, participan0_.name as name19_, participan0_.phone as phone19_, participan0_.pin as pin19_, participan0_.email as email19_, participan0_.mobile as mobile19_, participan0_.valid as valid19_, participan0_.userdefine1 as userdefine9_19_, participan0_.userdefine2 as userdefine10_19_, participan0_.userdefine3 as userdefine11_19_, participan0_.userdefine4 as userdefine12_19_ from participant participan0_ where (participan0_.conferenceid=2731041 )and(participan0_.pin='1506' );# User@Host: cms[cms] @ [172.17.43.24]# Query_time: 9.950549 Lock_time: 0.000073 Rows_sent: 1 Rows_examined: 2345881SET timestamp=1522065887;select participan0_.id as id19_, participan0_.conferenceid as conferen2_19_, participan0_.name as name19_, participan0_.phone as phone19_, participan0_.pin as pin19_, participan0_.email as email19_, participan0_.mobile as mobile19_, participan0_.valid as valid19_, participan0_.userdefine1 as userdefine9_19_, participan0_.userdefine2 as userdefine10_19_, participan0_.userdefine3 as userdefine11_19_, participan0_.userdefine4 as userdefine12_19_ from participant participan0_ where (participan0_.conferenceid=2682013 )and(participan0_.pin='6086' );# User@Host: cms[cms] @ [172.17.43.25]# Query_time: 9.992145 Lock_time: 0.000051 Rows_sent: 1 Rows_examined: 2345879SET timestamp=1522065887;select participan0_.id as id19_, participan0_.conferenceid as conferen2_19_, participan0_.name as name19_, participan0_.phone as phone19_, participan0_.pin as pin19_, participan0_.email as email19_, participan0_.mobile as mobile19_, participan0_.valid as valid19_, participan0_.userdefine1 as userdefine9_19_, participan0_.userdefine2 as userdefine10_19_, participan0_.userdefine3 as userdefine11_19_, participan0_.userdefine4 as userdefine12_19_ from participant participan0_ where (participan0_.conferenceid=2697493 )and(participan0_.pin='1103' );
查看该SQL的执行计划发现走了全表扫描,扫描了200多万行的数据;
mysql> explain select participan0_.id as id19_, participan0_.conferenceid as conferen2_19_, participan0_.name as name19_, participan0_.phone as phone19_, participan0_.pin as pin19_, participan0_.email as email19_, participan0_.mobile as mobile19_, participan0_.valid as valid19_, participan0_.userdefine1 as userdefine9_19_, participan0_.userdefine2 as userdefine10_19_, participan0_.userdefine3 as userdefine11_19_, participan0_.userdefine4 as userdefine12_19_ from participant participan0_ where (participan0_.conferenceid=2724963 )and(participan0_.pin='5476' );+----+-------------+--------------+------+---------------+------+---------+------+---------+-------------+| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |+----+-------------+--------------+------+---------------+------+---------+------+---------+-------------+| 1 | SIMPLE | participan0_ | ALL | NULL | NULL | NULL | NULL | 2042005 | Using where |+----+-------------+--------------+------+---------------+------+---------+------+---------+-------------+1 row in set (0.02 sec)
发现该表where条件的列上没有索引:
mysql> show index from participant;+-------------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+| Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | Index_comment |+-------------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+| participant | 0 | PRIMARY | 1 | id | A | 2384122 | NULL | NULL | | BTREE | | |+-------------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+1 row in set (0.00 sec)
和开发沟通后在该表上加上以下索引:
mysql> ALTER TABLE `participant` ADD INDEX index_conferenceid (`conferenceid`); Query OK, 0 rows affected (9.16 sec)Records: 0 Duplicates: 0 Warnings: 0 mysql> ALTER TABLE `participant` ADD INDEX index_pin (`pin`);Query OK, 0 rows affected (6.96 sec)Records: 0 Duplicates: 0 Warnings: 0
查看该表的索引
mysql> show index from participant;+-------------+------------+--------------------+--------------+--------------+-----------+-------------+----------+--------+------+------------+---------+---------------+| Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | Index_comment |+-------------+------------+--------------------+--------------+--------------+-----------+-------------+----------+--------+------+------------+---------+---------------+| participant | 0 | PRIMARY | 1 | id | A | 2360697 | NULL | NULL | | BTREE | | || participant | 1 | index_conferenceid | 1 | conferenceid | A | 199 | NULL | NULL | YES | BTREE | | || participant | 1 | index_pin | 1 | pin | A | 199 | NULL | NULL | YES | BTREE | | |+-------------+------------+--------------------+--------------+--------------+-----------+-------------+----------+--------+------+------------+---------+---------------+3 rows in set (0.00 sec)
再次查看该SQL的执行计划,不再走全表扫描,而是走了index_merge,执行时间也大大缩短,
mysql> explain select participan0_.id as id19_, participan0_.conferenceid as conferen2_19_, participan0_.name as name19_, participan0_.phone as phone19_, participan0_.pin as pin19_, participan0_.email as email19_, participan0_.mobile as mobile19_, participan0_.valid as valid19_, participan0_.userdefine1 as userdefine9_19_, participan0_.userdefine2 as userdefine10_19_, participan0_.userdefine3 as userdefine11_19_, participan0_.userdefine4 as userdefine12_19_ from participant participan0_ where (participan0_.conferenceid=2724963 )and(participan0_.pin='5476' );+----+-------------+--------------+-------------+------------------------------+------------------------------+---------+------+------+------------------------------------------------------------+| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |+----+-------------+--------------+-------------+------------------------------+------------------------------+---------+------+------+------------------------------------------------------------+| 1 | SIMPLE | participan0_ | index_merge | index_conferenceid,index_pin | index_conferenceid,index_pin | 5,7 | NULL | 1 | Using intersect(index_conferenceid,index_pin); Using where |+----+-------------+--------------+-------------+------------------------------+------------------------------+---------+------+------+------------------------------------------------------------+1 row in set (0.01 sec)
-----------------------------我是分割线-----------------------
等到晚上约课较多的时间再次观察数据库的负载和慢查询日志一切正常
通过此次事故:
① 及时优化慢查询
② 打开参数 log_queries_not_using_indexes 及时发现没有走索引的SQL
③可以采用SQL审核-自主上线平台,解放人力
https://blog.51cto.com/hcymysql/2053798#comment
数据
查询
数据库
索引
日志
时间
问题
再次
教室
监控
服务器
服务
频繁
两个
主页
之间
事故
人力
使用率
内存
数据库的安全要保护哪些东西
数据库安全各自的含义是什么
生产安全数据库录入
数据库的安全性及管理
数据库安全策略包含哪些
海淀数据库安全审计系统
建立农村房屋安全信息数据库
易用的数据库客户端支持安全管理
连接数据库失败ssl安全错误
数据库的锁怎样保障安全
广州淘业互联网络科技
互联网科技工作委员会毛军
科技与互联网
河南真二互联网科技有限公司
互联网科技资迅
科技互联网技术
上海喔噻互联网科技
阿里巴巴算科技企业还是互联网
浙江互联网科技研学营
宝灵互联网科技有限公司
青岛科技大学互联网大赛研究生
国大互联网教育科技有限公司工作
国大互联网教育科技有限公司薪资
高科技互联网套路
锡山区互联网智能科技产品供应
云鲸互联网络科技有限公司
互联网科技手抄报图片
三亚科技创新互联网基地
互联网科技对化妆品行业
重庆科技产业互联网有哪些
科技互联网
互联网与科技
互联网 卓越科技
互联网女皇 腾讯科技
互联网科技公司做什么
互联网科技创新企业排名
恒银科技与互联网金融
燊美集互联网科技有限公司
长沙互联网科技
互联网金融科技元年