这个库的迁移反而不是重点了，主要看开发团队，开发要做的东西太多，也很容易测试不到位。。。

我已经有了，就不兑换了

AI确实好用，但是有两个问题， 一个是太贵了，我们公司一个月就给2亿token，用完了得自己花钱了，我以前写脚本啥的都是自己手工写然后调试，现在直接让ai写完了自己调试，发现问题自己优化完事，确实轻松了。 第二个问题是，给了领导一个错觉，所有活ai都能干，所以疯狂裁员，所以感觉马上工作也没了。

写热点的缓解方式并不是扩容tikv节点，而是表主键优化，然后预拆region尽量将写分配到多个tikv上

可以在每个节点看些使用对应sql的执行计划，看看是否使用到了索引，没有的，重启下看看

不会卡顿的

可以的，pd其实不耗费多少资源，非主节点就更是如此了。

【你所在企业/单位的国产化进度还有哪些卡点？】 数据库基本都国产化了，有些服务器还没有 【你所在企业/单位开始大规模使用 AI Agent 了吗？现在是什么阶段？】 开始用了，目前有自己研发的， 也有对接第三方的。

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

我觉得都可以啊，只要保证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