MYSQL数据库优化

     根据不同业务场景有不同的侧重，优化的策略不同，比如数据量、访问量（QPS每秒查询率）、并发量、读写比例、数据是否快速增长、数据需不需要强一致？对于一些典型的场景可能会有成熟的解决方案。

优化SQL和索引

很多情况下，这一步做的并不到位，甚至有的只做了根据sql去建索引，根本没对sql优化，除了最简单的增删改查外，想实现一个查询，可以写出很多种查询语句，不同的语句，根据你选择的引擎、表中数据的分布情况、索引情况、数据库优化策略、查询中的锁策略等因素，最终查询的效率相差很大；优化要从整体去考虑，有时你优化一条语句后，其它查询反而效率被降低了，所以要取一个平衡点；即使精通mysql的话，除了纯技术面优化，还要根据业务面去优化sql语句，这样才能达到最优效果；

缓存
Memcached,Redis缓存技术来缓解数据库的读取压力

主从复制或主主复制

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

分区表
mysql自带分区表，对应用是透明的，无需更改代码,但是SQL语句是需要针对分区表做优化的，SQL条件中要带上分区条件的列，从而使查询定位到少量的分区上，否则就会扫描全部分区。不同业务场景，选择不同的shading key

1)时间

和数据回收类似

2)随机字段

垂直拆分
根据你模块的耦合度，将一个大的系统分为多个小的系统，也就是分布式系统。

水平切分

针对数据量大的表，这一步最麻烦，最能考验技术水平，要选择一个合理的sharding key,为了有好的查询效率，表结构也要改动，做一定的冗余，应用也要改，sql中尽量带sharding key，将数据定位到限定的表上去查，而不是扫描全部的表；

选择不同的存储引擎

 根据不同业务选用不同存储引擎     

mysql的优化一般都是按照这个步骤去演化的，成本也是由低到高。性能优化是无止境的，当性能可以满足需求时即可。注意不要过度优化，也不用过早的优化。