按关键词阅读：
本文插图
阿里妹导读：TDDL(Tabao Distributed Data Layer)是淘宝开源的一个用于访问数据库的中间件 ， 集成了分库分表 ， 主备 ， 读写分离 ， 权重调配 ， 动态数据库配置等功能 。 本文以2007年TDDL初诞生时的视角 ， 介绍TDDL是如何一步步设计成型的 ， 希望能帮助同学们简单收获：常规数据库效率问题解决思路、TDDL框架设计基本思路以及分布式数据库设计思路等 。
文末福利：《MySQL实操》技术公开课 。
时间倒转穿越回2007年年底
一觉醒来 ， 我还是照常去上班 ， 走到西溪湿地附近 ， 马路没有 ， 高楼没有 ， 有的是小山坡和金色的稻田 。 一番打听之后 ， 才知道此时没有什么西溪园区 。 没办法 ， 硬着头皮去滨江上班 ， 一刷卡 ， 才发现我并不是我 ， 我现在的身份是淘宝数据库团队的核心成员 。
此时全国上下在迎接着奥运的到来 ， 一片祥和 。 淘宝网成交额突破400亿 ， 日活用户达1000万 。 工程师们都非常兴奋 ， 磨刀霍霍 。 但是也遇到了棘手的问题 。
一 分析当前的现状
1.1 现有业务背景
淘宝网给中国市场提供了全新的购物形式 ， 在互联网的大潮下 ， 用户暴增 ， 成交量暴增 ， 公司持续飞速增长 。
截止2007年 ， 淘宝网成交额突破400亿 ， 日活用户达1000万 。
全天有1000万用户访问淘宝 。 而绝大多数用户都是在网上逛 ， 什么也不买 。
1.2 当前的问题
1.2.1 用户体验与反馈
用户普遍反馈逛淘宝卡顿 ， 操作延迟特别明显 。
1.2.2 分析核心原因
大量的用户在浏览商品 ， 并不下单 。 这个人数和场景的比例有20:1 。
说明：数据库模式事务 ， 写操作会对表或者行加写锁 ， 阻塞读操作 。
业务数据集中在一张表里 ， 如user表 。 一张表里数据破几千万 。 查询一条数据需要好几秒（单表数据量太大） 。
说明：一张表数据提升 ， 必然会导致检索变慢 ，这是必然事实 。 不论如何加索引或者优化都无法解决的 。
所有表集中在一个库里 ， 所有库集中在一个机器里 。 数据库集中在一台机器上 ， 动不动就说硬盘不够了（单机单库） 。
说明：所有业务共用一份物理机器资源 。 机器存在瓶颈：磁盘和CPU不够用且后期拓展性不佳 。
1.2.3 总结问题
20:1读写比例场景 。
单表单库数据量太大 。
小型机与单机场景 ， 抗不住当前规模 。
本文插图
当前现状
二 我要做什么？
如何满足当前每天1000万用户逛淘宝的需求 ， 且用户体验好（最基本要求：响应快） 。
如何满足未来有上亿用户的访问 ， 甚至是同时访问 ， 且用户体验好（最基本要求：响应快） 。
高筑墙 ， 广积粮 ， 积极做好准备 。
提炼核心：
提高数据库操作速度 。
同时能应对未来规模变化 。
三 我能做什么?
为实现以上两大目标 ， 我能做什么？
3.1 提高数据库操作速度 ， 通用方法
提炼常见的通用方法：
sql优化
排除语法问题 ， 烂sql
下推优化
下推的目的：提前过滤数据 -> 减少网络传输、并行计算 。
提前过滤数据
小表驱动大表等
建立索引
查询频率高的热点字段
区分度高的(DISTINCT column_name)/COUNT(*) ， 以主键为榜样（1/COUNT(*)）
长度小
尽量能覆盖常用查询字段
注意索引失效的场景
分库分表
垂直分库分表
水平分库分表
读写分离
缓存的使用
等等 。
3.2 如何应对未来的持续变化？ 
稿源：(ZAKER汽车)
【】网址：http://www.shadafang.com/c/hn092Y452G2020.html
标题：大数据&云计算|作为数据库核心成员，如何让淘宝不卡顿？
