慢查询导致任务执行hang住

上线上了大半天，原因：因为慢查询了导致跑不出来，后来同事帮忙看了下发现慢查询了，程序hang住了

select * from table where cdate = '2023-02-01' and id > ? order by id limit 500

这条sql线上执行了300ms，一共900w数据左右，需要半个小时，后来优化了下改成了这样进行扫表，按照id去进行扫表，扫表只需要4分钟，大概每个sql只需要20ms，速度提高很多

     SELECT id,name FROM table  WHERE  id > id and id <= maxId ORDER BY id ASC limit 500

midId: select id from table where cdate = '2023-02-01' order by id asc limit 1

maxId: select id from table where cdate = '2023-02-01' order by id desc limit 1

初始化 id := minId - 1

{

sub 数组

SELECT id,name FROM table WHERE id > id and id <= maxId ORDER BY id ASC limit 500

id = sub.id

}

对比两种扫表方式，第一种走的是 cdate 对应的索引，扫表行数在百万级别以上，然后获取数据需要进行回表

第二种方式直接走的主键索引，这种方式不需要进行回表，而且扫描行数比较低，这种方式是组内大佬进行优化想出来的

好的一点：发现问题，及时求助，同事帮忙定位到了，及时解决了导致没有一直等着，所以线上观察是很重要的，测试环境测试数据量小发现不了很多问题，线上数据量大起来，就会发现很多在测试环境发现不了的问题

慢查询治理: https://www.cnblogs.com/zhangpengfei5945/p/16085441.html

上线以后后续项目线上观察：

发现数据异常，和同事定位问题，是中间对接的时候有个指标的单位没有对其导致界面计算展示错误，需要修复，不然影响后续的任务。这里看到上线以后的数据观察是非常重要的，如果不观察，就不会发现异常，后续修复会更加的困难

上游数据错了，这个时候有点慌，经过旁边同事提醒，还是仔细分析：查数据看历史记录，无论是不是自己的原因，后面遇到问题尽量都不要慌了，深呼吸下，提醒自己，如果是自己的问题，就认，然后去修复改正，如果是上游的问题，就去发出来，然后看看大家有什么方案，积极去解决推动

总结

• 线上和测试环境的不一致，测试环境正常，线上环境不一定预期内的正常，比如数据量，用户操作等等，都可能是之前没有考虑到的情况，上线之后一定要观察下
• 慢查询还是要注意的，平时300ms的sql也不会影响使用，有些场景就会影响使用了
• 后续产品的运营和交互过程中要去观察体验看下，看数据是否符合预期
• 自己出错了或者上游导致的出错，遇到问题不要慌张，深呼吸，让自己冷静下来，去分析、去解决

参考：

https://my.oschina.net/u/4090830/blog/5571483