【 TiDB 使用环境】生产环境
【 TiDB 版本】5.4.0
【复现路径】做过哪些操作出现的问题
【遇到的问题：问题现象及影响】
需要将一张1.8亿的表主键从int改为bigint，有没有什么注意事项，会锁表吗？
【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【附件：截图/日志/监控】
你这个属于物理DDL了
物理 DDL 的特点是执行时间较长，且执行时间与表的数据量、机器配置以及业务负载有关。
执行物理 DDL 会影响业务负载，具体有两个方面。一方面需要从 TiKV 中读取数据并写入新数据，因此会消耗 TiKV 的 CPU 及 I/O 资源。另一方面，DDL Owner 所在的 TiDB 节点需要进行相应的计算，因此会消耗更多的 CPU 资源。
执行物理 DDL（包括添加索引或列类型变更）时，适当调整以下系统变量可以平衡 DDL 执行速度与对业务负载的影响：
tidb_ddl_reorg_worker_cnt：这个变量用来设置 DDL 操作 reorg worker 的数量，控制回填的并发度。
tidb_ddl_reorg_batch_size：这个变量用来设置 DDL 操作 re-organize 阶段的 batch size，以控制回填的数据量。
推荐值：
- 在无其他负载情况下，如需让
ADD INDEX尽快完成，可以将tidb_ddl_reorg_worker_cnt和tidb_ddl_reorg_batch_size的值适当调大，例如将两个变量值分别调为20和2048。 - 在有其他负载情况下，如需让
ADD INDEX尽量不影响其他业务，可以将tidb_ddl_reorg_worker_cnt和tidb_ddl_reorg_batch_size适当调小，例如将两个变量值分别调为4和256。
不锁表
https://docs.pingcap.com/zh/tidb/v5.4/mysql-compatibility#ddl-的限制
TiDB 中，所有支持的 DDL 变更操作都是在线执行的
1 个赞
其他注意的
- 耗时会比较久，可以参考下这个帖子里的答复 变更字段类型非常慢
- 你用的版本会有这个问题
- 目前，TiDB 不使用元数据锁 (MDL) 来防止 DDL 语句修改事务使用的表。如果表定义被更改，提交事务将导致报错
Information schema is changed。此时，事务会自动回滚。
https://docs.pingcap.com/zh/tidb/v5.4/sql-statement-commit#mysql-兼容性
1 个赞
还有个基础的坑也补充提醒下
- 多个 DDL 语句一起执行的时候，后面的几个 DDL 语句会比较慢。原因是当前 TiDB 集群中 DDL 操作是串行执行的。
https://docs.pingcap.com/zh/tidb/v5.4/manage-cluster-faq#为什么有的时候执行-ddl-会很慢
1 个赞
直接执行
在业务低峰期搞吧
建议升级版本后再变更，新版本变更速度特别快。
这倒是呢。
但是，为了改个字符类型，升级版本，这个动作有些大，哈哈
找个业务低峰期加就行
是呢，业务低峰期，开跑，然后把回填的参数改大，跑快些，就好
找个业务低峰期处理
估计时间会很长，建议有个预期，建议低峰期调高tidb_ddl_reorg_worker_cnt和tidb_ddl_reorg_batch_size回填参数执行。
另外回滚可能会很长时间。
谢谢解答
看个人取舍吧，我们的项目感觉慢就升级个版本，升级就快了很多，客户就很满意。 
TiDB 中，所有支持的 DDL 变更操作都是在线执行的，应该不慢吧