估计这个标题不少人会进来看看什么阶段，whereamI.这里并不是要讲技术,所以想获得“秘籍”的同学可以绕道了，这里讨论的是一个更大的方向.
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使用的阶段是?
carol11