mysql设计规范和原则

DB设计流程：

1，需求分析

2，ER设计

3，物理设计

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

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

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

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

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

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

    五、数据库表索引规范
        命名简洁明确,例如：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. 反范式设计提升效率

详细解析：

一、核心原则
        不在数据库作运算;
        cpu计算务必移至业务层;
        控制列数量(字段少而精,字段数建议在20之内);
        平衡范式与冗余(效率优先；每每牺牲范式)
        拒绝3B(拒绝大sql语句：big sql、拒绝大事物：big transaction、拒绝大批量：big batch);
 
    二、字段类原则
        用好数值类型(用合适的字段类型节约空间);
        字符转化为数字(能转化的最好转化,一样节约空间、提升查询性能);
        避免使用NULL字段(NULL字段很难查询优化、NULL字段的索引须要额外空间、NULL字段的复合索引无效);
        少用text类型(尽可能使用varchar代替text字段);
     
    三、索引类原则
        合理使用索引(改善查询,减慢更新,索引必定不是越多越好);
        字符字段必须建前缀索引;
        不在索引作列运算;
        innodb主键推荐使用自增列(主键创建聚簇索引,主键不该该被修改,字符串不该该作主键)(理解Innodb的索引保存结构就知道了);
        不用外键(由程序保证约束);
     
    四、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;
        请使用同类型比较;
        打散批量更新;