按关键词阅读：
必须支持动态扩容 。
必须走分布式化路线 ， 百分百不动摇 。
3.3 结合定位 ， 分析自己能做的
3.3.1 分析我们的架构定位
（1）大前提
我们要做通用型框架 ， 不参与业务 。
从软件设计原则出发 ， 开闭原则：对扩展开放 ， 对修改关闭 。
说明：大修改就意味着不稳定 ， 因此：我们要做到尽可能少的修改原来的代码 。 在程序需要进行拓展的时候 ， 不能去修改原有的代码 ， 实现一个热插拔的效果 。
（2）当前架构现状
淘宝网主要使用hibernate/ibatis传统框架：
本文插图
初始框架
（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解析为一棵语法树 。
例：
sql语法树：
本文插图
4.1.2 优化器
核心：
在sql解析成sql语法树后 ， 使用sql优化规则(1. 语法优化 2. 下推优化) ，通过对树进行左旋 ， 右旋 ， 删除子树来对语法树进行重构sql语法树 。
将重构的语法树进行遍历得到优化后的sql 。
（1）语法优化
函数提前计算
判断永真/永假式
合并范围
类型处理
（2）下推优化
Where条件下推
说明：提前条件过滤 ， 提前获取数据 ， 减少后期计算/IO/网络成本 。
JOIN中非join列的条件下推
说明：提前过滤 ， 减轻后期join计算成本 ， 达到“小表驱动”的目的 。
等值条件的推导
说明：同理 ， 提前过滤 。
4.1.3 总结
sql解析器
负责将sql语句化为sql语法树 。
sql优化器
负责将sql语法树利用sql优化规则 ， 重构sql语法树 。
稿源：(ZAKER汽车)
【】网址：http://www.shadafang.com/c/hn092Y452G2020.html
标题：大数据&云计算|作为数据库核心成员，如何让淘宝不卡顿？( 二 )
