mysql数据超过500w_Mysql数据过了500W如何优化？月薪从5K到25K

很多系统设计的时候没有考虑到数据的暴涨，后期真爆了，抓瞎。。。本文仅提供一些优化思路。

都是个人实战的总结

注：目前本人未接触过几十亿数据量级处理，所以真要玩这个级别的，我的这些小把戏估计就没用了，请自行斟酌。

1，优化你的查询Sql

绝大部分性能问题是查询效率低，那么首先找出你的sql代码，explain一下吧。

什么？explain不知道是什么？？问度娘去！

另外，相关优化技巧很多，难度不大，自己百度去吧！

2，设计好索引

千百万级数据用索引查询跟不使用索引，效率差100倍以上。

当然索引的使用也有很多坑，以前碰到一个“高手”，把所有字段都索引了，我了个去(注意索引会引出

额外的性能问题的，比如插入会稍慢，这里要有个权衡)

要说坑的话：比如同时使用多列的数据做查询条件，如何设计索引？哪些情况索引失效？等等，百度去！

3，读写分离

就是用两台或者多台主机做集群，一般是一写多读(一台mysql只写入，剩下的用来读取，

写入的数据要实时的从写库同步到读库)这个配置起来也比较简单，

唯一要说的是代理插件的选择，推荐360开源的atlas，用法很简单，实际使用中也没有

太多bug。

要说坑的话：运维要多练练，中间万一出错的情况下，导致数据不同步了咋办？百度去！

另外，因为写库与读库之间同步难免有毫秒级误差，所以某些数据刚写入立即就要读的情况下，

就不能从读库里读取了，咋办？这次不用百度了，告诉你，atlas里面有方案！自己找

4，分库

一般来说，数据库是安装在一台机器上，一个Mysql实例，我们就这么死心眼的在这个Mysql上

创建一个数据库，然后在里面弄一堆表做业务。。。。然后出去吹牛我们是程序猿。。。

其实这种程序猿工资真心高不了。。。好吧，说的有点远，直接说方案：

尽量分拆几个库，根据业务，比如订单库、用户库、日志库等等。。。

这样什么好处呢？

当以上1,2,3搞不定的时候，你把不同的库分别安装到不同的机器上啊，每个库由一台专门

的闪闪发光的Dell高配服务器来跑，多开心？

不过这样的话也还是会有很多副作用，比如原来都在一个库里，做事务很简单，现在弄了一大堆库

事务不好办，另外如果考虑到数据库之外的因素，比如代码跟着做了微服务，那事务可能要考虑

分布式事务了，各种补偿机制难免了。。。。

优点和缺点总是相辅相成！

5，水平拆分表

单表太大了，怎么办？可以把这个表的数据分成多个表，但是这里有个原则，一定不能给编码造成额外的

负担，原来写 select a from A，还得是这个！不能变！不然一切都没意义了。好在Mysql本身就有这个机制。

你啥都不用管！

拆分时，有很多拆分原则，有根据hash的，有根据时间的。。。。看业务需要吧，比如说一个表，我们只关注

当年度数据，那么根据时间拆分就行；如果使用索引查询，那么hash的不错。

有利有弊：拆分完了，你备份个表看看时间消耗吧。。。。运维的同事累了，另外，拆分以后最大的弊端是

拆分原则与用法的匹配，如果没有严格设计好，后面的用法跟拆分原则不一致，这绝对是个灾难！耗时百倍甚至千倍

增长就是家常便饭

这一步步下来，千万级，亿级数据基本上差不多了！但是成本也是越来越高，用法也要越来越谨慎。

先这样吧，有问题欢迎评论交流！