MySQL 5.6+ 对 InnoDB 表扩大 VARCHAR 长度通常不锁表（instant DDL），但存在全文索引、生成列依赖或 utf8mb4 接近行限制时会退化为 copy-alter 全程锁表；MyISAM 始终锁表。
ALTER TABLE 修改 VARCHAR 长度会锁表吗？
MySQL 5.6 以后的 INFORMATION_SCHEMA 和 performance_schema 默认启用，但真正影响锁表现的是存储引擎和操作类型。对 VARCHAR 字段执行 ALTER TABLE ... MODIFY COLUMN 或 CHANGE COLUMN 扩容时：
- 如果是
InnoDB表且只扩大长度（比如从VARCHAR(50)改成VARCHAR(200)），在 MySQL 5.6+ 中属于「instant DDL」，不重建表、不锁写，仅加元数据锁（MDL），持续时间极短 - 但如果字段上有全文索引、生成列依赖、或使用了
utf8mb4且原长度接近行限制（如VARCHAR(65535)），可能退化为 copy-alter，全程锁表 -
MyISAM表一律拷贝重建，锁表时间取决于数据量
怎么安全地扩 VARCHAR 而不中断线上服务
核心是避免隐式降级为 copy-alter。实操建议：
- 先查清当前字段定义：
SHOW CREATE TABLE `table_name`;，确认字符集（utf8mb4下每个字符最多占 4 字节）、是否含索引、是否被虚拟列引用 - 用
ALTER TABLE ... ALTER COLUMN ... SET DATA TYPE（MySQL 8.0.12+）比MODIFY更明确，优先触发 instant 模式 - 如果不确定，加
ALGORITHM=INSTANT强制指定（失败会报错，不会静默降级）：ALTER TABLE t1 ALTER COLUMN name SET DATA TYPE VARCHAR(255) ALGORITHM=INSTANT; - 生产环境务必在低峰期试跑，用
SELECT SLEEP(0.1)模拟并发写入，观察SHOW PROCESSLIST是否卡住
为什么扩到 VARCHAR(1000) 还报错 “Row size too large”
这不是字段长度问题，而是 InnoDB 单行总长度超限（约 65535 字节）。VARCHAR 在 utf8mb4 下按最大可能字节数计算：1000 × 4 = 4000 字节；如果表里还有十几个类似字段，加上其他固定长度列（INT、DATETIME 等），很容易突破硬限制。
- 检查实际行宽：
SELECT SUM(CHAR_LENGTH(COLUMN_NAME)) FROM information_schema.COLUMNS WHERE TABLE_NAME='t1' AND TABLE_SCHEMA='db_name';（仅估算，非精确） - 更准的方法是看
SHOW TABLE STATUS LIKE 't1'中的Row_format和Avg_row_length - 真超限了，只能拆表、改用
TEXT（不计入行大小）、或把部分大字段移到关联表
ALTER 后应用层要注意什么
字段变长本身不破坏兼容性，但容易忽略两点：
- ORM 框架（如 Laravel Eloquent、Django ORM）可能缓存了旧的 schema 元信息，重启应用或清空 schema cache
- 如果代码里有硬编码的截断逻辑（比如
substr($str, 0, 50)），现在字段能存 200 字符了，但业务校验没同步更新，会导致前端显示不全或后端校验失败 - 数据库连接池（如 HikariCP）一般不受影响，但某些老版本驱动对新长度返回的
getColumnDisplaySize()可能不准，影响分页或导出
最麻烦的不是 ALTER 语句本身，而是字段扩容后，上下游系统是否真的按新长度处理了数据——尤其是那些没走 ORM、直接拼 SQL 的老模块。
