SQL语句导致性能问题

前阵子,突然收到服务器的报警信息,于是上服务器找问题,我擦,top看到mysql占的%cpu高得把我吓尿了

从以上的信息看,相信大家已经可以定位到底是那个程序导致服务器CPU负载过高了,但我们要做的是,找出mysql进程下,是什么动作导致服务器出现性能问题

以下做个实验,相信大家看了后也能猜到当时是什么导致高负载的,废话不多说:

表结构如下:

mysql> desc test1;
+---------+-------------+------+-----+---------+----------------+
| Field   | Type        | Null | Key | Default | Extra          |
+---------+-------------+------+-----+---------+----------------+
| id      | int(11)     | NO   | PRI | NULL    | auto_increment |
| role_id | int(11)     | NO   |     | 0       |                |
| referer | varchar(20) | NO   |     |         |                |
+---------+-------------+------+-----+---------+----------------+
3 rows in set (0.00 sec)

mysql> desc test2;
+--------------+---------+------+-----+---------+----------------+
| Field        | Type    | Null | Key | Default | Extra          |
+--------------+---------+------+-----+---------+----------------+
| id           | int(11) | NO   | PRI | NULL    | auto_increment |
| role_id      | int(11) | NO   | MUL | 0       |                |
| privilege_id | int(11) | NO   |     | 0       |                |
+--------------+---------+------+-----+---------+----------------+
3 rows in set (0.00 sec)

表的索引情况如下:

mysql> show index from test1;
+-------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+
| Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment |
+-------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+
| test1 |          0 | PRIMARY  |            1 | id          | A         |         329 |     NULL | NULL   |      | BTREE      |         |
+-------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+
1 row in set (0.00 sec)

mysql> show index from test2;
+-------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+
| Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment |
+-------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+
| test2 |          0 | PRIMARY  |            1 | id          | A         |       12476 |     NULL | NULL   |      | BTREE      |         |
| test2 |          1 | role_id  |            1 | role_id     | A         |         415 |     NULL | NULL   |      | BTREE      |         |
+-------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+
2 rows in set (0.00 sec)

当时执行show full processlist后,发现有好几百个连接在执行同一条SQL语句,看见SQL也还好,不复杂,是子查询

mysql> select privilege_id from t2 where role_id in (select role_id from t1 where id=193);

看着以上的SQL语句,写没什么问题啊,但用explain分析一看,我擦

mysql> explain select privilege_id from test2 where role_id in (select role_id from test1 where id=192);
+----+--------------------+-------+-------+---------------+---------+---------+-------+-------+-------------+
| id | select_type        | table | type  | possible_keys | key     | key_len | ref   | rows  | Extra       |
+----+--------------------+-------+-------+---------------+---------+---------+-------+-------+-------------+
|  1 | PRIMARY            | test2 | ALL   | NULL          | NULL    | NULL    | NULL  | 12476 | Using where |
|  2 | DEPENDENT SUBQUERY | test1 | const | PRIMARY       | PRIMARY | 4       | const |     1 |             |
+----+--------------------+-------+-------+---------------+---------+---------+-------+-------+-------------+
2 rows in set (0.00 sec)

当时MySQL版本是:

mysql> select  version();
+-----------+
| version() |
+-----------+
| 5.1.66    |
+-----------+
1 row in set (0.00 sec)

但把SQL语句的子查询修改为以下的写法,执行效率就就像喝了可乐一样爽^0^:

select a.privilege_id from test2 as a inner join test1 as b on a.role_id = b.role_id and b.id=192;

看效果对比:

mysql> select  version();
+-----------+
| version() |
+-----------+
| 5.1.66    |
+-----------+
1 row in set (0.00 sec)

mysql> explain select privilege_id from test2 where role_id in (select role_id from test1 where id=192);
+----+--------------------+-------+-------+---------------+---------+---------+-------+-------+-------------+
| id | select_type        | table | type  | possible_keys | key     | key_len | ref   | rows  | Extra       |
+----+--------------------+-------+-------+---------------+---------+---------+-------+-------+-------------+
|  1 | PRIMARY            | test2 | ALL   | NULL          | NULL    | NULL    | NULL  | 12476 | Using where |
|  2 | DEPENDENT SUBQUERY | test1 | const | PRIMARY       | PRIMARY | 4       | const |     1 |             |
+----+--------------------+-------+-------+---------------+---------+---------+-------+-------+-------------+
2 rows in set (0.00 sec)

mysql> explain select a.privilege_id from test2 as a inner join test1 as b on a.role_id = b.role_id and b.id=192;
+----+-------------+-------+-------+---------------+---------+---------+-------+------+-------+
| id | select_type | table | type  | possible_keys | key     | key_len | ref   | rows | Extra |
+----+-------------+-------+-------+---------------+---------+---------+-------+------+-------+
|  1 | SIMPLE      | b     | const | PRIMARY       | PRIMARY | 4       | const |    1 |       |
|  1 | SIMPLE      | a     | ref   | role_id       | role_id | 4       | const |   32 |       |
+----+-------------+-------+-------+---------------+---------+---------+-------+------+-------+
2 rows in set (0.00 sec)

相信大家也能看到修改后跟修改前的差别了吧!

以下用版本为5.5的版本测试下:

以下用版本为5.6的版本测试下:

mysql> select version();
+------------+
| version()  |
+------------+
| 5.6.10-log |
+------------+
1 row in set (0.00 sec)

mysql> explain select privilege_id from test2 where role_id in (select role_id from test1 where id=192);
+----+-------------+-------+-------+---------------+---------+---------+-------+------+-------+
| id | select_type | table | type  | possible_keys | key     | key_len | ref   | rows | Extra |
+----+-------------+-------+-------+---------------+---------+---------+-------+------+-------+
|  1 | SIMPLE      | test1 | const | PRIMARY       | PRIMARY | 4       | const |    1 | NULL  |
|  1 | SIMPLE      | test2 | ref   | role_id       | role_id | 4       | const |   32 | NULL  |
+----+-------------+-------+-------+---------------+---------+---------+-------+------+-------+
2 rows in set (0.07 sec)

mysql> explain select a.privilege_id from test2 as a inner join test1 as b on a.role_id = b.role_id and b.id=192;
+----+-------------+-------+-------+---------------+---------+---------+-------+------+-------+
| id | select_type | table | type  | possible_keys | key     | key_len | ref   | rows | Extra |
+----+-------------+-------+-------+---------------+---------+---------+-------+------+-------+
|  1 | SIMPLE      | b     | const | PRIMARY       | PRIMARY | 4       | const |    1 | NULL  |
|  1 | SIMPLE      | a     | ref   | role_id       | role_id | 4       | const |   32 | NULL  |
+----+-------------+-------+-------+---------------+---------+---------+-------+------+-------+
2 rows in set (0.04 sec)

看到的两种查询结果是一样高效的,从以上的案例可以看出,写通用且性能高的SQL相当重要,希望大家以后不要踩类似的坑@[email protected]

时间: 2024-10-23 05:38:53

SQL语句导致性能问题的相关文章

利用pl/sql执行计划评估SQL语句的性能简析

一段SQL代码写好以后,可以通过查看SQL的执行计划,初步预测该SQL在运行时的性能好坏,尤其是在发现某个SQL语句的效率较差时,我们可以通过查看执行计划,分析出该SQL代码的问题所在. 那么,作为开发人员,怎么样比较简单的利用执行计划评估SQL语句的性能呢?总结如下步骤供大家参考: 1. 打开熟悉的查看工具:PL/SQL Developer. 在PL/SQL Developer中写好一段SQL代码后,按F5,PL/SQL Developer会自动打开执行计划窗口,显示该SQL的执行计划. 2.

SQl语句查询性能优化

[摘要]本文从DBMS的查询优化器对SQL查询语句进行性能优化的角度出发,结合数据库理论,从查询表达式及其多种查询条件组合对数据库查询性能优化进行分析,总结出多种提高数据库查询性能优化策略,介绍索引的合理建立和使用以及高质量SQL查询语句的书写原则,从而实现高效的查询,提高系统的可用性. [关键词]SQL查询语句,索引,性能优化 1.引言 在应用系统开发初期,由于开发数据库数据比较少,对于查询SQL语句,索引的运用与复杂视图的编写等体会不出SQL语句各种写法的性能优劣,但是应用系统实际应用后,随

mybatis的sql语句导致索引失效,使得查询超时

mybaitis书写sql需要特别注意where条件中的语句,否则将会导致索引失效,使得查询总是超时.如下语句会出现导致索引失效的情况: with test1 as (select count(C_FUNDACCO) val,'a' v from TINF_REQUEST a where a.C_FUNDCODE = #{cFundcode} and a.D_DATADATE = #{dDatadate}), test2 as (select count(C_FUNDACCO) val,'a'

SQL语句导致cpu占用如此高

一般我们可以使用sql server自带的性能分析追踪工具sql profiler分析数据库设计所产生问题的来源,进行有针对性的处理.但我们也可以通过自己写SQL语句来有针对性的进行性能方面的查询.通常会用到如下三个系统视图:sys.sysprocesses ,dm_exec_sessions ,dm_exec_requests --一.查看当前的数据库用户连接有多少USE master GOSELECT *FROM sys.[sysprocesses]WHERE [spid] > 50--AN

提高SQL语句的性能

一.FROM子句中的表 FROM子表的安排或次序对性能有很大的影响,把较小的表放在前面,把较大的表放在后面,可以得到更高的效率. 二.WHERE子句中的次序 一般来自基表的字段放在结合操作的右侧,要被结合的表通常按照从小到大的次序排列 如果没有基表的直接按照表的大小来安排条件的次序,把最小的表放在最前面. 结合条件应该放在最前面,之后才是过滤条件 根据SQL优化器读取SQL语句的次序,让最严格条件最先读取 三.使用LIKE操作符和通配符 使用通配符时,如果可以的话,不要再最前端使用,因为这样会影

SQL 语句与性能之执行顺序

select * , t3.Name from t1 left join t2 on t1.sysno = t2.Asysno left join t3 on t3.sysno = t2.Bsysno 上面SQL语句中,t3表数据很多;此时查询t3.Name会很慢,如果把t3和name干掉,秒中就能查询出数据,这样就有了这种sql select * , (select top 1 name from t3 where sysno =t2.Bsysno)Name from t1 left join

(转)详解利用EXPLAIN分析sql语句的性能

本文转自https://blog.csdn.net/Solmyr_biti/article/details/54293492 explain显示了MySQL如何使用索引来处理select语句以及连接表.可以帮助选择更好的索引和写出更优化的查询语句. 先解析一条sql语句,看出现什么内容 EXPLAINSELECTs.uid,s.username,s.name,f.email,f.mobile,f.phone,f.postalcode,f.addressFROM uchome_space ASs,

SQL 语句与性能之联合查询和联合分类查询

select * from t1 left join t2 on t2.sysno =t1.ASysNo left join t3 on t3.sysno =t2.ASysNo left join t4 on t4.sysno =t3.ASysNo left join t5 on t5.sysno =t4.ASysNo left join t6 on t6.sysno =t5.ASysNo left join t7 on t7.sysno =t6.ASysNo where t1.name lik

一条执行4秒的sql语句导致的系统问题 (转)

为了一看究竟,抓取了一个awr报告.发现系统的负载情况确实很严重,每秒的redo有1.6M,可见系统的负载不是主要在select上,可能有一些dml之类的操作极为频繁. 看了下等待事件.都是关于lock的.这个时候就有些纳闷了.到底什么样的操作会导致严重的锁等待. Top 5 Timed Foreground Events 这个时候怎么解释执行计划效率很高,但是执行时间却很长的问题.第一个猜想就是系统的负载加大了,可能查取数据的时候就慢了.但是反过来说,也不会慢这么高的比例啊.所以这种猜想不成立