设计表结构（建模）的考虑因素

        1.首先根据产品设计进行需求文档的编写，对需求文档进行分析后，将分析出的业务需求进行分层次二次分析，再推导出具体的表结构，明确需求之后，进行具体字段的创建

        不应该针对整个系统进行数据库设计，而应该根据系统架构中的组件划分，针对每个组件所处理的业务进行组件单元的数据库设计；不同组件间所对应的数据库表之间的关联应尽可能减少，如果不同组件间的表需要外键关联也尽量不要创建外键关联，而只是记录关联表的一个主键，确保组件对应的表之间的独立性，为系统或表结构的重构提供可能性。

        采用自顶向下的思路进行数据库设计，首先分析系统业务，根据职责定义对象。对象要符合封装的特性，确保与职责（功能）相关的数据项被定义在一个对象之内，这些数据项（字段）能够完整描述该职责，不会出现职责描述缺失。并且一个对象有且只有一项职责，如果一个对象要负责两个或两个以上的职责，应进行分拆。由于对象职责的单一性以及对象之间的关系反映的是业务逻辑之间的关系，所以在领域模型中的对象存在主对象和从对象之分，从1-N或N-N的关系角度进一步分析主对象的业务逻辑，所以从对象及对象关系映射的表及表关联关系不存在删除和插入异常。

• 根据数据库三范式来进行表结构的设计。设计表结构时，就需要考虑如何设计才能更有效的查询, 遵循数据库三范式：

  • 第一范式：（1NF）数据表中每个字段都必须是不可拆分的最小单元，是对属性的原子性约束，也就是确保每一列的原子性；

  • 第二范式：（2NF）满足一范式后，表中每一列必须有唯一性，都必须依赖于主键，是对记录的唯一性约束，要求记录有唯一标识，即实体的唯一性； 

  • 第三范式：（3NF）满足二范式后，表中的每一列只与主键直接相关而不是间接相关(外键也是直接相关)，是对字段冗余性的约束，即任何字段不能由其他字段派生出来，它要求字段没有冗余。

        注意：没有最好的设计，只有最合适的设计，所以不要过分注重理论。三范式可以作为一个基本依据，不要生搬硬套。设计出的表要尽可能减少数据冗余，确保数据的准确性，有效的控制冗余有助于提高数据库的性能。当然，适当的数据冗余又能加快查询，数据冗余究竟是好是坏还是要根据自己所做的项目进行合理的取舍。有时候可以根据场景合理地反规范化，当数据库模型数据量相对比较庞大时，为了提高数据库的运行效率，常常需要降低范式标准：适当增加冗余，达到以空间换时间的目的。

        A：保留冗余字段：当两个或多个表在查询中经常需要连接时，可以在其中一个表上增加若干冗余的字段，以避免表之间的连接过于频繁，一般在冗余列的数据不经常变动的情况下使用。

        B：增加派生列：派生列是由表中的其它多个列的计算所得，增加派生列可以减少统计运算，在数据汇总时可以大大缩短运算时间, 前提是这个列经常被用到, 这也就是反第三范式。

        C：数据表拆分：主要就是垂直拆分和水平拆分。

        水平拆分:将记录散列到不同的表中，各表的结构完全相同，每次从分表中查询, 提高效率。

        垂直拆分:将表中大字段单独拆分到另外一张表, 形成一对一的关系。

        D: 字段设计：采用一个自增数值型属性或一个随机字符串作为表的关键字(主键)；表的字段尽可能用NOT NULL；字段长度固定的表查询会更快；把数据库的大表按时间或一些标志分成小表；当设计模型中包含资金的流转及安全性问题时，资金方面要选择Big Decimal作为字段类型，切勿选择浮点型。在Rose 2002中，规定列有两种类型：数据列和计算列。“金额”这样的列被称为“计算列”，而“单价”和 “数量”这样的列被称为“数据列”。

        2.尽量少采用存储过程

        目前已经有很多技术可以替代存储过程的功能如“对象/关系映射”等，将数据一致性的保证放在数据库中，无论对于版本控制、开发和部署、以及数据库的迁移都会带来很大的影响。但不可否认，存储过程具有性能上的优势，经过预编译的sql语句能够尽可能的减轻数据库的压力。所以，当系统可使用的硬件不会得到提升而性能又是非常重要的质量属性时，可经过平衡考虑选用存储过程。

        3.索引设计原则

        考虑到数据库的访问量较大的情况下，应针对所有表的主键建立索引，有针对性的（针对一些大数据量和常用检索方式）建立组合属性的索引，提高检索效率。虽然建立索引会消耗部分系统资源，但比较起在检索时搜索整张表中的数据尤其当表中的数据量较大时所带来的性能影响，以及无索引时的排序操作所带来的性能影响，这种方式仍然是值得提倡的。

    索引的设计需要遵循一些已有的原则, 这样便于提升索引的使用效率, 更高效的使用索引。

1. 对查询频次较高, 且数据量比较大的表，建立索引。
2. 索引字段的选择, 最佳候选列应当从where子句的条件中提取，如果where子句中的组合比较多，那么应当挑选最常用，过滤效果最好的列的组合。
3. 使用唯一索引， 区分度越高，使用索引的效率越高。
4. 索引并非越多越好，如果该表赠,删,改操作较多，慎重选择建立索引， 过多索引会降低表维护效率。
5. 使用短索引，提高索引访问时的I/O效率，因此也相应提升了Mysql查询效率。
6. 如果where后有多个条件经常被用到，建议建立符合 索引， 复合索引需要遵循最左前缀法则， N个列组合而成的复合索引, 相当于创建了N个索引。
7. 复合索引命名规则 index_表名_列名1_列名2_列名3

比如:create index idx_seller_name_sta_addr on tb_seller(name, status, address)

        4.避免索引失效

1. 如果在查询的时候，使用了复合索引，要遵循最左前缀法则，也就是查询从索引的最左列开始并且不能跳过索引中的列。
2. 避免裸表查询，拒绝select * 从而选择需要什么就写什么，也是为了一个sql查询速度。
3. 尽量不要在 where 子句中对字段进行 null 值判断，否则将导致引擎放弃使用索引而进行全表扫描。
4. 应尽量避免在 where 子句中使用 != 或 <> 操作符，否则将引擎放弃使用索引而进行全表扫描。
5. 不做列运算where age + 1 = 10，任何对列的操作都将导致表扫描，它包括数据库教程函数、计算表达式等，都会是索引失效，从而导致sql执行速度缓慢。
6. 查询 like，如果是 ‘%aaa’ 也会造成索引失效。
7. 应尽量避免在 where 子句中使用 or 来连接条件，如果一个字段有索引，一个字段没有索引，将导致引擎放弃使用索引而进行全表扫描。如果需要用or连接，必须得保障左右两边都有索引才可以保证索引能正常使用。

        5.存储引擎的选择

1. MyISAM存储引擎

        主要特点：MySQL5.5版本之前的默认存储引擎；支持表级锁（表级锁是MySQL中锁定粒度最大的一种锁，表示对当前操作的整张表加锁）；不支持事务，外键。

        适用场景：对事务的完整性没有要求，或以select为主的应用基本都可以选用MYISAM。在Web、数据仓库中应用广泛。

      2. InnoDB存储引擎

        主要特点：MySQL5.5版本之后的默认存储引擎；支持事务；支持行级锁（行级锁是Mysql中锁定粒度最细的一种锁，表示只针对当前操作的行进行加锁）；支持聚集索引方式存储数据。

        从整个系统的角度来说我们还是要尽最大努力确保系统不会产生脏数据，单从另一个角度来说，脏数据的产生在一定程度上也是不可避免的，我们也要保证系统对这种情况的容错性。