使用SQLAlchemy动态创建SQL表列时VARCHAR长度不符如何解决

核心常见原因 #

1. SQLAlchemy 原生语句解析规则导致的类型覆盖 #

这是该问题最高概率的诱因：你直接传入字符串格式的DDL语句给engine.execute()时，部分版本的SQLAlchemy会自动尝试解析语句中的数据类型，其内置的VARCHAR类型默认长度为60，会覆盖你显式指定的VARCHAR(100)配置。
解决方法是使用SQLAlchemy提供的text()构造器包裹原生SQL，告知框架不需要对语句内容做额外解析，直接透传给数据库执行：

from sqlalchemy import text

# 用text()包裹原生DDL语句
engine.execute(text('ALTER TABLE %s ADD COLUMN %s %s;' % ('table1', col_name, "VARCHAR(100)")))

2. SQL拼接时参数被意外篡改 #

你当前使用Python字符串格式化拼接SQL，需要确认运行时的类型参数是否被其他逻辑覆盖，可以在执行前打印完整拼接后的SQL，验证语句是否符合预期：

sql = 'ALTER TABLE %s ADD COLUMN %s %s;' % ('table1', col_name, "VARCHAR(100)")
print(sql) # 检查输出的语句中是否为VARCHAR(100)
engine.execute(text(sql))

3. 数据库层面的配置限制 #

如果确认执行的SQL无误，需要检查对应数据库的配置：

• 若使用MySQL/MariaDB，检查是否开启了特殊兼容模式的sql_mode，或者低版本数据库存在VARCHAR长度隐式截断的bug，可以直接在数据库客户端手动执行你打印出的ALTER语句，验证是否依旧会生成VARCHAR(60)的列，排查是否是数据库本身的问题。
• 排查是否存在表级别的默认列属性配置，强制限制了新增VARCHAR列的长度。

额外注意事项 #

动态拼接表名、列名的DDL语句存在SQL注入风险，建议对col_name等动态参数做严格的白名单校验，禁止直接使用未过滤的用户输入作为参数。

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