登录 / 注册
IT168技术开发频道
IT168首页 > 技术开发 > 技术开发技术 > 正文

相同查询在不同RDS for MySQL的性能差异

2018-05-07 11:19    云栖社区 来源:云栖社区  作者: 田杰 编辑: 田晓旭

  【IT168 技术】相同查询在数据量相近的情况下在不同 RDS for MySQL 实例上有不同的性能表现,容易引发用户对 RDS for MySQL 实例的性能差异性的疑虑,本文分享下近期碰到的一个原因比较隐蔽但很常见的案例。

  1. 问题出现

  一个用户的下述查询在 RDS for MySQL 实例 A 上执行需要 30+ 毫秒,而在 RDS for MySQL 实例 B 执行需要 12+ 秒。

相同查询在不同RDS for MySQL的性能差异

  2. 问题原因

  排查 SQL 在 RDS for MySQL 实例 A 和 B 上的执行计划,发现不一致。执行时间短 - A:

相同查询在不同RDS for MySQL的性能差异

  执行时间长 - B:

相同查询在不同RDS for MySQL的性能差异

  从执行计划对比看问题出现在 表 A 和 中间表 B 关联这步。

  执行计划 B 的 Extra 信息显示 Using join buffer (Block Nested Loop),说明如果选择单纯的 Nested Loop Join 成本会很高(在内层循环无法使用索引的场景下,成本是 O(Rn x Sn))。

  优化器为了提高效率,因此选择了 Block Nested Loop。

  对比执行计划 A,内层使用的索引是 MySQL 自动创建的(auto_key1),检查优化器开关配置是否有区别,以防万一。

相同查询在不同RDS for MySQL的性能差异

  对比两个实例优化器开关配置相同,且 materialization 和 subquery_materialization_cost_based 都已经打开, 加之执行计划 B 中有物化表的使用,因此排除掉优化器开关配置问题。

  此时问题就比较明朗了,应该是关联的两个字段类型不匹配,导致无法通过索引物化临时表的关联字段来使用 Nested Loop Join。

  带着上面的怀疑检查下两个实例的表 Pay 和 inv_msg 的关联字段 PayId 的字段类型。

相同查询在不同RDS for MySQL的性能差异

相同查询在不同RDS for MySQL的性能差异

  可以看到 payId 字段在执行快场景下 2 个表都是 big int 类型;而在执行慢的场景下,2个表的字段类型分别为 big int 和 varchar,导致执行计划选择了对无法使用索引场景优化的 Block Netsted Loop。

  3. 问题解决

  理清问题的根源,就有了针对性的方法。建议用户修改 表 inv_msg 的字段 payid 类型为 big int not null,重新收集统计信息后问题解决。

相同查询在不同RDS for MySQL的性能差异

  4. 问题结论

  需要严格遵守规范进行开发工作。

  用户 DBA 应该进行 SQL 审核工作。

标签: 数据库
  • IT168企业级IT168企业级
  • IT168文库IT168文库

扫一扫关注

行车视线文章推荐

首页 评论 返回顶部