我试试看啊
强制走tilflash
/----个人排班表----/
left join lbx.ATDEMPLOYEECALENDAR on ATDEMPLOYEECALENDAR.PERSONID=a.PERSONID and ATDEMPLOYEECALENDAR.calendardate BETWEEN ‘2023-11-01’ and ‘2023-11-30’ and ATDEMPLOYEECALENDAR.calendardate <= curdate()
left join lbx.atdtimeclass atd on atd.TIMECLASSID = ATDEMPLOYEECALENDAR.TIMECLASSID
lbx.atdtimeclass atd
你的sql里面有atd别名的表其实是这个。
不在你的截图里面。
lbx.ATDPERSONTIMESHEET atd
还有一个，是这个表。
加完后分析了吗，手工做表分析
join需要每个表都加入tiflash
看看sql的执行计划，到底有没有走tiflash，理论上还是快很多。
sql里面不要执行函数
tiflash的目的是统计分析，你看一下SQL执行计划需要不需要走这
有个tikv或者tidb节点可能性能出问题了，而你的语句可能正好分配到这个节点
一般都是在聚合函数的时候使用tiflash
https://docs.pingcap.com/zh/tidb/stable/tune-tiflash-performance#tiflash-性能调优
怎么看节点性能出没出问题
先看下监控，几个节点的cpu，内存等资源是不是损耗相同，再观察每次执行，找到慢的时候，哪个节点是不是同时规律性的资源升高
大佬是这个情况，我也观察了，确实是同时好几个节点升高了，大概有3个节点由50到80，但是80也不满啊，他一会就下去了
就是说我想沟通加机器，这个偶尔有点高也不能作为合理的条件啊
以影响业务稳定性去申请？
别人的 TiDB 很稳，你的问题太多，同样做运维，你要比别人累很多。
所以尽量先申请到官方推荐的布置。
https://docs.pingcap.com/zh/tidb/stable/hardware-and-software-requirements#生产环境
你就拿官方文档的配置去申请，说要上生产环境使用，需要配置以上的硬件要求。
几个机器配置一样的么？就是tikv是不是一样的，另外tidb的配置是不是一样的，同类别的要保证一样的。我的意思是是不是每次慢的时候都是跑在同一个节点，而恰巧这个节点性能本身有问题
不是一个节点，这个也观察了，可以确定的
那估计还是机器配置太低了，讲实话，后期差多少秒已经不是问题了，主要你这个sql本来就慢