tidb是分布式的，所以没有table_io_waits_summary_by_table这个表的

你子查询的表数据可能是下推到tikv节点执行的，就算每个节点按照你的排序给了结果，汇总到tidb时候不可能重新再排序了啊，所以不保证子查询排序结果，放最外层，到tidb节点会重新排序的。

你是从哪个数据库迁移到 TiDB 的？ 迁移 TiDB 都用啥工具？偏爱 TiDB 原生的 DM、Lightning、TiCDC，还是习惯用 DataX、Flink 这些第三方，或者自己自研工具？ mysql到tidb，用的dm，也有配置datax任务 不用 TiDB 原生迁移工具的小伙伴，是因为技术栈适配难、性能不够，还是觉得易用性一般？大家最希望 TiDB 迁移工具加啥实用功能？ 其实最希望的是oracle到tidb的迁移工具，没找到合适的，最后oracle都迁移到ob了 实操 TiDB 数据迁移时，你踩过最坑的是什么？是数据量大迁移慢、一致性难保证，还是业务中断风险，或者工具运维太…

一般3个T差不多了，3节点的话，一个节点一个T，但是你的业务数据肯定还会增长啊，所以得按照业务多申请点空余空间融合增长数据

rename很快，大表收集统计信息的话建议手工收集一下看看 SET tidb_build_stats_concurrency=16; SET tidb_distsql_scan_concurrency =64; ANALYZE TABLE table_name WITH 0.1 SAMPLERATE;—收集10%的统计信息

一共几个tikv节点，3个以上的话，只是一个tikv节点重启应该不影响集群使用的

设置这个就可以了，这个是在线，实时生效，想要持久化的话，可以通过tiup edit-config修改这个配置参数

这不算高啊，tidb也是又缓存的，sql执行完了，不会立刻释放内存的。

机器上free -g看下内存使用情况呢

换俩笔记本吧

你的数据库设置的表名大小写敏感吗？

没复现这个问题。。。所有的view都不行吗？

需要compact才能真正释放空间，就算gc了，空间也没释放

直接发执行计划，explain analyze生成的

16G估计真的只能启动每个节点，然后稍微波动下就不够了，每个节点的应用起来都要占起码2G左右的内容的。。

mvcc模式，不会存在死锁或者幻读的情况

可以考虑下tidb cloud

你最喜欢的一款 TiDB 周边是什么？ 行李箱，没赶上啊。。。 你最近看到哪些创意的周边是让你感觉很 “哇塞” 的。有图片的话，可以尽可能附图哟~ 武侠类的手办

你截图的日志并不是报错级别的啊，不至于导致起不来