而且从整个sql来看，表l和表d走index join应该更好吧

走like会比走start_time过滤更多数据吗，如果不会，那现在走start_time没问题的。 start_time是一个范围值，就算跟like的字段是联合索引，也不能走这个索引啊。 如果走like会更优，那就用hint绑定like字段的那个索引，强行走like

先看监控，确认一下leader和region是不是已经全部迁移完成了。如果是的话，要用pd ctl查看对应的store，看看还有什么region在里面，手动给迁移走，当store没有region了，就回变成tombstone

这十分钟有没有人执行sql呢，最好在有问题的tidb的日志中找找expensive关键字，如果是sql导致的内存升高，基本会有这个关键字。如果找不到的话，可能是其他原因了。

lightning导入完成的时候还是正常的吗，然后重启集群后发现tidb节点占用内存非常高，就手动重启了机器对吧？重启机器后跑了sql吗，比如接入业务了吗，有人跑sql测试吗

这就是走index join了，为啥 t1.deleted=0 这个条件导致走不了index join，不清楚

查查表结构，字符集排序规则是不是一样的，关联字段是不是一样的，有没有对应的索引

INL_JOIN(t1) 这样试一下

1、你加hint以后，出现了warning： [image] 2、hint不生效，可以查看一下这里： Optimizer Hints | PingCAP 文档中心

不绑的话，可能导致使用内存的时候，用到了更远的内存，耗时增加。而且不绑核，万一并发内存消耗高的sql，机器容易hang住

建议绑，一个机器上有多个实例就需要绑，避免实例资源争抢。不管是相同的组件还是不同的组件混部，都一样。 具体测试情况，及绑核的原因可以看这个文章： 专栏 - 单机 8 个 NUMA node 如何玩转 TiDB - AMD EPYC 服务器上的 TiDB 集群最优部署拓扑探索 | TiDB 社区

绑核主要是限制cpu、内存，混部的时候不要有资源争抢。一般是给tidb和tikv绑核，每个节点都需要绑

满足以下权限即可：TiDB Lightning 目标数据库要求 | PingCAP 文档中心

这应该是找不到镜像文件吧，提示都写了呀，你重置一下镜像路径试试。 ps：没有镜像路径是怎么部署集群的？感觉这个tiup可能也不对

操作系统的性能不怎么好对比呀，反正使用的时候绑核了，没出现过坑。倒是应用出现过问题，哈哈哈

好多生产环境用上了麒麟欧拉版 V10 SP1/SP2，已经一年多了，目前看来没啥问题

看最亮的地方，每分钟多少流量

有的话就直接binding一下就行了

2.0有这个吗，我找了一下文档好像没找到： 执行计划管理 (SPM) | PingCAP 文档中心