mysql表太大怎么解决?
解决方法如下:
第一优化你的sql和索引;
第二加缓存,memcached,redis;
第三以上都做了后,还是慢,就做主从复制或主主复制,读写分离,可以在应用层做,效率高,也可以用三方工具,第三方工具推荐360的atlas,其它的要么效率不高,要么没人维护;
第四如果以上都做了还是慢,不要想着去做切分,mysql自带分区表,先试试这个,对你的应用是透明的,无需更改代码,但是sql语句是需要针对分区表做优化的,sql条件中要带上分区条件的列,从而使查询定位到少量的分区上,否则就会扫描全部分区,另外分区表还有一些坑,在这里就不多说了;
第五如果以上都做了,那就先做垂直拆分,其实就是根据你模块的耦合度,将一个大的系统分为多个小的系统,也就是分布式系统;
第六才是水平切分,针对数据量大的表,这一步最麻烦,最能考验技术水平,要选择一个合理的sharding key,为了有好的查询效率,表结构也要改动,做一定的冗余,应用也要改,sql中尽量带sharding key,将数据定位到限定的表上去查,而不是扫描全部的表;
SQL多表修改?
我理解题主问的是有100个表,这100个表结构完全一样,要给这100个表“同时”alter table,而不是在这100个表上面同时update数据。
结论是:没什么好的办法,只能挨个改。
这里面涉及两个问题:
1.表比较大的情况下,改表结构锁表时间很长;有主从同步的时候,改表会导致从库延迟。
这个可以用
pt-online-schema-change
来解决,可以把改表结构对线上系统的影响降到最低(用新结构建空表-逐条复制数据-rename,同时用触发器保证复制过程中对数据的增删改也应用到新表上,这些操作都可以不引起可观延迟地同步到从库)2.改表结构有先后,改的过程中不能保证每个分表结构一致。如果正常挨个改的话,不一致是肯定存在的,没法解决,只能让程序尽量兼容。或者用online-schema-change类似的思路,把改表的前两个步骤做了(建空表,复制并同步数据),最后统一rename,这样其实还是有一瞬间100个表不完全一致,但是能把不一致的时间缩短到最小。——以前某公司就有这样的100个表,而且 ORM还在内存中缓存了表结构,导致改表结构造成的影响很大。最早的时候一改表结构代码就报错,因为有表结构缓存,只要结构变了拼的SQL语句就会出问题,只能改完立刻重启web服务清除缓存。为了解决这个问题,就改用mysql返回的metadata来生成ORM对象,让读查询都脱离这个表结构缓存。然后对这种100个表不一致问题,在这100个表之外建一个单独的结构表xxx_struct,这个表不存数据,只用它来生成表结构缓存,在改表结构的流程上做个规范,加字段的时候先改存数据的表结构,然后再改_struct,删字段相反,总之保证_struct表比真实表字段少,就没啥问题了。mysql频繁写入有什么优化方法没?
1.优化数据结构,每张数据表字段4-5个,加上索引。还可以将不同的种类的数据存入不同的数据库。减少单个数据库的压力。
2.写入数据只是存的问题,问题在于读取数据会变慢。建议使用缓存memcache,redis在向你招收哦。将用户数据存入内存,再次读取避免从数据库查找。
3.分布式,搞集群,扩大配置。
一条新闻的相关信息,来源,作者,正文,这些基本不变咯,除了正文可能文字比较多,其他的你可以存进缓存,正文的话,你这里可以把前面200字作为正文缩略,存进缓存。

