晚饭都没吃,我一前端帮后端做了一点SQL优化,才避免了通宵

简介: 最近上线了一个新系统,刚试点运行,用户量不大还没什么大问题。但随之培训和大规模用户开始使用后,问题出现了。而且出现了好多问题,大部分都是后端的,这里就不细讲了。说说与我前端相关的吧。由于我会一点后端。

image.png


1、前言


其实感觉自己做的这点sql优化也算是比较常规的,没什么太大的难度。


最近上线了一个新系统,刚试点运行,用户量不大还没什么大问题。但随之培训和大规模用户开始使用后,问题出现了。而且出现了好多问题,大部分都是后端的,这里就不细讲了。说说与我前端相关的吧。由于我会一点后端。


  • 后端准备叫我开mysql客户端,删除多余的数据


  • 删就删吧,但是要删除的多余数据还有点多


  • 删除以后发现,还他妈有好多要删除的数据,原来三个后端也同时在删除数据


  • 于是我优化了三次sql语句,轻松实现批量删除


  • 如果下次再有这种类似的情况,我得写个相关的小工具了


  • 真的太浪费时间了,也不明白后端为啥不想想办法呢?可能是因为线上bug的压力,没空想吧


2、看看重复记录


根据这三个筛选条件,本来是可以确定唯一记录的。可是并没有,有的记录甚至七八条重复的。


image.png


现在要做的就是把重复记录都只保留一条。


3、开始删除重复记录


image.png


我这是在Navicat工具里删除的,如果只有一条或者几条重复记录这样删删也就完了。但是后端大佬给了100个areaid。年份是固定的2022没什么好说的,每个areaid下的name有89个不重复的。如果一个name一个name的删除要到猴年马月了。这里如上图所示就删除其中一条就好了。


image.png


这里是后端给我的要删除的areaid,也就是具体的name是不太清楚的,因为太多了,还得自己去查。


4、优化删除


因为这是三个查询条件下的数据,如果不加name,把所有这个areaid下的,所有的name 数据可能就有很多了,每次要根据给的areaid进行查询(年份是固定的这里我就不说了)


select s.name as 'sname', s.* from CollectDataSummary s 
where s.areaid = 23 and s.nf = 2022 
order by s.name desc 


image.png


可以看到我只是加了一个排序,然后最上面几条就可以看出三条记录是重复的就要进行删除其中的两条。其实这里正式环境用户量很多,产生一样的数据也非常多,所以删除起来还是比较麻烦的。


这里我想了一下,先查出一个areaid下有重复记录的name


select s.name from CollectDataSummary s 
where s.areaid = 23 and s.nf = 2022 
group by s.`name` HAVING count(s.`name`)> 1


image.png


然后再查询一次,将上面查询的重复的name也作为条件进行查询


select * from CollectDataSummary c 
where  c.areaid = 23 and c.nf = 2022 
and c.name in (select s.name from CollectDataSummary s 
where s.areaid = 23 and s.nf = 2022 group by s.`name` HAVING count(s.`name`)> 1)


image.png


这样查出来可以发现,可以点点将重复的记录都进行删除。勉强一下干了半个小时,我把后端给我的areaid都删除了。


并且我把我这个sql给他们,他们三个后端也在进行删除了,一顿操作后,我手里的这一批几十个删完了。


然后我问了一下都删完了吗,尼玛还有好多好多,按照现在这样删除,他们三个人可能还要删除三个小时,于是我又陷入了沉思.....


5、再次优化删除


想了想,我可以根据name进行分组,然后其实就是只选择了相同数据的其中一行


select a.id from CollectDataSummary a where a.areaid in (
23)  and a.nf=2022 group by a.name having count(a.name)>1


这样的话,我就把这些数据留下吧,然后结合了一下4、优化删除中的sql


image.png


把通过group by 单独查询出来的一组数据通过not in 过滤掉,这样就留下这组数据,其他所有的数据都是要删除的,这样的话就是查询出来的数据,Ctrl + A全选再加上 Delete就完事了,还是非常的方便


6、总结


  • 虽然我觉得这次我帮了大忙,但是这点sql好像也没啥技术含量


  • 其实我想到还可以直接写个delete语句的,但是这样只能看到删除的数据量


  • 然后再不行写一个存储过程将要删除的areaid传进去,循环慢慢删除


  • 还有大招我直接写个页面调用接口来删除,可能更灵活一些,当然要做好检查和确认


第二天想去再看看的时候,数据库已经访问不了了,行吧,继续搞我的前端吧,有空去试试mysql的存储过程,免的啥时候真能派上用场。

目录
相关文章
|
8天前
|
SQL 数据库 开发者
MSSQL性能调优实战技巧:索引优化、SQL语句微调与并发控制策略
在Microsoft SQL Server(MSSQL)的管理与优化中,性能调优是一项复杂但至关重要的任务
|
8天前
|
SQL 监控 数据库
MSSQL性能调优实战策略:索引优化、SQL语句重构与并发控制
在Microsoft SQL Server(MSSQL)的管理和优化过程中,性能调优是确保数据库高效运行、满足业务需求的重要环节
|
8天前
|
SQL 监控 数据库
MSSQL性能调优实战技巧:索引优化策略、SQL查询重构与并发控制详解
在Microsoft SQL Server(MSSQL)的管理与优化过程中,性能调优是确保数据库高效运行的关键环节
|
8天前
|
SQL 监控 数据库
MSSQL性能调优实战指南:精准索引策略、SQL查询优化与高效并发控制
在Microsoft SQL Server(MSSQL)的性能调优过程中,精准索引策略、SQL查询优化以及高效并发控制是三大核心要素
|
3天前
|
SQL 关系型数据库 MySQL
"超级攻略:如何快速排查和优化慢SQL,提升系统速度!"
摘要: 在公司中,SQL查询超1秒被视为慢查询。要排查慢查询,启用MySQL的慢查询日志(`slow_query_log = 1`,`long_query_time = 1`),然后分析`mysql-slow.log`。慢查询可能因缺少索引、不当使用索引、字段过多、多次回表、JOIN操作、深度分页或其他因素导致。通过优化表结构、添加索引、调整SQL和数据库配置来提高性能。定位问题关键,如使用`EXPLAIN`分析执行计划。详细教程和解决方案可在相关文章中找到。
|
3天前
|
缓存 前端开发 JavaScript
前端性能优化都有那些方案 ?
【7月更文挑战第11天】 前端性能优化包括资源合并压缩、懒加载、CDN使用、代码优化、缓存利用和图片优化等策略。例如,减少HTTP请求、压缩CSS/JS、事件委托、利用浏览器及服务器缓存、选择合适图片格式等,旨在提升网页速度和用户体验。服务工作者、异步加载和响应式设计也是关键。持续学习新技术以适应不断变化的优化需求。
10 1
|
8天前
|
SQL 运维 监控
MSSQL性能调优实战技巧:索引优化、SQL查询优化与并发控制策略
在Microsoft SQL Server(MSSQL)的运维过程中,性能调优是确保数据库高效运行、满足业务需求的关键环节
|
8天前
|
SQL 监控 数据处理
MSSQL性能调优实战:精准索引优化、SQL查询微调与高效并发控制策略
在Microsoft SQL Server(MSSQL)的性能调优过程中,精准索引优化、SQL查询的精细微调以及高效并发控制策略是提升数据库性能的三大关键领域
|
1天前
|
前端开发 JavaScript API
告别‘老司机’时代,AJAX与Fetch API让你的前端与Python后端无缝对接!
【7月更文挑战第14天】前端与后端交互的关键技术是AJAX和Fetch API。AJAX允许不刷新页面更新内容,而Fetch API提供了Promise基
|
1天前
|
编解码 缓存 前端开发
现代前端开发中的响应式设计实践与优化
在当今快节奏的互联网环境中,用户对网页的访问设备多样化,响应式设计成为前端开发中不可或缺的一环。本文探讨了响应式设计的重要性以及实现中的最佳实践,涵盖了基本概念、布局策略、以及性能优化的关键技术,为开发人员提供了全面的指导与思路。