mysql设计规范和原则

DB设计流程：

1，需求分析

2，ER设计

3，物理设计

需求分析的最佳实践是头脑风暴，把需求理解透彻。根据公司的现况和未来的发展，与pm一起来讨论。

ER（EntiyRelation）设计阶段要确定各个模块和模块之前的关系，用来表达的语言就是ER图，可以让人清晰的了解到表的设计和关系，工具用 workbench 来设计。

物理设计阶段，需要做具体的技术选型，选择合适的RDMS（比如Oracle、MySQL等等），设计表的字段类型，给表取一个 更好的名字。

物理设计的最佳实践和总计：

    1、数据库命名规范
        采用26个英文字母(区分大小写)和0-9的自然数(经常不需要)加上下划线'_'组成;
        命名简洁明确(长度不能超过30个字符);
        例如：user, stat, log, 也可以wifi_user, wifi_stat, wifi_log给数据库加个前缀;
        除非是备份数据库可以加0-9的自然数：user_db_20151210;  

    2、数据库表名命名规范
        采用26个英文字母(区分大小写)和0-9的自然数(经常不需要)加上下划线'_'组成;
        命名简洁明确,多个单词用下划线'_'分隔;
        例如：user_login, user_profile, user_detail, user_role, user_role_relation,
            user_role_right, user_role_right_relation
        表前缀'user_'可以有效的把相同关系的表显示在一起;
         
    3、数据库表字段名命名规范
        采用26个英文字母(区分大小写)和0-9的自然数(经常不需要)加上下划线'_'组成;
        命名简洁明确,多个单词用下划线'_'分隔;
        例如：user_login表字段 user_id, user_name, pass_word, eamil, tickit, status, mobile, add_time;
        每个表中必须有自增主键,add_time(默认系统时间)
        表与表之间的相关联字段名称要求尽可能的相同;
     
    4、数据库表字段类型规范
        用尽量少的存储空间来存数一个字段的数据;
        例如：能使用int就不要使用varchar、char,能用varchar(16)就不要使用varchar(256);
        IP地址最好使用int类型;
        固定长度的类型最好使用char,例如：邮编;
        能使用tinyint就不要使用smallint,int;
        最好给每个字段一个默认值,最好不能为null

    5、数据库表索引规范
        命名简洁明确,例如：user_login表user_name字段的索引应为user_name_index唯一索引;
        为每个表创建一个主键索引;
        为每个表创建合理的索引;
        建立复合索引请慎重;

数据库设计范式：

一，第一范式又称为1NF（First Normal Form），是对关系模式的基本要求，不满足第一范式的数据库就不是关系数据库。
数据库表中的字段都是单一属性的，不可再分。这个单一属性由基本类型构成，包括整型、实数、字符型、逻辑型、日期型等。
同一列中不能有多个值，即实体中的某个属性不能有多个值或者不能有重复的属性。 如果出现重复的属性，
就可能需要定义一个新的实体，新的实体由重复的属性构成，新实体与原实体之间为一对多关系。

简而言之，第一范式就是没有重复的列。

 二，第二范式（2NF）是在第一范式（1NF）的基础上建立起来的，即满足第二范式必须先满足第一范式（1NF）。
 第二范式要求数据库表中的每个实例或行必须可以被唯一地区分。为实现区分通常需要为表加上一个列，以存储各个实例的惟一标识。

简而言之，第二范式就是属性应完全依赖于其主键。

三，满足第三范式（3NF）必须先满足第二范式（2NF）。第三范式要求数据表中如果不存在非关键字段对任一候选关键字段的传递函数依赖。
所谓传递函数依赖，指的是如果存在"A → B → C"的决定关系，则C传递函数依赖于A。

简而言之，第三范式就是任一非主键属性不应依赖于其它任何非主键属性。它是对字段冗余性的约束，即任何字段不能由其他字段派生出来，它要求字段没有冗余

数据表的关系：

在关系型数据库中，弄清各个模块（或者叫实体或者叫表）之间的关系非常重要。关系型数据库中有三种基本关系：

1. 1 - 1，比如一个国家对应一个首都
2. 1 - N，比如一个分类下可以有多个商品，一个班级有多个学生，这种关系往往存在从属关系
3. N - N，比如学生和课程，一个学生可以选多门课，不同的学生也可以选择同一门课

数据库设计原则：

1. 一般表除了“语义上”的主键之外最好有一个自增主键
2. 避免使用外键约束，触发器
3. 不要用预留字段
4. 反范式设计提高效率

详细解析：

1、核心原则
        不在数据库做运算;
        cpu计算务必移至业务层;
        控制列数量(字段少而精,字段数建议在20以内);
        平衡范式与冗余(效率优先；往往牺牲范式)
        拒绝3B(拒绝大sql语句：big sql、拒绝大事物：big transaction、拒绝大批量：big batch);
 
    2、字段类原则
        用好数值类型(用合适的字段类型节约空间);
        字符转化为数字(能转化的最好转化,同样节约空间、提高查询性能);
        避免使用NULL字段(NULL字段很难查询优化、NULL字段的索引需要额外空间、NULL字段的复合索引无效);
        少用text类型(尽量使用varchar代替text字段);
     
    3、索引类原则
        合理使用索引(改善查询,减慢更新,索引一定不是越多越好);
        字符字段必须建前缀索引;
        不在索引做列运算;
        innodb主键推荐使用自增列(主键建立聚簇索引,主键不应该被修改,字符串不应该做主键)(理解Innodb的索引保存结构就知道了);
        不用外键(由程序保证约束);
     
    4、sql类原则
        sql语句尽可能简单(一条sql只能在一个cpu运算,大语句拆小语句,减少锁时间,一条大sql可以堵死整个库);
        简单的事务;
        避免使用trig/func(触发器、函数不用客户端程序取而代之);
        不用select *(消耗cpu,io,内存,带宽,这种程序不具有扩展性);
        OR改写为IN(or的效率是n级别);
        OR改写为UNION(mysql的索引合并很弱智);
            select id from t where phone = ’159′ or name = ‘john’;
            =>
            select id from t where phone=’159′
            union
            select id from t where name=’jonh’
        避免负向% ;
        limit高效分页(limit越大，效率越低);
        使用union all替代union(union有去重开销);
        少用连接join;
        使用group by;
        请使用同类型比较;
        打散批量更新;