MySQL千万级大表优化，看这一篇就忘不掉了!

尽可能避免或者杜绝多表复杂关联，大表关联是大表处理的噩梦，一旦打开了这个口子，越来越多的需求需要关联，性能优化就没有回头路了，更何况大表关联是 MySQL 的弱项，尽管 Hash Join 才推出，不要像掌握了绝对大杀器一样，在商业数据库中早就存在，问题照样层出不穷。

SQL 中尽可能避免反连接，避免半连接，这是优化器做得薄弱的一方面，什么是反连接，半连接?

其实比较好理解，举个例子：not in，not exists 就是反连接，in，exists 就是半连接，在千万级大表中出现这种问题，性能是几个数量级的差异。

③索引优化

应该是大表优化中需要把握的一个度：

首先必须有主键，规范设计中第一条就是，此处不接收反驳。

其次，SQL 查询基于索引或者唯一性索引，使得查询模型尽可能简单。

最后，尽可能杜绝范围数据的查询，范围扫描在千万级大表情况下还是尽可能减少。

管理优化

这部分应该是在所有的解决方案中最容易被忽视的部分了，我放在最后，在此也向运维同事致敬，总是为很多认为本应该正常的问题尽职尽责(背锅)。

千万级大表的数据清理一般来说是比较耗时的，在此建议在设计中需要完善冷热数据分离的策略，可能听起来比较拗口，我来举一个例子，把大表的 Drop 操作转换为可逆的 DDL 操作。

Drop 操作是默认提交的，而且是不可逆的，在数据库操作中都是跑路的代名词，MySQL 层面目前没有相应的 Drop 操作恢复功能，除非通过备份来恢复，但是我们可以考虑将 Drop 操作转换为一种可逆的 DDL 操作。

MySQL 中默认每个表有一个对应的 ibd 文件，其实可以把 Drop 操作转换为一个 rename 操作，即把文件从 testdb 迁移到 testdb_arch 下面。

从权限上来说，testdb_arch 是业务不可见的，rename 操作可以平滑的实现这个删除功能，如果在一定时间后确认可以清理，则数据清理对于已有的业务流程是不可见的，如下图所示：

此外，还有两个额外建议，一个是对于大表变更，尽可能考虑低峰时段的在线变更，比如使用 pt-osc 工具或者是维护时段的变更，就不再赘述了。

最后总结一下，其实就是一句话：千万级大表的优化是根据业务场景，以成本为代价进行优化的，绝对不是孤立的一个层面的优化。

作者：杨建荣

编辑：陶家龙、孙淑娟

出处：转载自微信公众号杨建荣的学习笔记(ID：jianrong-notes)

（编辑：晋中站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!