MySQL对于大表，要怎么优化？

第一优化你的sql和索引；

第二加缓存，memcached,redis；

第三以上都做了后，还是慢，就做主从复制或主主复制，读写分离，可以在应用层做，效率高，也可以用三方工具，第三方工具推荐360的atlas,其它的要么效率不高，要么没人维护；

第四如果以上都做了还是慢，不要想着去做切分，mysql自带分区表，先试试这个，对你的应用是透明的，无需更改代码,但是sql语句是需要针对分区表做优化的，sql条件中要带上分区条件的列，从而使查询定位到少量的分区上，否则就会扫描全部分区，另外分区表还有一些坑，在这里就不多说了；

第五如果以上都做了，那就先做垂直拆分，其实就是根据你模块的耦合度，将一个大的系统分为多个小的系统，也就是分布式系统；

这个问题涉及一下几个知识点

一、一般情况表的优化主要是索引，恰当的索引能加快查询的速度，当然索引的建立与表的主要用途有关，特别是表最频繁的操作是查询、添加、删除，查询是按哪些条件进行查询。

二、所谓的大表，对于数据库来说，没有绝对大小的限制，只要操作系统的硬盘、内存合适，表在一定范围内大一点、小一点对性能影响不大。分表是一个痛苦的过程，因为从逻辑上把表分成几个部分，会把查询、添加、修改的应用程序变得相当复杂，除非万不得已，没人会这样选择。数据太大的时候，一般使用磁盘阵列来提高性能，物理上一个大文件是分片存在不同的硬盘上，不同的硬盘可以并行读取，内存组装一下，达到了高速读取的效果。

• INSERT - 一天几十万的数据不算多，如果你的磁盘配置得当不需要特别优化，想优化方法也很多，比如把写入数据缓存到某个内存里的中间层，然后取出来批量写入；比如INSERT DALAYED等异步写入技巧
• UPDATE - 只要索引设计是高效的，也没有特别的问题；如果操作时效性要求不高，同样可以批量化和异步化，比如UPDATE LOW PRIORITY
• READ - 所有语句都需要EXPLAIN确认过性能开销确保没有瓶颈，通常无条件的SELECT本身不是问题，使用LIMIT以后也不会有问题，但如果用了GROUP BY，HAVING或者在表上作统计操作，就容易有瓶颈
• 尽早做master-master，cluster replication，至少要做master-replication，直接的好处首先是降低备份难度和风险，多库同步以后你可以在临时切断replication的前提下在非生产机上冷备份；其次是读和写可以分离，假如偶尔有昂贵的查询，可以不影响生产机
• 保持对服务器内存和磁盘IO的监控，确保数据库有足够的内存，IO维持在合理的Load内，用尽可能好的硬盘
• 比较新的文章 Ten ways to improve the performance of large tables in MySQL
• 让专业DBA管理（不要dev-op）