删除。。。
1、 欢迎使用 tiup 集群的管理工具，这边看到当前的集群是 4.0 rc 版本
2、如果方便请提供升级前后上述 sql 的执行计划，执行计划的获取方式为：
explain analyze sql
3、请查看下 slow-log 中是否有上述 sql 的记录
4、请提供下目标表的表结构
这个参数如果计算不会回影响性能吗？我这里没改。
1、从执行计划可以看到，使用的是全表扫描，并且扫描行数为 500+ 万
2、请提供下目标表的表结构，如果是 username 列没有索引，那么建议评估该列的基数，是否创建索引。如果评估后，可以创建索引，那么 sql 文本建议做如下修改，避免索引被屏蔽：
select * from table where username like ‘Abc%’;
3、如果评估后，无法创建索引，那么请评估是否调整下述参数，来达到提高数据扫描的效率。建议先在 session 级别配置，观察下：
同样的sql，同样的表结果在单机上要快，用tiup之后反而慢了。说明不是sql的问题
如果不模糊查询也很慢，第一次加载页面的时候
1、首先， tiup 只是咱们 tidb 的管理工具哈~~
2、如果是同样的 sql 在 4.0 rc 版本执行慢了，那么请提供下单机版下该 sql 的执行计划，这里再分析下
25分钟前的那两张图就是。下面是tiup，上面是单机
换成 4.0 rc 版本后页面加载，半天都加载不出来。
好的，我们现在重新梳理下信息：
1、单机环境下 sql 的执行计划：
2、tiup 部署的 4.0 rc 的 sql 执行计划
3、从两个执行计划看，均为全表扫描，并且执行的耗时分别为 1.39s 以及 1.27s ，并且 4.0 RC 下的 1.27s 执行时间小于 1.39s ，效率是比较高的。
4、上面提到的页面加载是指应用页面加载慢，还是第三方客户端访问 TiDB 慢？
1) 如果是应用端的直观感受是在 4.0 RC 下，耗时比较长，那么建议排查下应用到 TiDB 的网络延时，或者可以在应用端打出整个请求的耗时,便于继续排查。
2) 如果是通过第三方客户端访问慢，那么请直接登录 TiDB server 的服务器，使用 mysql client 来访问，再看下查询耗时。
都慢了很多，不管是第三方客户端还是页面加载。同一条sql，或是同一个页面明显比以前慢了很多
这个你搞错了吧慢的是4.0RC.快的是单机
好的，按照上面的信息，如果 1.39s 的是 4.0 rc，那么这个和 1.27s 之间差距不是特别的大，请：
1）在应用端添加日志，将整个请求的耗时输出，包括网络耗时等
2）请分别直接登录 tidb server 服务器，使用 mysql client 执行 sql 观察下两套环境的执行耗时
4.0和单机都是部署在一台服务器上的。单机是以前部署的端口4000。4.0rc的tidb端口是4001。速度慢了很多