1，资源变化，看下环境变化； 2，业务是否变更；访问模式（并发，访问量等）是否变化，是否造成了mvcc更多版本？ 3，最常用sql执行慢还是部分sql执行满，定位到具体sql。

改变很多呀，兼容适配，shell编写协作，测试代码编写。都很犀利。

1，lightning所在机器资源发下； 2, 感觉整个集群资源紧张。这种小资源下不建议追求速度。

有节点重启了么？或者修改防火墙么？看看防火墙状态。

其他反馈和建议。 自定义函数、同义词、dblink。

看下失败节点的启动日志和err日志。

把-r 200000去掉试试。

什么样的核心–综合稳定、基础性能、高可用、扩展性、痛点sql、成本、数据迁移、应用迁移复杂度、在线DDL复杂度、运维复杂度、升级复杂度、支持、培训、开源、社区、工具、监控等多维度、全生命周期进行考虑。

1，参考：https://docs.pingcap.com/zh/tidb/stable/dev-guide-delete-data#非事务批量删除 2，升级版本，使用TTL功能：ALTER TABLE t1 TTL = created_at + INTERVAL 1 MONTH;

坐标天津，年底缺钱，媳妇让我喝西北风

支持，麻烦搞下，自定义函数很有战略价值。国内来说，本来在异构数据库的兼容性已经很落后了。国际市场也大概率有不少需求。麻烦产品经理用力点。

什么样的核心–综合稳定、基础性能、高可用、扩展性、痛点sql、成本、数据迁移、应用迁移复杂度、在线DDL复杂度、运维复杂度、升级复杂度、支持、培训、开源、社区、工具、监控等多维度、全生命周期进行考虑。

不用tiup ， 用dumpling文件的路径执行试试。

可能需要先看本地客户端字符集问题。

大量数据导出可以使用sqluldr： Oracle 大数据量导出工具——sqluldr2 的安装与使用 另外商业版本可以找方法使用TMS

Oracle的不兼容，对国内TiDB商业市场挑战比较大；资本看中商业化成果；未来还是开源和用户数量。

看下系统load，pd那个盘在干嘛，cpu在干嘛，内存在干嘛？

sql走不走索引跟条件有关，其次速度看： 1，统计信息； 2，索引； 3，执行计划是否有很多版本，比如频繁删除数据等，需要想办法减少版本。 4，tiflash。