ALTER COLUMN修改列类型不安全，需按数据库差异处理：PostgreSQL用ALTER COLUMN ... TYPE + USING；MySQL用MODIFY/CHANGE COLUMN；SQL Server用ALTER COLUMN；均须预检数据兼容性、约束及索引影响。
ALTER COLUMN 语法在不同数据库中的实际写法
直接用 ALTER COLUMN 修改列类型是否安全，取决于你用的是哪种数据库。MySQL、PostgreSQL 和 SQL Server 的语法和行为差异很大，稍不注意就会报错或隐式截断数据。
PostgreSQL 支持 ALTER COLUMN ... TYPE 并自动尝试转换，比如把 TEXT 改成 VARCHAR(100)，但若原数据超长会直接失败；MySQL 则必须用 MODIFY COLUMN 或 CHANGE COLUMN，且对 TEXT → VARCHAR 这类变更要求显式指定长度，否则报错 ERROR 1170 (42000): BLOB/TEXT column used in key specification without a key length。
- PostgreSQL 示例：
ALTER TABLE users ALTER COLUMN email TYPE VARCHAR(255) USING email::VARCHAR(255);——USING子句必须显式声明转换逻辑，否则遇到非空约束或默认值可能失败 - MySQL 示例：
ALTER TABLE users MODIFY COLUMN email VARCHAR(255) NOT NULL;—— 若原列为TEXT，必须补全NOT NULL或其他约束，否则会丢失原有约束 - SQL Server 示例：
ALTER TABLE users ALTER COLUMN email NVARCHAR(255) NOT NULL;—— 不支持直接从TEXT（已弃用）转，需先转成NVARCHAR(MAX)再改长度
修改前必须验证数据兼容性
类型变更不是“改个定义”就完事。比如把 INT 改成 TINYINT，只要表里有大于 255 的值，执行就会中断并回滚（PostgreSQL）或静默截断（旧版 MySQL，开启严格模式后才报错）。
真正要做的，是提前查出“可能出问题的数据”：
- 检查长度：对目标列运行
SELECT MAX(LENGTH(column_name)) FROM table_name;，对比新类型的长度上限 - 检查数值范围：如改
INT→SMALLINT，执行SELECT COUNT(*) FROM table_name WHERE column_name 32767; - 检查非法字符：从
VARCHAR改为CHAR或带校对规则的类型时，SELECT * FROM table_name WHERE column_name COLLATE utf8mb4_bin != column_name COLLATE utf8mb4_general_ci;可暴露排序/比较异常
NULL 值与默认值会悄悄破坏变更
很多同学改类型时没注意 NOT NULL 约束和默认值的存在。例如 PostgreSQL 中给一个允许 NULL 的列改类型，如果新类型不支持 NULL（极少，但自定义域可能），或者你加了 NOT NULL 但没提供 DEFAULT，语句直接失败。
更隐蔽的是默认值表达式不兼容：把 DATE 列改成 TIMESTAMP，原默认值 CURRENT_DATE 在部分版本中无法自动适配为 CURRENT_TIMESTAMP，导致 ALTER 报错 default expression not valid for new type。
- 安全做法：先
ALTER TABLE ... ALTER COLUMN ... DROP DEFAULT;，改完再加回来 - 若新类型需要非空默认值，且原列含 NULL，得先
UPDATE table_name SET column_name = 'fallback_value' WHERE column_name IS NULL; - MySQL 中
ALTER COLUMN不保留原默认值，必须在MODIFY语句里重新写上DEFAULT ...
大表在线修改的锁与性能风险
在生产环境对百万级以上表执行类型变更，ALTER TABLE 很可能锁表数分钟甚至更久。MySQL 5.6+ 的 ALGORITHM=INPLACE 仅对部分变更有效（如增减长度），而类型转换通常触发 COPY 算法；PostgreSQL 的 ALTER COLUMN ... TYPE 在多数情况下仍需重写整张表。
真正能避开长锁的方法，不是“怎么写 SQL”，而是换策略：
- 新建兼容列（如
email_v2 VARCHAR(255)），用UPDATE分批同步数据（每次 1k 行 +SLEEP(0.1)） - 建视图或应用层双写过渡，等新列数据一致后，再用
DROP COLUMN+RENAME COLUMN切换 - 用
pt-online-schema-change（MySQL）或pg_repack（PostgreSQL）这类工具，它们本质是创建影子表 + 触发器同步，但要求主键存在且无复杂外键依赖
最常被忽略的一点：即使语法跑通、数据也兼容，如果表上有函数索引、表达式索引或部分索引，类型变更后这些索引大概率失效，必须手动重建。
