千万级数据的全表 update 正确姿势

主要观点总结

本文介绍了在进行MySQL大数据量表更新时，如何避免直接执行全表update带来的问题。文章通过作者的实际经验，详细阐述了从简单update到分批更新策略的思考和优化过程，包括深度分页问题、使用脚本分批处理、不使用buffer pool进行数据更新的方法，以及对于主键id的生成和管理方法的讨论。同时，也分享了一些与数据库主从同步相关的知识和理解。

关键观点总结

关键观点1: 直接全表update的问题

在进行大数据量表更新时，直接执行全表update会产生大量的binlog，导致主从同步压力增大，风险较高。

关键观点2: 分批更新策略

通过编写脚本分批处理，使用limit语句进行范围查找，但存在深度分页问题，效率较低。

关键观点3: 使用no cache和强制索引优化查询效率

通过使用SQL_NO_CACHE关键字和强制使用主键索引，优化查询效率，减少数据库压力。

关键观点4: 主从同步和数据库性能问题

文章讨论了MySQL的binlog格式对主从同步的影响，以及如何通过调整更新策略来保护数据库性能。

关键观点5: 其他问题解答

解答了关于数据缓存、写缓存和change buffer的问题，以及关于多线程执行的任务分配问题。

文章预览

作者：呼呼虎 juejin.cn/post/6897185211340029966 前言 有些时候在进行一些业务迭代时需要我们对Mysql表中数据进行全表update，如果是在数据量比较小的情况下（万级别），可以直接执行sql语句，但是如果数据量达到一个量级后，就会出现一些问题，比如主从架构部署的Mysql，主从同步需要需要binlog来完成，而binlog格式如下，其中使用statement和row格式的主从同步之间binlog在update情况下的展示： 我们当前线上mysql是使用row格式binlog来进行的主从同步，因此如果在亿级数据的表中执行全表update，必然会在主库中产生大量的binlog，接着会在进行主从同步时，从库也需要阻塞执行大量sql，风险极高，因此直接update是不行的。本文就从我最开始的一个全表update sql开始，到最后上线的分批更新策略，如何优化和思考来展开说明。 正文 直接update的问题 我们前段时间需要 ………………………………