python 使用 mysql-connector-python 轮询 mysql 时，首次查询能返回结果，后续却始终为空——根本原因在于游标未显式获取数据且连接复用导致事务隔离或结果集缓存问题，需正确管理游标生命周期与连接状态。
python 使用 mysql-connector-python 轮询 mysql 时，首次查询能返回结果，后续却始终为空——根本原因在于游标未显式获取数据且连接复用导致事务隔离或结果集缓存问题，需正确管理游标生命周期与连接状态。
在构建数据库轮询服务（如监听遗留系统表并同步至新系统）时，一个常见但隐蔽的问题是：查询逻辑看似正确，却只能在首次执行时获取到数据，后续轮询永远返回空结果，即使目标表已被其他进程真实插入并提交了新记录。这并非数据库未更新，而是客户端连接层的行为导致的“假性失联”。
根本原因分析
你的代码中存在两个关键问题：
-
get_records() 方法仅创建并执行了 SQL，但未调用 fetchall() / fetchone() 等方法实际提取结果
cursor.execute(sql) return cursor # ❌ 返回未取数的游标
当你在 for result in source.get_records(): 中遍历时，Python 会尝试对游标对象进行迭代——这虽在 mysql-connector 中被支持，但其行为依赖于内部结果集缓冲状态。更严重的是，若前一次查询未完全消费结果（例如中途异常退出），游标可能处于不可重用状态；而复用同一连接时，未关闭的旧结果集会阻塞新查询的可见性。
长连接 + 自动提交关闭（默认） → 隐式事务隔离影响可见性
mysql-connector-python 默认启用 autocommit=False。这意味着每次 SELECT 实际运行在一个隐式事务中。根据 MySQL 的 RR（Repeatable Read）隔离级别，事务启动时刻的快照将被复用——即使其他连接已提交新数据，当前连接的后续 SELECT 仍读取初始快照，导致“看不见新行”。
win可用的mysql指令skill下载安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
✅ 验证方式：在 MySQL 客户端执行 SELECT @@tx_isolation;，通常为 REPEATABLE-READ；再执行 SELECT @@autocommit;，通常为 OFF。
正确实现方案（推荐）
✅ 方案一：启用自动提交 + 显式获取结果（最简可靠）
class Source(Mysql_DB):
def get_records(self):
if not self.is_connected():
return []
# 关键：确保 autocommit 开启，使每次 SELECT 独立读取最新快照
self.connection.autocommit = True
cursor = self.connection.cursor(buffered=True)
try:
sql = """
SELECT id, inspection_data
FROM `1730_Vantage`
WHERE part_fail = 1
AND posted_in_GFxPRoduction = 0
AND created_at > '2023-06-01'
ORDER BY created_at DESC
"""
cursor.execute(sql)
# ✅ 必须显式获取全部结果，避免游标残留状态
results = cursor.fetchall()
return results
finally:
cursor.close() # 及时释放游标资源主循环调整：
while True:
records = source.get_records() # 直接获取 list of tuples
if not records:
time.sleep(10)
continue
for (id, data) in records:
# ... 处理逻辑（解析、写入目标库、更新标记字段）
success = source.update_record(id, created_at)
if not success:
raise Exception(f"Failed to update id {id}")
# 注意：无需 close connection！连接保持复用，高效且安全✅ 方案二：手动控制事务（适合需要原子性更新场景）
若 update_record() 需与 SELECT 在同一事务中保证一致性（如防止并发重复处理），则应显式开启事务，并在每次轮询后 COMMIT：
def get_records(self):
if not self.is_connected():
return []
self.connection.autocommit = False # 关闭自动提交
cursor = self.connection.cursor(buffered=True)
try:
cursor.execute("START TRANSACTION")
cursor.execute(sql)
results = cursor.fetchall()
# 注意：此处不 commit，留给后续 update_record() 统一提交
return results
except Exception:
self.connection.rollback()
raise
finally:
cursor.close()
def update_record(self, id, created_at):
cursor = self.connection.cursor()
try:
cursor.execute(
"UPDATE `1730_Vantage` SET posted_in_GFxPRoduction = 1 WHERE id = %s",
(id,)
)
self.connection.commit() # ✅ 提交后，下一轮 SELECT 才能看到新快照
return cursor.rowcount > 0
finally:
cursor.close()关键注意事项
- 不要在循环中反复 close() 连接：虽然 source.connection.close() 能“临时修复”，但频繁建连/断连极大降低性能，且掩盖了根本问题。
- buffered=True 是必要的：它确保 fetchall() 将全部结果加载到内存，避免后续 SELECT 因未读完前序结果而阻塞。
- 避免 with 块误用：with cursor: 会在退出时自动 close()，但若你返回的是已关闭游标，后续迭代必然失败。直接 try/finally 显式管理更可控。
- 时间字段比较要谨慎：created_at > "2023-06-01" 若字段含时分秒，建议使用 >= '2023-06-01 00:00:00' 避免边界遗漏。
总结
轮询失效的本质，是 MySQL 连接层的状态管理与事务隔离机制共同作用的结果。解决的核心在于两点：（1）确保每次查询都完整获取结果并清理游标；（2）通过 autocommit=True 或显式 COMMIT 保证每次 SELECT 读取数据库最新状态。遵循上述实践，即可在保持连接复用的前提下，实现稳定、低延迟、高可靠的轮询同步服务。
