MySQL修改VARCHAR字段长度是否锁表，取决于实际字节数是否跨越255边界：≤255字节用1字节存长度，≥256字节需2字节，跨界则必须COPY重建表并全程锁表；未跨界且为扩容时可in-place或instant，不锁表。
为什么 VARCHAR 扩容有时不锁表，本质是长度字节数没变
MySQL 对VARCHAR 字段扩容是否锁表，不看数字大小，而看它在当前字符集下**实际最大可能占用的字节数是否跨越了 255 字节边界**。因为 InnoDB 在行头用 1 或 2 字节记录该字段真实长度：≤255 字节用 1 字节，≥256 字节就必须用 2 字节。
一旦从 1 字节跳到 2 字节（比如 utf8mb4 下从 VARCHAR(63) → VARCHAR(64)，63×4=252 → 64×4=256），InnoDB 就无法 in-place 修改每行的长度标记，只能走 ALGORITHM=COPY 全表重建——这时就锁表。
反之，如果扩容前后都 ≤255 字节（如 VARCHAR(50) → VARCHAR(200)，200×4=800？错！这里要看的是 *字节数*，不是字符数；但 utf8mb4 下 200 字符最多 800 字节，早已超 255 —— 所以这个例子本身就会锁表。正确例子是 VARCHAR(60) → VARCHAR(63)，240→252 字节，仍用 1 字节存长度），或都 ≥256 字节（如 VARCHAR(256) → VARCHAR(1000)，两者都是 1024/4000 字节，均需 2 字节存长度），InnoDB 可直接更新元数据，不碰行数据，也就不会锁表。
常见误判点：
- 只看
VARCHAR(N)的 N，不查字符集和单字符最大字节数 - 以为 “扩大就不锁”，忽略了 255 字节这个隐形分水岭
- 把
utf8（实际是 utf8mb3）和utf8mb4混为一谈：前者单字符最多 3 字节，255÷3=85，所以VARCHAR(85)是安全上限；后者是 255÷4=63.75 → 实际上限是VARCHAR(63)
怎么提前判断一次 ALTER 是否会锁表
别猜，用算式+命令交叉验证：先确认基础信息：
- 查字符集：
SHOW CREATE TABLE `your_table`;，重点关注DEFAULT CHARSET和字段定义 - 算旧长度字节数：
原长度 × 单字符最大字节数（utf8mb4 用 4，utf8 用 3） - 算新长度字节数：
目标长度 × 单字符最大字节数 - 看是否跨 255：若旧 ≤255 且新 >255 → 必锁；若两者都 ≤255 或都 ≥256 → 可能不锁（还需下一步验证）
再实测可行性（生产前必做）：
- 加显式约束执行：
ALTER TABLE t MODIFY c VARCHAR(N) ALGORITHM=INPLACE, LOCK=NONE; - 如果报错
ERROR 1846 (0A000): ALGORITHM=INPLACE is not supported，说明降级为 COPY，会锁表 - 如果成功，
SHOW PROCESSLIST中状态应为altering table，而非copy to tmp table
MySQL 8.0.12+ 推荐用 ALTER COLUMN 而不是 MODIFY
ALTER TABLE ... ALTER COLUMN ... SET DATA TYPE 比传统的 MODIFY COLUMN 更倾向触发 instant DDL，尤其在纯长度扩容场景下。
它有两点优势：
- 语义更明确：只改类型定义，不隐含索引/约束变更逻辑
- 在满足条件时（如无全文索引、无生成列依赖、未跨 255 字节边界），MySQL 会优先尝试
ALGORITHM=INSTANT，比INPLACE更轻量（连元数据锁 MDL 都只持极短时间） - 失败时直接报错，不会静默 fallback 到 COPY，避免线上误判
示例命令：
ALTER TABLE users ALTER COLUMN nickname SET DATA TYPE VARCHAR(512) ALGORITHM=INSTANT;
注意：如果不确定，宁可显式写 ALGORITHM=INSTANT，而不是省略——省略后 MySQL 会按默认策略选，可能降级。
真正容易被忽略的锁表诱因
很多 DBA 测试时发现“扩 64→256 不锁”，上线却卡住，往往栽在这几个非长度因素上：这些情况会让本该 instant/in-place 的操作强制退化为 copy：
- 字段上有
FULLTEXT索引：InnoDB 无法增量更新全文索引结构，必须重建 - 字段被虚拟生成列（
GENERATED ALWAYS AS）引用：修改源字段需重算所有衍生值 - 表使用
ROW_FORMAT=COMPACT且已接近单行 65535 字节硬限制：即使只是改长度，MySQL 可能因校验行宽而触发重建 - 字段是主键或唯一索引的一部分，且修改涉及排序规则（collation）变更：哪怕只是长度，也可能引发索引重组
VARCHAR(N) 的数字，而是通盘看字符集、索引、行格式、依赖关系——任何一个环节踩中，ALGORITHM=INSTANT 就会当场失效。 
