文章目录
1. 数据库
在了解MySQL数据库之前，我们先带着问题来了解一下数据库：数据库是什么？用来干什么？怎么实现的？
1.1 数据库是什么？
按百度百科来说，数据库是“按照数据结构来组织、存储和管理数据的仓库”，是一个长期存储在计算机内的、有组织的、可共享的、统一管理的大量数据的集合。
因此，学习数据库首先需要学习数据库的理念和结构，然后学习不同数据库类型对数据的管理方式（数据存储、数据安全、数据完整性）等，最后学习重要数据库软件的实现（底层架构，执行流程）等。
1.2 数据库的结构
首先声明，本文所讲的所有数据库指数据库系统，而不是存储物理数据的数据库。数据库系统理论上包括用于存储数据的数据库和管理数据的数据库管理系统（如MySQL）。而本文的大部分内容也是围绕着MySQL来讲的。
数据库索引
索引是对数据库表中一列或多列的值进行排序的一种结构，使用索引可快速访问数据库表中的特定信息。如果想按特定职员的姓来查找他或她，则与在表中搜索所有的行相比，索引有助于更快地获取信息。
索引的一个主要目的就是加快检索表中数据的方法，亦即能协助信息搜索者尽快的找到符合限制条件的记录ID的辅助数据结构。
数据库事务
数据库事务(Database Transaction) ，是指作为单个逻辑工作单元执行的一系列操作，要么完全地执行，要么完全地不执行。 事务处理可以确保除非事务性单元内的所有操作都成功完成，否则不会永久更新面向数据的资源。通过将一组相关操作组合为一个要么全部成功要么全部失败的单元，可以简化错误恢复并使应用程序更加可靠。一个逻辑工作单元要成为事务，必须满足所谓的ACID（原子性、一致性、隔离性和持久性）属性。事务是数据库运行中的逻辑工作单位，由DBMS中的事务管理子系统负责事务的处理。
数据库事务的一致性
事务（Transaction）是由一系列对系统中数据进行访问与更新的操作所组成的一个程序执行逻辑单元。事务是DBMS中最基础的单位，事务不可分割。
事务具有4个基本特征，分别是：原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Duration），简称ACID。
- 原子性（Atomicity）
原子性是指事务包含的所有操作要么全部成功，要么全部失败回滚，因此事务的操作如果成功就必须要完全应用到数据库，如果操作失败则不能对数据库有任何影响。
- 一致性（Consistency）
一致性是指事务必须使数据库从一个一致性状态变换到另一个一致性状态，也就是说一个事务执行之前和执行之后都必须处于一致性状态。
拿转账来说，假设用户A和用户B两者的钱加起来一共是5000，那么不管A和B之间如何转账，转几次账，事务结束后两个用户的钱相加起来应该还得是5000，这就是事务的一致性。
- 隔离性（Isolation）
隔离性是当多个用户并发访问数据库时，比如操作同一张表时，数据库为每一个用户开启的事务，不能被其他事务的操作所干扰，多个并发事务之间要相互隔离。
即要达到这么一种效果：对于任意两个并发的事务T1和T2，在事务T1看来，T2要么在T1开始之前就已经结束，要么在T1结束之后才开始，这样每个事务都感觉不到有其他事务在并发地执行。
多个事务并发访问时，事务之间是隔离的，一个事务不应该影响其它事务运行效果。这指的是在并发环境中，当不同的事务同时操纵相同的数据时，每个事务都有各自的完整数据空间。由并发事务所做的修改必须与任何其他并发事务所做的修改隔离。
不同的隔离级别：
-
Read Uncommitted（读取未提交[添加中文释义]内容）：最低的隔离级别，什么都不需要做，一个事务可以读到另一个事务未提交的结果。所有的并发事务问题都会发生。
-
Read Committed（读取提交内容）：只有在事务提交后，其更新结果才会被其他事务看见。可以解决脏读问题。
-
Repeated Read（可重复读）：在一个事务中，对于同一份数据的读取结果总是相同的，无论是否有其他事务对这份数据进行操作，以及这个事务是否提交。可以解决脏读、不可重复读。
-
Serialization（可串行化）：事务串行化执行，隔离级别最高，牺牲了系统的并发性。可以解决并发事务的所有问题。
- 持久性（Durability）
持久性是指一个事务一旦被提交了，那么对数据库中的数据的改变就是永久性的，即便是在数据库系统遇到故障的情况下也不会丢失提交事务的操作。
例如我们在使用JDBC操作数据库时，在提交事务方法后，提示用户事务操作完成，当我们程序执行完成直到看到提示后，就可以认定事务以及正确提交，即使这时候数据库出现了问题，也必须要将我们的事务完全执行完成，否则就会造成我们看到提示事务处理完毕，但是数据库因为故障而没有执行事务的重大错误。
2. 常用命令
# 显示数据库:
show databases;
# 进入数据库：
use [db_name];
# 显示数据库内的表：
show tables from [db_name];
# 显示当前所在的库名：
select databas();
# 查看当前mysql版本：
select version();
# 查看表结构：
desc [tb_name];
3. 命名规范
3.1 数据库命名规范
-
采用26个英文字母(区分大小写)和0-9的自然数(经常不需要)加上下划线’‘组成，命名简洁明确，多个单词用下划线’'分隔，
-
一个项目一个数据库，多个项目慎用同一个数据库
##3.2 数据表命名规范
3.2.1.数据表命名规范
-
采用26个英文字母(区分大小写)和0-9的自然数(经常不需要)加上下划线’‘组成，命名简洁明确，多个单词用下划线’'分隔
-
全部小写命名，禁止出现大写
-
禁用数据库相关字
-
表名称不应该取得太长（一般不超过三个英文单词）
-
表的名称一般使用名词或者动宾短语
-
用单数形式表示名称，例如，使用 employee，而不是 employees
-
表必须填写描述信息（使用SQL语句建表时）
3.2.2 取名规范
- 模块 + 功能 ： 如 login_note
3.2.3 待优化命名实例
-
冗余:
错误示例：yy_alllive_video_recomment yy_alllive_open_close_log
说明：去除项目名，简化表名长度，去”yy_" -
相同类别表命名存在差异，管理性差
错误示例：yy_all_live_category yy_alllive_comment_user
说明：去除项目名，统一命名规则，均为”yy_alllive_”开头即可 -
命名格式存在差异
错误示例：yy_showfriend yy_user_getpoints yy_live_program_get
说明：去除项目名，统一命名规则，动宾短语分离且动宾逻辑顺序统一
3.3表字段命名规范
3.3.1 字段命名规范
-
采用26个英文字母(区分大小写)和0-9的自然数(经常不需要)加上下划线’‘组成，命名简洁明确，多个单词用下划线’'分隔
-
全部小写命名，禁止出现大写
-
字段必须填写描述信息
-
禁止使用数据库关键字，如：name，time ，datetime password 等
-
字段名称一般采用名词或动宾短语
-
采用字段的名称必须是易于理解，一般不超过三个英文单词
-
在命名表的列时，不要重复表的名称
-
不要在列的名称中包含数据类型
-
字段命名使用完整名称，禁止缩写
3.3.2 字段类型规范
-
所有字段在设计时，除以下数据类型timestamp、image、datetime、smalldatetime、uniqueidentifier、
binary、sql_variant、binary 、varbinary外，必须有默认值，字符型的默认值为一个空字符值串’’，
数值型的默认值为数值0，逻辑型的默认值为数值0 -
系统中所有逻辑型中数值0表示为“假”，数值1表示为“真”，datetime、smalldatetime类型的字段没有默认值，必须为NULL
-
用尽量少的存储空间来存储一个字段的数据
使用int就不要使用varchar、char，
用varchar(16)就不要使varchar(256)
IP地址使用int类型
固定长度的类型最好使用char，例如：邮编(postcode)
能使用tinyint就不要使用smallint，int
最好给每个字段一个默认值，最好不能为null
-
用合适的字段类型节约空间
字符转化为数字(能转化的最好转化，同样节约空间、提高查询性能)
避免使用NULL字段(NULL字段很难查询优化、NULL字段的索引需要额外空间、NULL字段的复合索引无效)
少用text类型(尽量使用varchar代替text字段)
3.3.3 数据库中每个字段的规范描述
-
尽量遵守第三范式的标准（3NF）
表内的每一个值只能被表达一次
表内的每一行都应当被唯一的标示
表内不应该存储依赖于其他键的非键信息
-
如果字段事实上是与其它表的关键字相关联而未设计为外键引用，需建索引
-
如果字段与其它表的字段相关联，需建索引
-
如果字段需做模糊查询之外的条件查询，需建索引
-
除了主关键字允许建立簇索引外，其它字段所建索引必须为非簇索引
3.4 SQL语言编码规范
3.4.1 大小写规范
-
所有关键字必须大写，如：INSERT、UPDATE、DELETE、SELECT及其子句，IF……ELSE、CASE、DECLARE等
-
所有函数及其参数中除用户变量以外的部分必须大写
-
在定义变量时用到的数据类型必须小写
3.4.2 注释
注释可以包含在批处理中，在触发器、存储过程中包含描述性注释将大大增加文本的可读性和可维护性，本规范建议：
-
注释以英文为主，实际应用中，发现以中文注释的SQL语句版本在英文环境中不可用，为避免后续版本执行过程中发生某些异常错误，建议使用英文注释
-
注释尽可能详细、全面创建每一数据对象前，应具体描述该对象的功能和用途，传入参数的含义应该有所说明，如果取值范围确定，也应该一并说明，取值有特定含义的变量（如boolean类型变量），应给出每个值的含义
-
注释语法：单行注释、多行注释
单行注释：注释前有两个连字符（–）对变量、条件子句可以采用该类注释
多行注释：符号之间的内容为注释内容，对某项完整的操作建议使用该类注释
-
注释简洁，同时应描述清晰
-
函数注释：
编写函数文本–如触发器、存储过程以及其他数据对象–时，必须为每个函数增加适当注释，该注释以多行注释为主，主要结构如下：
CREATE PROCEDURE sp_xxx
注释：
- 单行注释：#注释文字
- 单行注释：–注释文字
- 多行注释：/注释文字/
扫一扫
279
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
