mysql优化方案

前提：
用缓存，主要有两个用途：高性能、高并发。高性能：非实时变化的数据-查询mysql耗时需要300ms,存到缓存redis，每次查询仅仅1ms,性能瞬间提升百倍。高并发：mysql 单机支撑到2K QPS就容易报警了，如果系统中高峰时期1s请求1万，仅单机mysql是支撑不了的，但是使用缓存的话，单机支撑的并发量轻松1s几万~十几万。
优化方案：
1.方案陈述：
1）代码中sql语句优化。
2）数据库字段优化，索引优化。
3）加缓存， redis/memcache等。
4）主从，读写分离。
5）分区表。
6）垂直拆分，解耦模块。
7）水平切分。
2.方案对比：
1、1&2是最简单，也是提升效率最快的方式。也许有人说这两点你已经做的很好了，你的每条语句都命中了索引，是最高效的。但是你是否是为了你的sql达到最优而去建索引，而不是从整个业务上来考虑。比如，订单表上我需要增加xx索引满足某单一业务，是否就一定要加，其他方法能否解决。如果要满足所有业务的需求，那么索引就泛滥了，对于千万级以上的表来说，维护索引的成本大大增加，反而增加了数据库的内存的开销。

2、数据库字段的优化。曾经发现一高级程序员在表字段的设计上，一个日期类型，被设计为varchar类型，不规范的同时，无法对写入数据校验，做索引的效率也有差别(网(xian)友(pen)的(liao)观(zai)点(shuo)，具体差别原理不详)。

3、缓存适合读多写少更新频度相对较低的业务场景，否则缓存异议不大，命中率不高。缓存通常来说主要为了提高接口处理速度，降低并发带来的db压力以及由此产生的其他问题。你的接口时延多少？有没有被用户吐槽？有没有必要提升？好吧，我们的前台后台商家并发量太低，当我没说。

4、分区不是分表，结果还是一张表，只不过把存放的数据文件分词了多个小块，分块后。在表数据非常大的情况下，可以解决无法一次载入内存，以及大表数据维护等问题。

5、垂直拆分将表按列拆成多表，常见于将主表的扩展数据独立开，文本数据独立开，降低磁盘io的压力。

6、水平拆，这是一把最有效的牛刀。但是存在一个误区，有的人会觉得，为什么不在最开始就直接水平线拆，免去了后面迁移数据的麻烦。我个人感觉是，下定某个决策之前，必须有一个非常充分的理由。水平拆分的主要目的是提升单表并发读写能力(压力分散到各个分表中)和磁盘IO性能(一个非常大的.MYD文件分摊到各个小表的.MYD文件中)。如果没有千万级以上数据，为什么要拆，仅对单表做做优化也是可以的；再如果没有太大的并发量，分区表也一般能够满足。所以，一般情况下，水平拆分是最后的选择，在设计时还是需要一步一步走。