你是否遇到过Python轮询MySQL时“第一次有数据、之后全为空”的诡异问题？这并非数据库没更新，而是mysql-connector-python在连接复用、事务隔离（默认RR级别）和游标状态管理上的隐性陷阱——未显式取数、autocommit关闭导致快照固化、旧结果集残留阻塞新查询。本文直击根源，给出两种生产级解决方案：一是开启autocommit+显式fetchall+buffered游标，简单高效；二是手动事务控制，兼顾SELECT与UPDATE的原子性。附关键避坑指南：禁用频繁重连、必设buffered=True、慎用with游标、精准处理时间边界。掌握这些，就能构建稳定低延迟的轮询同步服务。 
    
 

Python 使用 mysql-connector-python 轮询 MySQL 时，首次查询能返回结果，后续却始终为空——根本原因在于游标未显式获取数据且连接复用导致事务隔离或结果集缓存问题，需正确管理游标生命周期与连接状态。

在构建数据库轮询服务（如监听遗留系统表并同步至新系统）时，一个常见但隐蔽的问题是：查询逻辑看似正确，却只能在首次执行时获取到数据，后续轮询永远返回空结果，即使目标表已被其他进程真实插入并提交了新记录。这并非数据库未更新，而是客户端连接层的行为导致的“假性失联”。

你的代码中存在两个关键问题：

1. get_records() 方法仅创建并执行了 SQL，但未调用 fetchall() / fetchone() 等方法实际提取结果

   cursor.execute(sql) return cursor # ❌ 返回未取数的游标

   当你在 for result in source.get_records(): 中遍历时，Python 会尝试对游标对象进行迭代——这虽在 mysql-connector 中被支持，但其行为依赖于内部结果集缓冲状态。更严重的是，若前一次查询未完全消费结果（例如中途异常退出），游标可能处于不可重用状态；而复用同一连接时，未关闭的旧结果集会阻塞新查询的可见性。

2. 长连接 + 自动提交关闭（默认） → 隐式事务隔离影响可见性
   mysql-connector-python 默认启用 autocommit=False。这意味着每次 SELECT 实际运行在一个隐式事务中。根据 MySQL 的 RR（Repeatable Read）隔离级别，事务启动时刻的快照将被复用——即使其他连接已提交新数据，当前连接的后续 SELECT 仍读取初始快照，导致“看不见新行”。
   
   
   
   

✅ 验证方式：在 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 读取数据库最新状态。遵循上述实践，即可在保持连接复用的前提下，实现稳定、低延迟、高可靠的轮询同步服务。

好了，本文到此结束，带大家了解了《MySQL轮询获取新数据失败怎么解决》，希望本文对你有所帮助！关注golang学习网公众号，给大家分享更多文章知识！