将数据库列从longtext改为mediumtext耗时超1小时，是否正常？

4万行数据修改字段类型耗时1.5小时以上确实不太正常，大概率是操作或环境层面存在问题，以下是具体分析和排查方向：

可能的核心原因 #

• 锁表阻塞：执行ALTER TABLE修改字段类型时，MySQL会对目标表加排他锁。如果此时有未完成的读写事务、慢查询在运行，会导致修改语句一直等待锁释放，时间被大幅拖长。
• 磁盘IO瓶颈：修改字段类型本质是重写整张表的数据，若服务器磁盘性能不足（比如用机械硬盘、磁盘负载过高），会严重拖慢数据重写速度。4万行的量级哪怕全是大字段，正常情况下也不该耗时这么久。
• 全文索引的额外开销：如果该字段上建有全文索引，修改类型时需要同步重建索引，这会增加耗时，但4万行的规模也不至于到1.5小时，更可能是和其他因素叠加导致。

排查与优化建议 #

• 检查锁状态：执行SHOW PROCESSLIST;查看当前是否有阻塞ALTER语句的进程，若存在无关的长事务或慢查询，可以优先终止。
• 使用在线DDL方式：如果是MySQL 5.6及以上版本，可尝试添加ALGORITHM=INPLACE参数执行修改（mediumtext和longtext同属TEXT家族，多数场景支持INPLACE模式），避免锁表并提升速度；也可以用pt-online-schema-change这类工具实现无锁表结构修改。
• 排查磁盘性能：用iostat或服务器监控工具查看磁盘IO使用率、读写速度，确认是否是磁盘性能瓶颈导致的耗时增加。
• 验证实际数据规模：先执行SELECT MAX(LENGTH(content)) FROM your_table;查看字段的实际数据长度，如果大部分数据远小于mediumtext的16MB上限，说明修改类型本身的开销应该很小，重点排查其他阻塞因素。

另外补充：修改字段类型从longtext到mediumtext不一定能解决全文检索的性能问题，全文检索慢更多和索引设计、查询语句优化、服务器内存配置有关——比如是否给全文索引分配了足够内存，查询时是否避免了不必要的字段扫描等。

内容的提问来源于stack exchange，提问作者maybethebestprogrammer