首页 > 数据库> 文章详细

mysql更改执行计划_数据量增加导致MySQL执行计划改变

2022-08-24 11:02:41 阅读：181 来源： 互联网

标签：product gift promo MySQL cost 数据量 mysql id

收到运维同学电话，MySQL服务器连接数满了，登录服务器查看，确实满了，好吧，首先增加连接数到2500，暂时提供对外服务。连接继续升高，又快达到2500。发现有大量的查询时间将近到了1200秒，大量的长连接堆积，导致连接数攀升，看来还是sql的问题。在这些长连接中，发现这样的sql

SELECT product_id,gift_id,gift_original_price,gift_count, FROM promo_xxx WHERE promotion_id IN (589994,589994) AND product_id IN (22569455) AND is_valid=1;

mysql> explain SELECT product_id,gift_id,gift_original_price,gift_count FROM promo_gift WHERE promotion_id IN (589994,589994) AND product_id IN (22569455) AND is_valid=1;

+----+-------------+-----------------+------+---------------+------+---------+------+--------+-------------+

+----+-------------+-----------------+------+---------------+------+---------+------+--------+-------------+

+----+-------------+-----------------+------+---------------+------+---------+------+--------+-------------+

1 row in set (0.04 sec)

mysql> show index from promo_gift;

+-----------------+------------+-----------------+--------------+-----------------+-----------+-------------+----------+--------+------+------------+---------+---------------+

+-----------------+------------+-----------------+--------------+-----------------+-----------+-------------+----------+--------+------+------------+---------+---------------+

| promo_gift_list | 0 | PRIMARY | 1 | id | A | 261184 | NULL | NULL | | BTREE | | |

| promo_gift_list | 0 | id_promo_gift | 1 | promotion_id | A | 1140 | NULL | NULL | YES | BTREE | | |

| promo_gift_list | 0 | id_promo_gift | 4 | product_id | A | 261184 | NULL | NULL | YES | BTREE | | |

狗血的sql，竟然走全表扫描，但是promotion_id有索引啊，为什么没有走索引呢？而且以前建立的索引，走的好好的，今天怎么就出现问题了，这是一个问题

那我们可以通过last_query_cost 查看sql消耗

mysql>SELECT product_id,gift_id,gift_original_price,gift_count FROM promo_gift WHERE promotion_id IN (589994,589994) AND product_id IN (22569455) AND is_valid=1;

mysql>show status like 'last_query_cost';

+-----------------+--------------+

| Variable_name | Value |

+-----------------+--------------+

| Last_query_cost | 52626.599000 |

+-----------------+--------------+

1 row in set (0.00 sec)

不走索引，那我们强制使用索引

mysql> explain SELECT product_id,gift_id,gift_original_price,gift_count FROM promo_gift force index(id_promo_gift) WHERE promotion_id IN (589994,589994) AND product_id IN (22569455) AND is_valid=1;

+----+-------------+-----------------+-------+---------------+---------------+---------+------+--------+-------------+

+----+-------------+-----------------+-------+---------------+---------------+---------+------+--------+-------------+

+----+-------------+-----------------+-------+---------------+---------------+---------+------+--------+-------------+

1 row in set (0.02 sec)

嗯，加上索引了，那么sql消耗怎么样呢？

mysql> SELECT product_id,gift_id,gift_original_price,gift_count FROM promo_gift force index(id_promo_gift) WHERE promotion_id IN (589994,589994) AND product_id IN (22569455) AND is_valid=1;

+------------+----------+---------------------+------------+

+------------+----------+---------------------+------------+

| 22569455 | 23230046 | 147.00 | 1 |

+------------+----------+---------------------+------------+

1 row in set (0.40 sec)

mysql> show status like 'last_query_cost';

+-----------------+---------------+

| Variable_name | Value |

+-----------------+---------------+

| Last_query_cost | 174432.609000 |

+-----------------+---------------+

1 row in set (0.00 sec)

我们发现如果使用这个索引，sql消耗174432.609000>52626.599000,mysql优化器认为使用这个id_promo_gift索引，sql消耗是非常大的，这就是mysql执行不使用这个索引的原因。

后来开发人员说，昨天晚上这个表增加了11万多的数据，嗯，数据量增加，mysql执行计划改变。那好吧，单独product_id列再加一个索引。

mysql> alter table promo_gift_list add index product_id(product_id);

Query OK, 0 rows affected (6.45 sec)

Records: 0 Duplicates: 0 Warnings: 0

mysql> explain SELECT product_id,gift_id,gift_original_price,gift_count FROM promo_gift_list WHERE promotion_id IN (589994,589994) AND product_id IN (22569455) AND is_valid=1 AND IFNULL(is_delete,0)!=1;

+----+-------------+-----------------+------+--------------------------+------------+---------+-------+------+-------------+

+----+-------------+-----------------+------+--------------------------+------------+---------+-------+------+-------------+

+----+-------------+-----------------+------+--------------------------+------------+---------+-------+------+-------------+

1 row in set (0.00 sec)

使用了刚才新加的索引 product_id

mysql> SELECT product_id,gift_id,gift_original_price,gift_count FROM promo_gift_list WHERE promotion_id IN (589994,589994) AND product_id IN (22569455) AND is_valid=1 AND IFNULL(is_delete,0)!=1;

+------------+----------+---------------------+------------+

+------------+----------+---------------------+------------+

| 22569455 | 23230046 | 147.00 | 1 |

+------------+----------+---------------------+------------+

1 row in set (0.00 sec)

mysql> show status like 'last_query_cost';

+-----------------+----------+

| Variable_name | Value |

+-----------------+----------+

| Last_query_cost | 2.399000 |

+-----------------+----------+

1 row in set (0.01 sec)

sql消耗降到了2.399000，ok，问题解决。连接数很快从1000多降到100以内。

数据量的增加导致了mysql执行计划的改变，那么mysql的cost是怎么计算的呢？

cost=io_cost+cpu_cost

cpu_cost位于mysql上层，处理返回的记录所花开销，io_cost存储引擎层，读取也没的IO开销。最直接的方式last_query_cost记录sql的cost。查看last_query_cost可以初步判断sql的cost，明白mysql优化器执行的依据。
参考网址见:https://blog.csdn.net/weixin_35980267/article/details/113223849

标签：product,gift,promo,MySQL,cost,数据量,mysql,id
来源： https://www.cnblogs.com/lipengsheng-javaweb/p/16619073.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。

ICode9

mysql更改执行计划_数据量增加导致MySQL执行计划改变