如题
搞开发接触数据查询的少不了遇到这样的情况：
①查询一堆数据响应太慢，耗时太长；
② 甚至如果项目里有定时任务还会出现事务发生死锁的现象。（时间太长会锁表，而这时定时任务过来更新表操作就会出问题，执行失败）
总结一些查询慢的原因，以供查看。
- 未用到索引或者干脆没有索引。（设计时的缺陷）
- 过度依赖索引（索引不是万能的，某些情况全表反而效率更高）
- I/O性能问题，出现瓶颈。
- SQL语句写的太渣，需要优化。
- 网络速度慢如蜗牛（就比如国内访问国外节点，调试一小时，等待50分）
- 内存不足了、CPU占用过高
- 要查询的数据量太大，一次吃不下（动不动就查百万数据，还想一次就返回来？）
- 出现了死锁（设计缺陷导致出现死锁，出结果是不可能的啦）
- 表结构设计有问题（这就需要在一开始就尽量设计规范，考虑全面）
…
解决顺序
当我们出现这样的问题时，正常的顺序一般是：
-
先排除网络原因（因为网络好坏是最显而易见的，很容易就判别）
-
观察监控，是不是此时CPU飙升或内存占满？（废话，这时候一般都会飙升）
-
调试程序定位到出现问题/耗时太长的代码附近，看是不是本条SQL造成的。
-
将SQL拉出来，单独去工具上执行查找，看耗时：如果依然耗时太长，那就是SQL问题，优化就行（字段、列、关键字使用、索引、分页查询等等）；
如果工具上执行很快，一放到代码里就很慢，那多半不是SQL问题，需要去找SQL被调用的关联代码块，去打日志计算耗时。 -
SQL优化发现已经没啥效果了，那就考虑是表设计是否有问题；
-
业务逻辑是不是有问题，或者耦合过高；
-
最后才考虑升级硬件、添加场外辅助等。
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。
文章由极客之音整理，本文链接：https://www.bmabk.com/index.php/post/157219.html
