MySQL分身

https://time.geekbang.org/column/article/168963
https://tech.meituan.com/2014/06/30/mysql-index.html

查询优化神器 - explain命令
关于explain命令相信大家并不陌生，具体用法和字段含义可以参考官网explain-output，这里需要强调rows是核心指标，绝大部分rows小的语句执行一定很快（有例外，下面会讲到）。所以优化语句基本上都是在优化rows。

慢查询优化基本步骤
0.先运行看看是否真的很慢，注意设置SQL_NO_CACHE

1.where条件单表查，锁定最小返回记录表。这句话的意思是把查询语句的where都应用到表中返回的记录数最小的表开始查起，单表每个字段分别查询，看哪个字段的区分度最高

2.explain查看执行计划，是否与1预期一致（从锁定记录较少的表开始查询）

3.order by limit 形式的sql语句让排序的表优先查

4.了解业务方使用场景

5.加索引时参照建索引的几大原则

6.观察结果，不符合预期继续从0分析

https://cloud.tencent.com/developer/article/1663923
什么是数据复制技术？

概括来讲，数据复制是一种实现数据备份的技术。比如，现在有节点 1 和节点 2，节点 1 上存储了 10M 用户数据，直观地说，数据复制技术就是将节点 1 上的这 10M 数据拷贝到节点 2 上，以使得节点 1 和节点 2 上存储了相同的数据，也就是节点 2 对节点 1 的数据进行了备份。当节点 1 出现故障后，可以通过获取节点 2 上的数据，实现分布式存储系统的自动容错。

也就是说，数据复制技术，可以保证存储在不同节点上的同一份数据是一致的。这样当一个节点故障后，可以从其他存储该数据的节点获取数据，避免数据丢失，进而提高了系统的可靠性。

这是不是就像数据有了自己的“分身”呢？那么，分布式系统是如何实现数据“分身有术”的呢？

http://tech.it168.com/a2018/0912/5032/000005032685.shtml?%205

为什么要在分库分表的情况下做二级索引?举个例子，集群中有partition key，以订单ID做了分库分表，如果想查询乘客或司机的订单时怎么办?工程师觉得再建一个索引就可以了，但分库表时的难度就很大了。所以工程师就花很大精力写两份表，先写一个订单库，写完再写一个司机索引，再写一个乘客索引，这样还不够，MIS还需要用一、两个维度。工程师写的大部分代码都在去确保把所有索引写成功，但有时发布还会丢数据，这个问题困扰我们很久了。

　　当然这个问题我们使用了分布式事务产品也可以在技术层面解决，但使用起来有些繁琐，所以我们从另一个维度进行了尝试。假设仍然是订单ID和乘客ID的两个维度，我们实现了分身系统，把所有的来自于主库的数据更新完之后，通过binlog复制到另外一个表里面去。逻辑是自动完成的，也就相当于在做创建表的时候，创建一个索引，在分库分表情况下创建一个主key，然后在索引Key的情况下，自动把数据复制到另外一张表里，在DBProxy往下查询时，自动识别，直接查询。

　　这对于工程师来说是很大的解放，一张表里两个索引一样可以工作，当然这个也是有限制的，但它至少解决了写两张表的问题。这是我们第一个基于MySQL binlog的尝试，解决了很多业务问题，整个代码复杂度大幅下降
　　
　　第二次尝试是MySQL和ES的融合，上图是典型的架构图，业务代码从DBProxy到MySQL。这其中，我们用了canal，canal是阿里巴巴开源的binlog server的一个中间件。我们把数据通过canal同步到kafka，kafka写到ES里。

　　这样做的好处是MySQL创建表在ES里，在分钟级别甚至是秒级就可以查询到数据，体验很好。但是也会有问题，我们大部分代码都是PHP和Go，所以工程师就会觉得很麻烦，能不能提供一个MySQL协议的ES查询引擎。

　　也因为此，诞生了YASE的MySQL引擎，支持MySQL通过DBProxy去访问ES。我们曾希望所有东西都以MySQL为入口，但事实证明这并不是一个好的方案。因为ES API原生的客户端和访问协议都有其优势，灵活性和定制性都更强，如果降为MySQL标准SQL协议，反而损失很多能力，得不偿失。
　　
　　https://myslide.cn/slides/16488