作为数据库核心成员如何让淘宝不卡顿一点,淘宝app卡顿( 二 ) _为什么淘宝一上就卡

文章插图
初始框架
（3）分析我们的架构定位
淘宝数据库团队当时使用映射框架（hibernate/ibatis）作为数据库交互入库，为了不让他们修改代码，那我们只能在ibatis/hibenate这类映射框架之下。
同时jdbc是与底层数据库交互的Java数据库连接驱动程序，是基础能力，我们要使用它，而不是改造它。
结论：我得把TDDL安插于ibatis/jdbc之间，于是有了第一张架构图：

文章插图
TDDL的定位
3.4 总结，我们能做什么？

文章插图
结合我们的目标，通用方法，大前提以及架构定位，分析下我们能做和不能做的。
不能做的：
索引，因为这个是设计阶段，强业务相关。与大前提冲突：我们不参与业务。能做的：
语法优化排除sql问题下推优化分表分库（自动水平分表，水平分库）读写分离（读写分离/分布式化与动态扩容）四我们如何做？
4.1 语法优化
为达到语法优化的目的，我们需要具备什么能力？
简单来说：
我们需要认识这个别人提交给我的sql 。我能拆解sql 。优化与重组这个sql 。

文章插图
专业点来说：语义分析能力。
sql解析sql规则制定sql优化sql重组

文章插图
因此：我们需要设计一个sql解析器，sql优化器。
4.1.1 解析器
解析器的核心是词法分析、语法语义分析，也就是说来了一条 select/update/insert/delete语句，你能认识它，而且你知道下一步该怎么处理，同时为后面的优化器打下基础。
核心：将sql解析为一棵语法树。
例：
SELECT id, member_id FROM wp_image WHERE member_id = ‘123’

文章插图
sql语法树：

文章插图
4.1.2 优化器
核心：
在sql解析成sql语法树后，使用sql优化规则(1. 语法优化 2. 下推优化) ，通过对树进行左旋，右旋，删除子树来对语法树进行重构sql语法树。将重构的语法树进行遍历得到优化后的sql 。（1）语法优化
函数提前计算a. id = 11=> id = 2判断永真/永假式1 = 1 and id = 1 => id = 10 = 1 and id = 1 => 空结果合并范围id > 1 or id永真式id > 1 and id = 3 => id = 3类型处理id = ‘1’=> id为数字类型,自动Long.valueof(1)create=‘2015-02-14 12:12:12’ => create为timestamp类型，解析为时间类型（2）下推优化
Where条件下推select from (A) o where o.id = 1=>select from (A.query(id = 1))说明：提前条件过滤，提前获取数据，减少后期计算/IO/网络成本。
JOIN中非join列的条件下推A join B on A.id = B.id where A.name = 1 and B.title = 2=> A.query(name = 1) join B.query(title = 2) on A.id = B.id说明：提前过滤，减轻后期join计算成本，达到“小表驱动”的目的。
等值条件的推导A join B on A.id = B.id where A.id = 1 => B.id = 1=> A join B.query(B.id=1) on A.id = B.id说明：同理，提前过滤。
4.1.3 总结
sql解析器负责将sql语句化为sql语法树。sql优化器负责将sql语法树利用sql优化规则，重构sql语法树。将sql语法树转化为sql语句。

文章插图
4.2 分表分库
单库单表的问题：