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字作为正文缩略，存进缓存。