Mysql数据剧增后存储和检索优化方案，100%经验干货!

一、直接抛出核心问题（这个很考验实际的工作经验，请看完全文）：

业务数据快速增加之后，Mysql必然会面临检索性能不佳的问题。在我十年的工作经验中，该问题一旦出现，解决起来并不容易，需要考虑很多问题，尤其是那些有大量历史债的系统上，那简直是神坑，直接看下面的解决方案。

二、直接上解决方案（小步快跑的策略）

第一步：增加索引，优化sql（针对系统数据量刚升上来或者查询有些慢暂可接受的情况，通用的解决方案，后面还有更好的方案）

1、增加索引在一定程度上确实可以提速，但是需要考虑两件事情：

1.1、增加了索引，需要让索引生效，而不是加了之后sql语句无法触发索引，如果你不知道走没走索引，建议你执行一下explain计划，可以很清晰的看到sql索引走没有，具体看计划中的type字段，index是走了索引。

1.2、不能盲目增加索引，索引不是越多越好，需要考虑负面影响，过多的增加索引反而会对mysql的性能造成影响，因为索引增多了，mysql需要维护索引，增加索引的存储成本。

2、优化sql的方案就很多了，这里就不一一罗列了，后面单独出一集。我着重说一个方案，就是可以采用大宽表、增加冗余字段的方式，解决掉多表关联的性能低下问题。

第二步：分表分库（针对当前的检索性能已经完全无法满足需求的情况）

1、分库分表并不能从根本上解决问题，只能说临时一段时间内的解决方案。为什么这么说呢？因为不能保证业务数据不会继续增多，继续增多之后，你的小表的数据量还是会升上来，升上来之后还会面临慢查询的问题。

2、我着重说一下分库分表的负面影响：

第三步：可以采用分布式数据库、列存数据库（针对前两种都无法解决的情况，直接弃用Mysql行存数据库）

1、TiDB分布式数据库建议可以有针对性的做下技术选型，首先支持Mysql协议，业务系统改造成本很低，最理想的情况下数据同步到TiDB后，只需要换个jdbc链接即可；同时还是分布式查询，整体性能比Mysql有一定提升（后面单独出一集TiDB讲解）

2、ClickHouse列存数据库

优点：快，很快；分布式查询；有大量的引擎支持；列存数据库只检索需要的列，不同于Mysql一行一行去扫，再拿到需要的列（后面我单独出一集Clickhouse讲解，这里不详细说了）

缺点：不支持实时更新，这对于业务系统来说不可接受，所以一般建议用在业务数据的分析领域。

第四步：数据分析和业务系统分离

1、整体架构设计上来说，最好分三层，第一层是业务系统的数据库；第二层是数仓；第三层是BI数分。数分去数仓搞数据，不要直接链接业务系统执行数据分析，之前见过很多公司BI团队直接读取业务系统数据库进行数分，这样很不合适，很容易影响业务系统的检索。

第五步：也可以采用数据的离线统计，写入结果表，业务系统直接拿结果数据，避免每次实时检索。

第六步：可以借助全文搜索技术，来改进搜索业务性能，比如借助ES的能力提升全文搜索的速度（后面单独出一集ES的讲解）