MySQL 视图(合并多表数据)引发的严重性能问题
问题背景:
一、客户环境连续多次出现性能问题,系统登入异常,数据库CPU告警。
处理过程:
1>协助排查数据库性能问题时发现如下两个较频繁的SQL导致严重的性能问题(均使用了视图合并多表数据):
1 1. SELECT nodename FROM view_name1 WHERE id = xxx; 2 3 2. SELECT a.id rid,accounttype,belongto,resourceId,belongtoshow FROM view_name2 a 4 LEFT JOIN tablename1 b 5 ON a. col1= b.col1 6 WHERE a.col1> 0 ;
2> 上面两个SQL使用到了视图(视图通过union all合并了两张表的数据)。下面以t001和t002为例分别给出直接查询原表和使用视图查询的执行计划对比
(其中t001和t002表中id列均有索引):直接查询原表后对结果进行合并:
3>通过视图进行查询:
1 create view t_view as 2 select * from t001 3 union all 4 select * from t002
4> 对比执行计划可以发现,使用视图进行数据union all会导致索引失效,使用了全表扫描的方式进行数据检索,在并发高的情况下,
占用较多的磁盘IO,严重消耗数据库的CPU和IO资源,影响到整体的数据库性能,现阶段已发现较多的这种使用视图的代码,应避免使用视图,采用分开查询各表的方式。
————————————————
聚焦技术与人文,分享干货,共同成长更多内容请关注“数据与人”
分类:
MySQL
【推荐】国内首个AI IDE,深度理解中文开发场景,立即下载体验Trae
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· 记一次.NET内存居高不下排查解决与启示
· 探究高空视频全景AR技术的实现原理
· 理解Rust引用及其生命周期标识(上)
· 浏览器原生「磁吸」效果!Anchor Positioning 锚点定位神器解析
· 没有源码,如何修改代码逻辑?
· 分享4款.NET开源、免费、实用的商城系统
· 全程不用写代码,我用AI程序员写了一个飞机大战
· MongoDB 8.0这个新功能碉堡了,比商业数据库还牛
· 记一次.NET内存居高不下排查解决与启示
· 白话解读 Dapr 1.15:你的「微服务管家」又秀新绝活了