MYSQL 使用的三个阶段，where are you

估计这个标题不少人会进来看看什么阶段，where am I.  这里并不是要讲技术,所以想获得“秘籍”的同学可以绕道了，这里讨论的是一个更大的方向. 

MYSQL 在各大传统企业用的越来越多,问题也是越来越多,在传统企业使用MYSQL会经历三个过程.

1  初期,兴奋期, OMG 我们单位用了MYSQL 可算和互联网接近了, 我们整体的IT的架构也变得更亮眼了, 有没有一种 fasion的感觉.  

2  疑问期,随着MYSQL的使用的数量越来也多,问题也是凸显,例如数据分析用ORACLE的方法在MYSQL里面就不灵光了, 业务分析的人员估计是第一个抱怨的, 大家都希望一个新的东西上线,会比原来的好,怎么就比原来的难用了

3 成熟期, 各种问题的坑已经摸清楚了, mysql 能做什么,不能做什么,通过什么方法将不能做的问题弥补了,完善了,让抱怨的声音降低了,那也就成熟了.

在使用中的三个阶段和过程, 部分传统企业都止步于第二个阶段.

WHY , 

如果你认为MYSQL 他就是一个数据库, 或者认为任何数据库的问题都应该数据库来解决,或者某个软件来解决,那你停留在第二个阶段可能性就比较大. MYSQL 数据库的使用会带出一个生态,一个完成整体数据流转的生态.

MYSQL 本身是一个标准的OLTP 的数据库,也就是说他不适合去做OLAP ,数据分析的工作, 大部分传统企业的使用者对这点的认知并不明确,部分的抱怨也是从这里来的. 当你的企业大面积部署了 MYSQL ,那么很高兴,你已经从第一个兴高采烈的阶段, 到达了第二个阶段, 几家欢喜几家愁.

愁到底来自于哪里,愁来自于数据分析和非专业的人员对数据库数据的获取的问题,当然你可以说一句, 让大数据来完成呀

随之而来的是成本的问题, 如人员的成本,时间的成本 ..........   并且如果人家没有大数据部门,你怎么办.很多需求都是灵活的, 大数据部门的不灵活性也在这里展露无疑.  需求和满足不了的需求就产生了矛盾，最终MYSQL 就成了背锅侠。

第三个阶段对传统企业来说的问题核心来自于数据的融合和合并,让数据更便于数据的分析和提取,让业务人员更快的通过SQL来获取数据,这是使用MYSQL经历的最后的一个阶段,成熟的阶段.

为什么这个阶段很难, 三不管

1  在程序设计的初期,分库了 分表了, 那都是为了业务逻辑和性能设计的, 有人管你业务人员查询的方便性吗?   没人管

2  在数据库端, DBA 主要还是满足线上业务的稳定性,有人管业务人员查询数据的不便吗?  

3  业务人员本身不是专业的人员,在一个项目的建立时期,一直到后面估计都不会参与系统设计，并具有话语权,最终只有到系统都落地了,才发现有问题, 估计他们自己也管不了

最后一个阶段有什么方法解决这个问题,

1  初期软件设计不用MYSQL ,用其他的数据库 TIDB ,POSTGRESQL , 当然也可以继续走传统的商业数据库的路

2  和互联网企业一样,走大数据,人家互联网是兵强马壮, 技术都是顶尖的,什么流式计算, FLINK  ,给你堆, 业务人员自然提提需求就好

3  传统的数据融合,找一台强悍的机器,装上MYSQL 然后做多源复制,汇总库,然后单独做优化,让这个库为业务人员的统计分析查询做出"贡献"

4 找其他的解决方案,例如在程序设计初期,就考虑这个问题

5  通过自己的程序员,用程序的方式处理这些数据,并计算出结果

6  通过免费的OLAP 的数据库产品来低成本的解决这方面的问题

解决问题的方法千千万,那种更好,成本更低（学习成本，维护成本）, 是事前解决,还是事后解决,最后都需要解决, 所以你是在那个MYSQL 使用的阶段是?