不是大幅度调整时间肯定没问题了

我觉得都可以啊，只要保证56789都是单独的节点，其他没啥大区别，都不太消耗资源的

lighting全量加cdc增量吧只能。

调整 GC 时间（重要！） -- 导出前延长 GC 时间，避免数据被清理 SET GLOBAL tidb_gc_life_time = '24h'; -- 导出完成后恢复 SET GLOBAL tidb_gc_life_time = '10m'; 降低并发数 dumpling --host 127.0.0.1 --port 4000 --user root --threads 4 --rows 100000 --filesize 256MiB --output /path/to/output 分片导出 d…

SELECT ID, USER, HOST, DB, COMMAND, TIME, STATE, INFO FROM information_schema.PROCESSLIST WHERE TIME > 1000 AND state<>‘SLEEP’ ORDER BY TIME DESC; 直接找时间长的就行，时间段的也好耗费不了多少CPU

创建必要的目录 mkdir -p /tmp/tidb/tmp_ddl-4000 chmod 755 /tmp/tidb/tmp_ddl-4000 配置 TiDB 临时目录 # tidb.toml [performance] temp-dir = "/data/tidb/tmp" 使用持久化目录 mkdir -p /data/tidb/tmp_ddl chown tidb:tidb /data/tidb/tmp_ddl 确保临时目录配置在持久化存储上 检查 TiDB 启动用户对目录的权限 避免使用 /tmp 目录（系统重启可能清空）

参数可以调整下看看

这么小的表，应该还是锁的问题，应该先把锁处理了，ddl语句就过去了

不可能吧，访问肯定是访问新表啊

调整 Store 权重 # 降低空间紧张节点的权重 tiup ctl pd -u http://pd:2379 store weight <store_id> 1 5 # store_id: tikv001 的 store id # 参数说明: leader_weight region_weight

v8.1.1 存在一些内存管理相关的已知问题 建议升级到 v8.1.2 或更新版本

绑定numa只是为了防止节点之间争抢资源，你也可以光给tidb绑定numa，限制他只能用1一个node，但是tikv不限制啊。。。可以防止tidb抢tikv的资源，但是不限制tikv抢tidb的资源。。。

【2025 年你对 TiDB 有哪些新的认知？】 暂无 【2025 年你眼中的 TiDB 社区】 很好很强大 【总结你的 2025 年社区参与战绩】 惭愧，没有多少战绩 【2026 年你会在哪些新的场景和系统考虑用 TiDB 吗】 有个项目要换掉原来的mysql，就是规模太小，考虑换成tidb有点大材小用 【留言你对 TiDBer 们的新年祝福】 祝大家马上暴富。

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%的统计信息