我来帮你排查这个问题——这种批量操作遇到「列名不存在」的报错，大概率是脚本的表过滤逻辑有漏洞，或是跨数据库操作时的上下文没处理好。下面分步骤给你拆解解决方案：

1. 先确保表过滤逻辑精准 #

你的脚本可能没准确筛选出真正包含id_ciudad列的用户表，比如误包含了系统表、视图，或者没考虑数据库的大小写敏感性。

针对不同数据库的正确查询方式 #

SQL Server：

SELECT 
    db_name() AS database_name,
    t.name AS table_name
FROM 
    sys.tables t
JOIN 
    sys.columns c ON t.object_id = c.object_id
WHERE 
    c.name = 'id_ciudad'
    AND t.type = 'U' -- 仅筛选用户表，排除系统表
    -- 若数据库大小写敏感，可加LOWER(c.name) = 'id_ciudad'

MySQL：

SELECT 
    table_schema AS database_name,
    table_name
FROM 
    information_schema.columns
WHERE 
    column_name = 'id_ciudad'
    AND table_schema NOT IN ('information_schema', 'mysql', 'performance_schema', 'sys') -- 排除系统库
    AND table_type = 'BASE TABLE' -- 仅筛选实体表，排除视图

PostgreSQL：

SELECT 
    table_catalog AS database_name,
    table_name
FROM 
    information_schema.columns
WHERE 
    column_name = 'id_ciudad' -- 若列名是带引号创建的，要写'"id_ciudad"'
    AND table_schema NOT IN ('pg_catalog', 'information_schema')

2. 确保跨数据库操作的上下文正确 #

很多时候脚本遍历表时，没切换到目标数据库的上下文，导致在当前库中查找其他库的表，自然找不到列。

以SQL Server为例的完整修正脚本 #

DECLARE @dbName NVARCHAR(128), @tableName NVARCHAR(128), @sql NVARCHAR(MAX)

-- 游标获取所有符合条件的表（跨所有用户数据库）
DECLARE tableCursor CURSOR FOR
SELECT 
    d.name AS database_name,
    t.name AS table_name
FROM 
    sys.databases d
JOIN 
    sys.tables t ON d.database_id = t.database_id
JOIN 
    sys.columns c ON t.object_id = c.object_id
WHERE 
    c.name = 'id_ciudad'
    AND d.name NOT IN ('master', 'tempdb', 'model', 'msdb') -- 排除系统库
    AND t.type = 'U' -- 仅用户表

OPEN tableCursor
FETCH NEXT FROM tableCursor INTO @dbName, @tableName

WHILE @@FETCH_STATUS = 0
BEGIN
    -- 切换到目标数据库，这一步非常关键！
    SET @sql = N'USE [' + @dbName + N']; '
    -- 构造更新语句（替换成你的实际更新逻辑）
    SET @sql += N'UPDATE [' + @tableName + N'] 
                  SET id_ciudad = [你的更新值/逻辑] 
                  WHERE [可选：更新条件];'
    
    -- 先打印SQL验证正确性，没问题再取消注释执行
    PRINT @sql
    -- EXEC sp_executesql @sql

    FETCH NEXT FROM tableCursor INTO @dbName, @tableName
END

CLOSE tableCursor
DEALLOCATE tableCursor

3. 额外注意事项 #

• 先验证再执行：大型数据库操作风险高，一定要先打印生成的SQL语句，确认每个更新语句对应的表确实存在id_ciudad列，再执行更新。
• 分批更新：针对超大型表，不要一次性全量更新，建议分批次（比如每次更新1000条），避免长时间锁表影响业务。
• 备份数据：操作前务必备份目标数据库，防止更新逻辑错误导致数据丢失。
• 大小写敏感问题：如果你的数据库开启了大小写敏感（比如PostgreSQL默认、SQL Server区分大小写的排序规则），要确保过滤条件的列名和实际列名完全匹配。

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