问题场景: mysql数据库的配置为8核16G,数据库单表45k条记录,通过两个未加索引的字段进行查询,返回的记录数小于等于1,绝对并发6k,每个SQL的查询时间为1s。
出现问题: 数据库CPU利用率一直处于100%,导致其他sql操作超时,应用down掉。实际上不到6k并发cpu利用率就到100%。
解决方法:对涉及的两个字段加索引,问题解决,相同的问题场景下数据库CPU基本没有出现波动。
通过这个小问题,值得深思的地方:
- 严谨。设计、开发、维护等整个流程环节都需要严谨。
- 分工。分工越来越细,环环相扣,一个环节出现问题,很可能就是致命的。拿此案例来说,服务器部署架构都没问题,就是因为这个SQL没有索引,导致CPU一直是100%,之外的其它功能也受影响,访问不了。
- 人品。忠诚度应该是算作人品的一个方面,而不是全部。试问一个工作多年的人,忠诚度非常高,但是没有一技之长,能算人品好?勤奋好学也应该是人品中一个重要部分。
相关推荐
一条看似简单的SQL语句,若未经充分优化,就有可能成为系统性能的瓶颈,甚至引发所谓的“血案”——即一系列由于性能问题导致的严重后果。本文将通过四个真实的案例,深入探讨与SQL优化相关的各个方面,以期揭示其...
一条SQL引发的“血案”:与SQL优化相关的个案例(文末送书).docx
本文以一个实际案例"一条慢SQL引发的血案"为背景,探讨了如何诊断和解决慢查询问题。 首先,描述中提到的慢查询耗时达到了70秒,这对任何在线服务来说都是无法接受的,因为它可能导致整个网站瘫痪。这个查询的执行...
第二个查询的注释被正确识别并忽略,而第三个查询由于空格的存在,sqlplus实际上执行的是之前的命令,即`/`,它会执行缓存中的上一条SQL语句。 这种情况可能在某些情况下被忽视,但当通过.shell脚本或.sql文件自动...
这引导我们发现了第二个问题:“一条UPDATE引发的血案”,即事务的锁等待超时。`Error: ER_LOCK_WAIT_TIMEOUT: Lock wait timeout exceeded; try restarting transaction`表明某个事务在等待其他事务释放锁资源时...