一、所有请求都慢
1、确认源实例和目标实例的规格,是否一致,排除实例规格的影响
2、连续执行两次同一个SQL,是否一直都慢,排序物理读的影响
3、查看物理机监控是否有异常
4、查看CPU、IOPS、内存、锁监控,是否有异常
5、show processlist查看会话status是什么状态,是否有明显的异常
二、部分请求慢
1、确认源实例和目标实例的规格,是否一直,排除实例规格的影响
2、连续执行两次问题SQL,是否一直都慢,排序物理读的影响
3、对比分析源实例和目标实例问题SQL的:执行计划,SQL涉及表的表结构,索引信息、query_cache_type是否有区别
4、查看锁监控/show processlist,是否有锁导致的
5、profiling跟踪,分析性能损耗原因
profiling步骤:
1).set profiling=1;
2).执行SQL
3).show profiles; 获取2执行SQL的query_id
4).show profile for query 【3步获取的query_id】
这个问题太大了,有没有其他参数呀?
mysql迁移之后读取速度变慢有可能是碎片导致mysql查询访问变慢的,具体详见下面链接:https://blog.csdn.net/weixin_31968223/article/details/113466217?share_token=c604dfa7-950a-4a8f-af7b-a5723e4bc7ab&tt_from=copy_link&utm_source=copy_link&utm_medium=toutiao_android&utm_campaign=client_share - 【mysql迁移之后读取速度变慢_碎片为什么会导致mysql... - 今日头条
MySQL执行语句过程中涉及到两大流程:优化器和执行器。其中优化器最主要的任务,是选择索引和在多表连接时选择连接顺序。
在case中,join顺序的选择会影响了执行性能。 确定join执行顺序就需要估算所有join操作的代价。默认配置下MySQL会估算所有可能的组合。
MySQL里限制一个查询的join表数目上限为61.
对于一个有61个表参与的join操作,理论上需要61!(阶乘)次的评估。
多表join的场景下,为了避免优化器占用太多时间,MySQL提供了一个参数 optimizer_search_depth 来控制递归深度。 这个参数对算法的控制可以简单描述为:对于所有的排列,只取前当前join顺序的前optimizer_search_depth个表估算代价。
MySQL Tips: MySQL中optimizer_search_depth默认值为62.也就是说默认为全排列计算。 这样能够保证得到最优的执行计划,只是在有些场景下,决定执行计划的时间会远大于执行时间本身。
当出现实例迁移后,多表join执行结果差异较大的时候,要考虑调整这个值。该参数是允许线程单独设置,因此对于应用层来说,每个连接应该都能得到一个较优的值。 2) 反过来,当设置为默认的optimizer_search_depth=62时, MySQL Tips:MySQL profiling 可以用于查看各执行环节的消耗时间。
版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。