GitHub API数据拉取及MySQL插入耗时过长 如何优化提升运行速度

一、API请求核心优化（提速占比最高） #

• 砍掉重复请求：当前单仓库累计发起3次commit接口请求、1次contributor接口请求，其中3次commit请求完全可以合并为1次：拉取commit列表的同时统计总commit数、当前用户的commit数、提取commit日期，直接减少2/3的commit类请求开销。
• 改用异步/并发请求：现有所有请求为串行执行，可换成aiohttp协程或者线程池并发拉取不同仓库的数据，并发数控制在10~20即可，避免触发GitHub限流，可将请求耗时压缩到原来的1/N（N为并发数）。
• 优先选用GitHub GraphQL API：REST API需要多次调用才能拿到单仓库的全量字段，GraphQL可以一次性请求得到用户信息、仓库列表、每个仓库的commit总数、用户提交数、贡献者数、时间字段等所有需要的数据，请求量直接降低一个数量级，是最明显的优化手段。
• 优化分页逻辑：不需要手动拼接page参数，GitHub API返回的Link响应头已经包含下一页的地址，直接读取即可，既避免拼接错误也能快速判断是否还有下一页。
• 增加缓存机制：已经拉取过的仓库、commit数据可存入本地JSON或者Redis，下次运行时无需重复请求，适合多次跑任务的场景。

二、代码逻辑冗余优化 #

• 封装通用分页函数：拉取仓库、commit、贡献者的分页逻辑完全一致，封装为一个通用函数，避免重复代码，也降低出错概率。
• 删掉无效代码：现有日期处理逻辑中d1.strftime(new_format)、d1.date()的返回值没有被赋值，属于无效运行，可直接一步转换日期格式：

created_at = datetime.datetime.strptime(repo['created_at'], "%Y-%m-%dT%H:%M:%SZ").date()

• 无需额外维护all_repo_data大字典，处理仓库数据时直接攒入库参数即可，减少内存开销。

三、数据库入库优化 #

• 改用批量插入：现有逻辑是单仓库单条执行INSERT，可攒50~100条仓库数据后用cursor.executemany批量插入，大幅降低网络交互开销，入库速度可提升数倍。
• 优化MySQL配置：如果数据量较大，可临时关闭非必要索引、调整事务提交策略，插入完成后再重建索引，进一步提升写入速度。
• 使用连接池管理MySQL连接：避免连接超时、重复创建连接的开销，提升稳定性和写入效率。

附加注意事项 #

GitHub认证用户的API请求配额为5000次/小时，优化重复请求后可大幅降低配额消耗，避免因为触发限流导致的阻塞等待。

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