08 | 一个几乎每个系统必踩的坑儿：访问数据库超时

老师，慢SQL 我感觉也没有个人标准，个人的标准也要分场景，业务复杂度等；如果作为常规的用户业务系统，超过1秒就是慢SQL；但是如果是类似生成报表的服务，选择在业务低峰期，从库执行等策略，时间长点也不是不能接受。 避免慢SQL：第一点肯定想到的是合适的索引，毕竟SQL执行速度的快慢关键还是语句需要扫描数据的行数，如尽量不要使用 对where 条件列进行计算的做法让MySQL查询优化器不知道怎么选择索引，特定业务 可以设置联合索引让需要查询返回的列都在索引中避免回表操作。 第二：排序也是可能完成慢SQL的因素，尤其是数据量大，需要使用外部排序的时候又可以与磁盘IO性能扯上关系等，常见的问题还有limit m,n m很大又无法使用索引的时候 第三：多表联合查询的时候，尽量使用小表驱动大表。 第四：避免大事务，这也是发生死锁常见的雷区，尽量减小事务粒度，尽量注意不同事务对表操作的顺序一致，大事务其实也包含着批量操作的隐式事务，如一个update 影响100万行数据。 第五：见过的关于架构方面的慢SQL问题 1～数据量到达一定规模后，单机性能容易受限导致数据库响应慢；2～读写分离，从库提供读服务，错误的认为从库只需要提供查询服务采用了达不到性能指标的机器，其实是主库承受的数据更新压力，从库一个不落的都要承受，还要更多的提供查询服务

上面那个小型创业公司的微服务架构，想知道有关 Nginx 的主备是怎么实现的？

请问老师，我有两个问题请教。1. 为什么后台服务被大量请求打死的话无法自动恢复呢？ 2. 案例中用的什么cache，怎么refresh的？

老师，我现在想做一个Mysql的本地熔断方案。就是监控对每一个表的操作语句，通过机器数量在配置中心配置每个服务的访问频次、访问时间等。比如Mysql的TPS是4000，我们有10台机器，平均下来每个服务的上限为400/s。碰到超限、或者超慢的情况就熔断、告警。可以整体监控，也可以对热点表进行监控，这种方案是否可行？

个人感觉，算不算慢SQL首先取决于这条SQL有没有正确的命中索引。如果可以正确的命中索引，那么从业务上是否正确。如果业务匹配，且正常命中索引，那应该不算是慢查询。 看完本章还有一点疑惑，就是当第一个慢查询SQL处理完成后，MySQL的CPU使用率已经降到了20%以下。那么即便会有周期性的SQL执行，但是以这个利用率不足以整体导致服务不可用吧。

老师讲的非常好，给出了查找问题的思路和解决问题思路，对于项目经验少的很有用。后续课程里面有没有涉及对于视频类的大文件存储方式和使用方式的课程？这部分数据知道使用对象存储进行存储比较好，但是对于有这种大文件的存储的系统架构方面还是不清晰，老师要是了解给指导一下可以吗

老师 针对两个问题排查后处理的方法能不能给个思路 1. 缓存热点数据 ： 因为使用连表查询等复杂语句在数据量大的时候会产生慢差 。是否该考虑修改查询语句或者上搜索（es / 阿里open search ) 然后再加一道缓存 缓存的读写策略采用旁路策略。 2. 像这种定时任务应该大部分公司都会有很多，一般都是放到凌晨来执行 ，经常会有人问当数据量大的时候 这种定时任务是否可行。 所以像数据量非常大（京东这种级别数据） 定时任务扫表是否还可行 有没有其他的解决思路 希望老师给些思路 谢谢🙏

老师好，我想问一下如果定时任务执行时间到了，但是数据还没执行完，这时候该怎么处理？

合理使用日志系统、通过合理监控获取必要时信息和做报警提醒，每天定时排查日志中记录的问题；例：cpu使用率、IO使用率等。 指定一套完善的开发规范：严禁开发去写，上线之前做code review;规范制度+code review+架构审核，基本能避免大多数问题的发生。

慢SQL要以业务场景来区分。例如做即时通讯或者消息类等有实时性要求的，可能2秒就算慢查询了，但是读从库做大数据分析的场景，可能跑一个小时也不算慢。另外，对于请数量大的时候，如果存在多个请求会加锁，即使一个查询是毫秒级别的，上百个查询访问一个热数据加锁也会有很大的问题，所以，没有慢查询的具体标准，影响到业务，拖慢了服务的，就算慢查询。