在数据库运维工作中，监控和优化慢查询是提高mysql性能的关键步骤。正确设置并分析慢查询日志，可以帮助我们定位到性能瓶颈，从而制定出相应的优化策略。本文将通过一个实际案例来详细讲解如何在mysql中动态设置慢查询，并分析其结果。
假设在某电商平台的数据库运维过程中，管理员发现在高并发时段，用户反映系统响应缓慢。为了找到潜在的问题，决定启用并分析慢查询日志。
首先，我们登录到mysql数据库，通过以下命令查看当前的慢查询配置：
show variables like 'long_query_time';
show variables like 'slow_query_log';
long_query_time变量定义了多慢的查询才会被记录到慢查询日志中，默认值是10秒。slow_query_log变量则表示是否开启了慢查询日志记录功能。
在初步检查后，我们发现慢查询日志未开启，且long_query_time的值过长。于是，我们决定将其设置为2秒，并开启慢查询日志：
set global long_query_time = 2;
set global slow_query_log = 'on';
接下来，我们让系统在高流量时段运行一段时间，然后通过以下命令查看慢查询日志文件的位置：
show global variables like 'slow_query_log_file';
获取到日志文件路径后，我们下载并分析该日志文件。在日志中，我们看到许多执行时间超过2秒的查询，其中一个频繁出现的查询引起了我们的注意：
select * from orders where customer_id = 1234 and status = 'pending';
经过分析，该表的customer_id和status字段并未建立合适的索引，导致查询效率低下。为了验证这一点，我们使用explain命令分析查询计划：
explain select * from orders where customer_id = 1234 and status = 'pending';
查询计划显示，该查询进行了全表扫描，这是非常低效的。于是，我们决定为这两个字段创建复合索引：
create index idx_orders_customer_status on orders(customer_id, status);
在创建了索引后，我们再次观察慢查询日志，并发现该查询的执行时间大幅减少，不再出现在慢查询日志中。
通过这个案例，我们可以看到，动态设置和分析mysql的慢查询对于快速定位并解决性能问题是非常有帮助的。重要的是要合理设置long_query_time以捕捉到可能影响性能的慢查询，并通过分析慢查询日志来优化相应的查询语句和数据库结构。
