开头还是介绍一下群，如果感兴趣PolarDB ,MongoDB ,MySQL ,PostgreSQL ,Redis, OceanBase, Sql Server等有问题，有需求都可以加群群内有各大数据库行业大咖，可以解决你的问题。加群请联系 liuaustin3 ，（共3400人左右 1 + 2 + 3 + 4 +5 + 6 + 7 + 8 ）(1 2 3 4 5 6 7 8群已经爆满 9群 为纯聊天群，默认不加入不得发广告，自己公众号文章链接等，发一次直接踢，加入8群，开10群PolarDB专业学习群115+)
其实作为PolarDB的布道师，至少去年给我颁发了一个奖章。咱们不能白让人阿里云给颁发一个这样的奖白颁。
作为一个使用快5年的人，咱们的传递点正能量。
阿里 PolarDB 不垃圾，由serverless引发的一场回怼！（2）--他能切库业务不闪断？
阿里 PolarDB 真垃圾，由serverless引发的一场回怼！（1）
最近有人问，都是MySQL为什么用法，SQL写法都是一样的，怎么就到了PolarDB for MySQL上，突然变快了。
其实这个问题很多迁移MySQL到PolarDB for MySQL后的人都有体会，今天我们来说说原因。首先在SQL查询中，JOIN的查询我们最怕什么，或者DBA最反感什么。
你猜出来了吗？ 对 left join
在很多开发者的脑子里，基本上对于SQL是一种镂空的状态，他们的SQL在JOIN上的撰写，只有一种模式left join。
为什么
1 不会出错，表和表之间的计算使用LEFT JOIN 是最不用动脑子了的
2 抄开发人员的很多SQL都不是自己写的，都是上一个项目的留下来的SQL 然后抄就行了。
3 使用了left join right join后会产生查询时的连接顺序无法进行优化，如三个表四个表的JOIN，优化引擎是无法进行连接顺序的调优的。
然后你问他LEFT JOIN 的含义你懂吗，他都说必须要用LEFT JOIN但你在细问，INNER JOIN才是他们需要的逻辑。
所以MYSQL的SQL优化器，他们只按开发人员写的方式，LEFT JOIN来运行，那么会产生很多不需要的数据，最后在MYSQL的 server层在进行过滤，性能非常的差。
PolarDB for MySQL,在使用时他就是一个MySQL，但是他被优化了，在JOIN上他就被优化了。
当MySQL被切换到PolarDB FOR MySQL后，会做如下的事情
减少处理的表数量，在满足特定条件（如 LEFT JOIN 的 ON 条件为 FALSE）时，系统可以直接删除对应的表及其条件，将字段转换为 NULL 。 利用唯一性简化查询，在 LEFT JOIN + UNIQUE 场景下，如果在连接条件外没有对该表的引用，且满足唯一性要求，则可以删除该表及其连接条件 。 消除冗余的自我连接（Self Join），当一个表与另一个具有包含关系的表做内连接或半连接（Semi Join）时，如果满足等值推导和唯一性条件，可以用源表列替代目标表列并删除冗余的目标表 。 利用外键约束（Foreign Key Join），基于外键关系，如果连接条件能推导出等值关系且满足引用完整性，系统可以消除对被引用表的 JOIN，简化执行计划
这也是为什么一些复杂的MYSQL查询到了PolarDB后直接提速的一个根本原因之一。
因为这样处理后，简化的JOIN查询中的多余的表，多余的列，直接就会降低CPU的计算，和内存的占用，在SQL加速的同时，他的性能消耗还远低于MYSQL数据库本身。
这是基于数据查询中的规则中的三个信息掌握后的推理后的结果
1 约束推理（Constraint Inference）：主键、唯一键、外键
2 函数依赖（Functional Dependency）：列之间的决定关系
3 语义等价性（Semantic Equivalence）：保证重写前后结果一致
所以现在你知道为什么从MySQL迁移后，到了PolarDB FOR MYSQL上运算速度变快的根本原因。
最后一句，注意POLARDB FOR MYSQL分为两个大版本，你如果想拥有上面的功能，要使用PolarDB for MySQL 8.02这个大版本。
