单表设计与优化
1）设计规范化表，消除数据冗余（以使用正确字段类型最明显）：
数据库范式是确保数据库结构合理，满足各种查询需要、避免数据库操作异常的数据库设计方式。满足范式要求的表，称为规范化表，范式产生于20世纪70年代初，一般表设计满足前三范式就可以，在这里简单介绍一下前三范式。
第一范式（1NF）无重复的列
所谓第一范式（1NF）是指在关系模型中，对域添加的一个规范要求，所有的域都应该是原子性的，即数据库表的每一列都是不可分割的原子数据项，而不能是集合，数组，记录等非原子数据项。
第二范式（2NF）属性
在1NF的基础上，非码属性必须完全依赖于码[在1NF基础上消除非主属性对主码的部分函数依赖]
第三范式（3NF）属性
在1NF基础上，任何非主属性不依赖于其它非主属性[在2NF基础上消除传递依赖。
通俗点讲：
第一范式：属性(字段)的原子性约束，要求属性具有原子性，不可再分割；
第二范式：记录的惟一性约束，要求记录有惟一标识，每条记录需要有一个属性来做为实体的唯一标识，即每列都要和主键相关。
第三范式：属性(字段)冗余性的约束，即任何字段不能由其他字段派生出来，在通俗点就是：主键没有直接关系的数据列必须消除(消除的办法就是再创建一个表来存放他们，当然外键除外)。即：确保每列都和主键列直接相关,而不是间接相关。
如果数据库设计达到了完全的标准化，则把所有的表通过关键字连接在一起时，不会出现任何数据的复本(repetition)。标准化的优点是明显的，它避免了数据冗余，自然就节省了空间，也对数据的一致性(consistency)提供了根本的保障，杜绝了数据不一致的现象，同时也提高了效率。
（2）适当的冗余，增加计算列：（实际开发中必须思考的点）
数据库设计的实用原则是：在数据冗余和处理速度之间找到合适的平衡点。
满足范式的表一定是规范化的表，但不一定是最佳的设计。很多情况下会为了提高数据库的运行效率，常常需要降低范式标准：适当增加冗余，达到以空间换时间的目的。比如我们有一个表，产品名称，单价，库存量，总价值。这个表是不满足第三范式的，因为“总价值”可以由“单价”乘以“数量”得到，说明“金额”是冗余字段。但是，增加“总价值”这个冗余字段，可以提高查询统计的速度，这就是以空间换时间的作法。合理的冗余可以分散数据量大的表的并发压力，也可以加快特殊查询的速度，冗余字段可以有效减少数据库表的连接，提高效率。
其中”总价值”就是一个计算列，在数据库中有两种类型：数据列和计算列，数据列就是需要我们手动或者程序给予赋值的列，计算列是源于表中其他的数据计算得来，比如这里的”总价值”
在SQL中创建计算列：
create table goods(id int auto_increment not null,c1 int, c2 int, c3 int as (c1+c2), //这个就是计算列啦primary key(id))
（3）索引的设计：
表优化的重要途径，百万级别的表没有索引，注定卡死。
MySQL的分区
MySQL分区表是在数据库层面，MySQL自己实现的分表功能，在很大程度上简化了分表的难度。物理存储上分区存储,每个分区有独立的文件,应用程序上还是一张表Range（范围）–这种模式允许将数据划分不同范围。例如可以将一个表通过年份划分成若干个分区。MySQL5.1开始支持表分区
RANGE分区 -根据范围分区，范围应该连续但是不重叠，使用PARTITION BY RANGE, VALUES LESS THAN关键字。不使用COLUMNS关键字时RANGE括号内必须为整数字段名或返回确定整数的函数。
List（预定义列表）–这种模式允许系统通过预定义的列表的值来对数据进行分割。
Hash（哈希）–这中模式允许通过对表的一个或多个列的HashKey进行计算，最后通过这个Hash码不同数值对应的数据区域进行分区。例如可以建立一个对表主键进行分区的表。
Key（键值）-上面Hash模式的一种延伸，这里的Hash Key是MySQL系统产生的。
分区的好处是：
可以让单表存储更多的数据
分区表的数据更容易维护，可以通过清楚整个分区批量删除大量数据，也可以增加新的分区来支持新插入的数据。另外，还可以对一个独立分区进行优化、检查、修复等操作
部分查询能够从查询条件确定只落在少数分区上，速度会很快
分区表的数据还可以分布在不同的物理设备上，从而搞笑利用多个硬件设备
可以使用分区表赖避免某些特殊瓶颈，例如InnoDB单个索引的互斥访问、ext3文件系统的inode锁竞争
可以备份和恢复单个分区
分区的限制和缺点：
一个表最多只能有1024个分区
如果分区字段中有主键或者唯一索引的列，那么所有主键列和唯一索引列都必须包含进来
分区表无法使用外键约束
NULL值会使分区过滤无效
所有分区必须使用相同的存储引擎
MySQL从5.1开始支持分区功能。分区一句话就是：把一张表按照某种规则（range/list/hash/key等）分成多个区域（页/文件）保存。
MySQL的分表
为什么我们需要分表：
当一张的数据达到几百万时，你查询一次所花的时间会变多，如果有联合查询的话，我想有可能会死在那儿了。分表的目的就在于此，减小数据库的负担，缩短查询时间。
mysql中有一种机制是表锁定和行锁定，为什么要出现这种机制，是为了保证数据的完整性，我举个例子来说吧，如果有二个sql都要修改同一张表的同一条数据，这个时候怎么办呢，是不是二个sql都可以同时修改这条数据呢？很显然mysql对这种情况的处理是，一种是表锁定（myisam存储引擎），一个是行锁定（innodb存储引擎）。表锁定表示你们都不能对这张表进行操作，必须等我对表操作完才行。行锁定也一样，别的sql必须等我对这条数据操作完了，才能对这条数据进行操作。如果数据太多，一次执行的时间太长，等待的时间就越长，这也是我们为什么要分表的原因。
单库数据库-->数据库读写分离-->缓存技术-->搜索技术-->数据的垂直拆分-->数据的水平拆分
MySQL的分库
大型网站解决存储瓶颈的问题，我们要找准存储这个关键点，因为数据库其实是存储和运算的组合体，但是在我们这个场景下，存储是第一位的，当存储是瓶颈时候我们要狠下心来尽量多的抛弃数据的计算特点，所以上文中我提出我们数据库就不要滥用计算功能了例如触发器、存储过程等等。
数据库剥离计算功能不代表不要数据的计算功能，因为没有数据的计算功能数据库也就没价值了，那么我们要将数据库的计算功能进行迁移，迁移到程序里面，一般大型系统程序和数据库都是分开部署到不同服务器上，因此程序里处理数据计算就不会影响到数据库所在服务器的性能，就可以让安装数据库的服务器专心服务于存储。
我们要尽一切可能的把数据库的变化对服务层的影响降到最低，最好是数据库做拆分后，现有业务不要任何的更改，那么我们就得设计一个全新的数据访问层，这个数据访问层将数据库和服务层进行解耦，任何数据库的变化都由数据访问层消化，数据访问层对外接口要高度统一，不要轻易改变。
如果我们设计了数据访问层来解决数据库拆分的问题，数据访问层加上数据库其实就组合出了一个分布式数据库的解决方案，由此可见拆分数据库的难度是很高的，因为数据库将拥有分布式的特性，而分布式开发就意味开发难度的增加。
对于分布式事务的处理，我们尽量要从具体问题具体分析，不要一感觉这个事务操作本质是分布式事务就去寻找通用的分布式事务技术手段，这样的想法其实是回避困难的思想，结果可能会是把问题搞得更加复杂。
)
