上线上了大半天，原因：因为慢查询了导致跑不出来，后来同事帮忙看了下发现慢查询了，程序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也不会影响使用，有些场景就会影响使用了
- 后续产品的运营和交互过程中要去观察体验看下，看数据是否符合预期
- 自己出错了或者上游导致的出错，遇到问题不要慌张，深呼吸，让自己冷静下来，去分析、去解决