阅读全文

⭐⭐⭐ Spring Boot 项目实战	⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》	《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》	《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》	《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》	《Java 面试题 + Java 学习指南》

摘要: 原创出处 juejin.cn/post/7407304950349676554 「掘金online」欢迎转载，保留摘要，谢谢！

• 1、使用Navicat执行大文件sql情况
• 2、使用IDEA执行大文件sql情况
• 3、使用IDEA执行1.83G sql的超大文件
• 4、原因猜想：

---

🙂🙂🙂关注微信公众号：【芋道源码】有福利：

1. RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表
2. RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址
3. 您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。
4. 新的源码解析文章实时收到通知。每周更新一篇左右。
5. 认真的源码交流微信群。

---

最近我惊奇地发现IDEA执行大文件sql竟然比专业的Navicat效率高很多！反常识有木有！

前提：我有一些大文件sql需要执行，如下，最大的文件有1.83G：

至于为什么要执行这么大的文件，因为迁移数据库数据，数据库之间网络不通，不能直接迁移。故先导出sql，复制到对应环境中再执行sql。

1、使用Navicat执行大文件sql情况

起初我使用的Navicat导入数据，先执行的小文件试水，当执行90.1M的文件时，明显卡顿，电脑发热，cpu高占用率高，程序卡死（navica卡死，看不到导入进度），如下图：

• Navicat: 运行100M左右的sql，14分钟后卡死，看不到执行进度
• kernel_task: 电脑发热或线程调度繁忙时mac系统自带的任务管理工具，尝试改善发热和调度。我用手摸确实电脑非常烫。需要用小风扇对着吹才能维持电脑中等温度。
• OrbStack Helper: 容器管理工具，类似于Docker，据说比Docker轻。我要迁移的目标库使用的OrbStack生成的mysql容器

总结：它们三者累计占用cpu 194.6+118.9+54.5=368，执行90.1M的sql执行完成时间为20.5分钟，执行效率为4.4M/min，执行sql时会卡死

2、使用IDEA执行大文件sql情况

尝试用IDEA自带的数据库管理工具执行大sql。以下是执行98.8M的sql时的情况：

• kernel_task: cpu占用只有前面数据的40%左右，电脑不使用风扇亦能保持中等温度。
• OrbStack Helper: 跟前面的数据接近，符合常理。
• IDEA： cpu占用只有44，对比前面的Navicat 194.6，约为前面的22.6%。IDEA执行时cpu占用情况大幅优于cavicat。执行时间为17分钟，执行效率为5.8M/min，对比前面的效率4.4M/min，效率提升32%，即执行大文件sql的执行效率IDEA也优于navicat！此外，IDEA并未卡死！

总结：它们三者累计占用cpu 49.6+47.3+44.0=140.6, 执行98.8M的sql执行时间为17分钟，执行效率为5.8M/min，执行sql不会卡死！

3、使用IDEA执行1.83G sql的超大文件

执行结果如下：

总结：cpu占用率同前，占比不高，cpu占用约140，执行1.83G的sql执行时间为1小时19分，执行效率为23.47M/min，效率又提升了300%，即文件越大执行效率越高，执行sql也没有卡死！。

所以执行大文件sql应果断选用IDEA，各方面吊打Navicat有木有!

4、原因猜想：

1）cpu占用： 也许Navicat执行时采用了多线程，画蛇添足，IDEA未采用多线程，不会触发线程保护机制，也不会有线程管理的消耗，反而cpu占用更低。

2）执行效率： Navicat默认每条sql执行完成后（成功or失败），一条条打印结果，增大了消耗，而IDEA在insert时是1000条sql执行完成后才打印一条结果，消耗没那么多