MySQL 5.6+ InnoDB 中扩大 VARCHAR 长度通常不锁表，缩小则可能重建表；PostgreSQL 扩容 character varying 不锁表仅更新元数据；SQL Server 含 LOB 列时易卡住。
ALTER TABLE 修改 VARCHAR 字段长度会锁表吗？
mysql 5.6+ 的 innodb 引擎下，扩大 varchar 长度（比如从 varchar(50) 改成 varchar(200)）通常不重建表，也不锁全表；但缩小长度（如 varchar(200) → varchar(10)）可能触发表重建——尤其当字段已存超长数据时，mysql 要校验并截断，必须走 copy-alter 流程。
- 是否锁表取决于操作类型和 MySQL 版本：5.7+ 启用
ALGORITHM=INSTANT时，仅修改元数据的扩大操作可秒级完成 - 执行前务必检查现有数据：
SELECT MAX(LENGTH(column_name)) FROM table_name;，若结果超过目标长度，ALTER会失败或静默截断（取决于SQL_MODE） - 线上环境别直接
MODIFY COLUMN，优先用CHANGE COLUMN显式指定类型和长度，避免意外丢失列属性（如默认值、注释）
CHAR 字段能随便调大吗？为什么很少有人改它
CHAR 是定长存储，字段长度一改，整张表所有行的物理结构都得重排——哪怕只加 1 字节，MySQL 也大概率重建表。这不是“能不能”，而是“值不值得”。
-
CHAR(10)存'a'仍占 10 字节；改成CHAR(20)后，每行多占 10 字节，总空间翻倍风险真实存在 - 绝大多数场景该用
VARCHAR：只有极短、等长、高频查询的码值（如国家代码CHAR(2)）才适合CHAR - 如果真要调大
CHAR，先确认没业务依赖其定长特性（比如某些 C 程序直连读取），否则不如直接转成VARCHAR
PostgreSQL 怎么安全调整 character varying 长度？
PostgreSQL 对 character varying（即 VARCHAR）长度调整非常友好：只要不缩小到低于现有数据最大长度，就只是更新系统表 pg_attribute，毫秒级完成，不锁表、不重建。
- 检查当前最大长度：
SELECT MAX(LENGTH(column_name)) FROM table_name; - 安全扩长（无锁）：
ALTER TABLE table_name ALTER COLUMN column_name TYPE VARCHAR(500); - 缩小时必须先清理或截断数据，否则报错：
ERROR: value too long for type character varying(10) - 注意：即使不重建，ALTER 操作仍需获取
ACCESS EXCLUSIVE锁——短时阻塞写入，但不影响读
SQL Server 改 varchar 长度卡住？看是不是遇到 LOB 列
SQL Server 在修改含 varchar(max)、text 或其它 LOB 类型的表结构时，容易因内部页迁移卡住，尤其数据量大时。这不是语法问题，是存储引擎行为。
- 普通
varchar(n)（n ≤ 8000）扩长基本秒级；但一旦涉及varchar(max)，哪怕只是加个字节，也可能触发全表扫描+页重组 - 避免方案：先用
SELECT TOP 0 INTO #tmp FROM table创建空临时表，改好结构再INSERT回去（需停写） - 生产环境务必在低峰期操作，并监控
sys.dm_exec_requests中的wait_type，若长时间为LOGBUFFER或PAGEIOLATCH_*，说明 I/O 压力已顶满
