事情的起因是，我们的一个项目经理需要对一个数据库的信息进行查询，SQL 人家都会写的。（语句已经经过处理字段名，和原有的语句不同）语句并不复杂， mysql 5.7.23
select c.APP,c.CON,c.ACT,c.term,
(select sum(AMORTIZEAMT)
from tb_amortize t1
where t1.CAM= c.CON and t1.SAP_PO_IND='F') 待摊销,
(select sum(AMORTIZEAMT)
from tb_amortize t2
where t2.CA= c.CONTRACTNO and t2.SAP_PO_IND='T') 已摊销
from tb_sync_contract c
where 1=1 and c.ACT>='2020-06-01' and c.ACT<='2020-06-30' ;
查询计划在下面，基本上半小时是没法给出数据，主要的原因是一张表的数据量有点大；
我们对于这样的表进行了SQL 查询的改写，但结果一般
1 方法，驱动表的位置的变换
我们将小的表放到了驱动表的位置，大表放到了下面
结果并没有好转
2 方法，尝试通过再次减小驱动表的方式来加速查询
select a.AP,a.CONTR,a.ACTIVEDATE,a.term,sum(b.AMORTIZEAMT) as ‘以’
from (select APPL,CONTR,ACTI,term from tb_sync_ct foe index (idx_activedate) where ACTI>='2020-06-01' and ACTI<='2020-06-05') as a
inner join tb_am as b on a.CONTRA = b.CAMA and b.SAP_PO='T';
3 方法，将合同表的数据直接导入到新的表中，基本是不到4万条数据，但和2000万的表进行查询，速度还是很慢
select a.APP,a.CONT,a.ACTIE,sum(b.AMOT) as ‘以’
from tb_sync_con_s as a
inner join tb_amo as b on a.CONTRA = b.CAM
where b.SP_P='T';
常用的方法都不奏效的情况下，我们问了顾问逻辑，主要的逻辑其实就是将每个月的一堆的记录（几万条），和另一个表的2000多万的记录进行一个计算，其中关系是 一对多的关系。
所以即使在有索引的情况下，将常用的方式方法都使用的情况下，对这样的OLAP的操作 MYSQL 还是“肌无力”。
后面我们转换了思路，MYSQL 本身在 JOIN 方面的性能差，但对于单条记录的计算还是很快的，我们不行就通过中间表的方式，将合并的计算变为单条记录，加 中间表 在次计算的方式来进行。
解决的方案也很简单, 其实就是通过解耦和单独轮休的方式,将问题解决,
主要是通过两个中间表的方式,实际上也可以用一个中间表的方式来计算.
通过这个事情,其实可以很明显的看出一个问题,为什么MYSQL在互联网企业用的风生水起,一到传统企业,业务逻辑计算复杂的企业就玩不转了.
1 MYSQL 本身的机理使然,这点就不重复的,业内都知道是怎么回事
2 业务逻辑的问题
3 传统企业缺乏 IT 方面的整合型的人才
大多数成熟的互联网企业都有DEVOPS 这个工作的职位,DEVOPS 可不光是解决系统层级的问题, 业务方面的问题,如上数据方面的操作也是需要DEVOPS来完成的. 传统型的企业原先基本上使用的是商业性的数据库,所以这方面本来是没有需求的, 但随着MYSQL的大量使用, 分库分表后的数据融合, 数据的聚合计算,等等也都充满了需求, 所以传统型企业如果想用好MYSQL DEVOPS的介入那是不可缺的存在.
如上的需求,可以做一个界面,将这些操作自动化化,需要的人员仅仅输入相关的变量参数,就可以直接将结果获得,可惜大多数传统企业,在最初并不知道这些问题,可能会导致对MYSQL的误解.
不过话说回来,DBA 不会PYTHON 估计在这年月也快说不过去了
