因为数据库字段、索引对大小写是不敏感的，驼峰标识无意义；

所以一般采用数据库字段下划线， 实体类驼峰的命名方式

0. 字符集合
a-z A-Z 0-9 和 _ 共 63个
1. 所有字条以小写字母开头，所有名词采用单数,所以前缀都要小写
如：userIduser_id
2. 数据库对象命名规范
数据库对象={表,视图（查询）,索引,关联,存储过程（参数查询）,函数}
规则：对象名字由前缀和实际名字组成，他们之间加下划线，不要在对象名的字符之间留空格，长度不超过30字符。
[对象名字]＝[前缀]_[实际名字]
前缀：使用小写字母
表              tb
视图           vi
索引           idx
关联           rl
存储过程     sp
函数           fn
实际名字：实际名字尽量描述实体的内容，由单词或单词组合，每个单词（第一个除外）的首字母大写，其他字母小写，不以数字和_开头，单词与单词间不用下划线。
[实际名字]=[小写字母开头的单词][大写字母开头的单词]...[大写字母开头的单词 
例如：userNamepassWord userRegisterTime
[单词]=[a-z|A-Z][a-z|A-Z|0-9|_]...[a-z|A-Z|0-9|_]
例子：tb_webUservi_userOrder
3. 数据库表命名规范
表名由 前缀(tb) 接 _ 接 实际名字组成
[表名]=tb_[实际名字]
4. 字段命名规范
[字段名]=[表名简称]_[实际名字]
现在约定，[表名简称]＝[表名]的[实际名字]部分 的各个单词首字母安顺序组合
如：tb_userInfomation应用此规则，其表名简称为uI
5. 视图命名规范
[视图]=vi_[实际名字]
6. 存储过程命名规范
[存储过程名]=sp_[实际名字]_[操作名字]
[操作名字]=[insert|delete|update|calculate|confirm]
例如：sp_userState_update
7. 索引命名规范
[索引]=idx[0-9]_[表名简写]_[实际名字]
例子：idx0_uInfo_age
注：［表名简写］不同于上面的［表名简称］，它采用下面的字串简化规则。参见最后9。
8. 关联命名规范
[关联]=rl_[表名简写]_[表名简写]
例子：rl_uInfo_msg
8.数据库设计文档规范
    表名：    tb_userInformation
    作者：    XXX
    日期：    2004-12-17
    版本：    1.0
    描述：    保存用户资料
    具体内容：（以表格形式）

Oracle数据库索引
如果你在数据库方面是一个新手，又或者你对Oracle数据库不是很熟悉，那你可能会发现关于索引和构建索引策略方面的讨论资料看起来很艰涩。不过，只要你对于能满足数据库管理员日常管理相关的选项稍加注意，其实要入手还是很容易的。

　　1)b-tree索引

　　Oracle数据库中最常见的索引类型是b-tree索引，也就是B-树索引，以其同名的计算科学结构命名。每当你发布基本的没有经过进一步修改的CREATE INDEX语句时，就是在创建b-tree索引。这里不打算对b-tree索引进行更多深入的探讨，这些用户都可以自己了解。基本上这些索引存储你创建的索引所在的列值以及用来查找自身行的指向实际数据表的指针。记住，这也就意味着要进行多路查询，其中一个查询各个节点和索引的叶节点，然后才是表的行自身。这就是为什么Oracle的优化器在某种情况下会选择执行全表扫描而不执行索引查找的原因了，因为全表扫描执行起来实际上可能会更快一些。还要注意的是，如果你的索引是创建在多个列上的话，那么第一列(leading column)非常重要。假设你有一个多列索引(也称为级联索引)，索引列的排列顺序是c列到d列，你可以对使用该索引c列单独进行一次查询，但你不能使用该索引对d列冶金行一次单独的查询。

　　2)基于函数的索引

　　如果在搜索时你读取很多行，或者你的索引选择性不大，又或者你在级联索引中使用了第一列以外的列，Oracle数据库有时候会选择不使用索引。那么如果你想要执行一个大小写不敏感的搜索呢?像下面的指令：WHERE UPPER(first_name) = 'JOHN'。

　　这也不会使用first_name字段上的索引。为什么?因为Oracle不得不将UPPER函数用在该索引所有(ALL)的值上，所以还不如做一次全表扫描。所以，很多时候Oracle创建基于函数的索引就是为了这个目的。

　　3)反转关键字索引

　　你还可以看到这些反转关键字索引，而且不时还要用到这些索引。假设有一列包含了“餐厅甲”、“餐厅乙”、“餐厅丙”等类似名字。可能这不是一个很好的例子，不过关键的一点是拥有很多唯一值，但其关键字的前面一部分变化不大。因为Oracle会在将REVERSE关键字指定给b-tree前把REVERSE字符串简化，所以使用反转关键字索引可能是最好的。这样的一个索引可能更平衡、有用，搜索起来更快。

　　更多外部索引类型

　　Oracle还提供了很多更为复杂的索引类型。不过请注意，你最好全面阅读过相关的说明文档后再使用这些索引，因为它们各自都有各自特定的适用范围。

　　1)位图索引(bitmap index)

　　假设数据库表中有一列其选择性非常窄，例如性别列，该用什么类型的索引?你可能会考虑对其使用位图索引。因为位图索引正是为相异值很少的列而创建的。但需要考虑的因素还不只这些。一般而言，只有当你对表中值相宜度较小的多个不同的列都使用位图索引，这样位图索引才有用，因为你可以一起使用这些索引才能对列产生更大的选择性，否则你还是需要对这些列进行一次全表扫描。例如，对于性别列，其索引只能有两个唯一值，那么用这个索引对表的任何搜索有可能都返回一半的记录。其次，这些索引是为数据仓库而设计的，所以其假定条件是数据不会发生很大的改变。这些索引不能用来满足事务数据库或更新频繁的数据库。应该说，对位图索引的表进行更新根本没有一点效率。

　　2)位图连接索引(bitmap join index)

　　位图连接索引比位图索引更进了一步。这些索引将位图化的列完全从表数据中抽取出来，并将其存储在索引中。其假定条件是这些列集合必须一起查询。同样的，这也是为数据仓库数据库而设计的。除了在句法最后有一个WHERE子句之外，位图连接索引的创建指令就像创建位图索引的CREATE BITMAP INDEX一样。

　　3)压缩索引

　　压缩索引实际是标准b-tree索引的一个选项。压缩索引的叶节点更少，所以总的I/O数量和需要的缓存也更少。这些都意味着Oracle的优化器更可能使用这些压缩索引，而不倾向于使用标准的非压缩索引。不过，这些好处也是有代价的，当你对这些压缩索引进行存取操作时，要消耗更多的CPU来进行解压缩。而且，当你阅读关于优化器如何使用这些索引，又是如何选择合适的压缩级别的资料时，就开始变得晦涩了。不同的用户不同的设置从压缩索引中得到的好处也可能会有所不同。

　4)降序索引(descending index)

　　这是基于函数索引的一种特殊类型。降序索引可以显著优化ORDER BY x, y, z DESC子句查询的。

　　5)分区索引(partitioned index)

　　如果你的数据库中有一个分区表，你就有机会体验几种新的索引类型，从贯穿所有分区的全局分区索引(global)和集中于各个单独分区的本地分区索引(local)。这里不再进行赘述，想知道细节问题可以查询相关文献。

　　6)索引组织表(index organized table，IOT)

　　这是在Oracle 9i中引进的一种新类型表。Oracle会将级联索引及其扩展类型的索引用于表中所有的列。当所有数据都载入到索引结构之后，表就成多余的了，你尽可以将表本身删除掉。这就是索引组织表。

　　7)簇索引(cluster index)

　　基本上，簇索引就是将多个表的相同列放在一起，而对该列使用用一个簇索引。这种索引在实际应用中比较少，因为还有各种有待解决的性能问题存在。

　　8)域索引(domain index)

　　当我们创建为用户自定义数据类型(datatype)创建用户自定义索引类型(indextype)时就要使用域索引。

　　9)隐藏索引(invisible index)

　　这是Oracle 11g中推出的新特性。其创建过程和标准索引一样，但创建后对于基于代价的优化器(CBO)是不可见的。这可以让你对性能进行大型测试查询，而不会影响现有的正在运行的应用程序。

　　10)虚拟索引(virtual index)

　　这是为测试人员和开发人员准备的又一个工具。虚拟索引(不分配段空间)可以让你在不需要实际创建索引的情况下，测试新索引及其对查询计划的影响。对于GB级的表来说，构建索引非常耗费资源而且还要占用大量时间。

　　11)其他的索引类型

　　Oracle数据库还提供了很多其他类型的索引，例如用来为字符型大型二进制对象(CLOB)或其他大型文本数据构建索引的Oracle TEXT，Oracle Spatial等。有兴趣的读者可以自己查找相关资料了解。

　　都是为了优化器

　　如果你曾经广泛接触过MySQL和其他的数据库，你会发现甲骨文虽然是全球领先的数据库供应商，但它们的数据库对于用户来说用起来其实并不是很方便。提到优化器这个问题可能有点离题了，不过Oracle数据库最基本的食料就是优化器了，这的确是种挺特别的调料，而且变得越来越美味了。市面上有很多以Oracle基于代价的优化器(Cost Based Optimizer，CBO)为主题内容的书籍，专门介绍分析表和索引的技巧和策略。

　　对于数据库，除了需要一直更新你的统计信息之外，你可能还需要不断测试新的查询。使用解析计划机制，并进行优化以便减少总I/O量以及排序和合并数据的计算量，只有这样你才能获得更好的性能表现。

　　总结

　　虽然Oracle数据库的索引世界有点吓人，不过实际上你平常经常使用的索引就只有那么一些。而且，不管唱反调的人怎样诋毁，Oracle的优化器都已经设计相当出色;总体而言，Oracle很擅长于让你的数据库运行地更有效率。虽然这并不意味着你不需要对自己的SQL进行调优，不过，如果你一直保持着最新的统计信息，并让Oracle为你整理出你所需要的最小数据集的话，它能够以极快的速度满足你的需要。

写在最前面，本篇内容是在公司内部培训的一次内容，今天分享出来，希望能够对需要的朋友起到帮助，如果内容有错误，也请留言指出，感激不尽，转载请注明出处。
另外以后我会整理一个关于Mysql知识点的系列文章，感兴趣的朋友可以扫描下面的二维码加群。



------------ 废话不多说，开始正文 -----------------
一、数据库设计


三范式简单理解

– 第一范式(1NF)：字段具有原子性，不能再分(所有关系型数据库系统都满足第一范式)

– 第二范式(2NF)：一个表必须有主键,即每行数据都能被唯一的区分

– 第三范式(3NF)：一个表中不能包涵其他相关表中非关键字段的信息，即数据表不能有沉余字段
注：为了使用方便，很难完全符合 第三范式，适当冗余是需要的



MySql 存储引擎（InnoDB， MyISAM）

– MyISAM：不支持事物， 写入和读取速度比较快，适合写少，读多的场景

– InnoDB：支持事物，行锁


命名

– 表  名：下划线连接全小写单词，例：product，product_order


字段名：

– 所有字段都不允许为NULL（特殊考虑：date、datetime）

– 默认值：应考虑哪些字段不应允许有默认值

– 小写驼峰，其中：

bool型：is* 或 allow*，如isDisabled（是否禁用）或allowClose（允许关闭）
datetime类型：*Time，如startedTime
date类型（YYYY-MM-DD）：*Date，如endDate

– 关联字段名为对应AR类名首字母小写+关联字段名，如：user_id，order_id


主键：建议使用非业务字段做主键（id，int 自增）


外键：不使用外键(由程序保证约束)


注：要控制表的字段数量，根据业务规则适当的分表

二、SQL执行顺序=

FROM：对FROM子句中前两个表执行笛卡尔积生成虚拟表vt1
ON：对vt1表应用ON筛选器只有满足< join_condition> 为真的行才被插入vt2
如果 FROM 包含两个以上表则对上一个联结生成的结果表和下一个表重复执行步骤1 和 步骤2
WHERE：对vt2应用 WHERE 筛选器只有使< where_condition> 为true的行才被插入vt3
GROUP BY：按GROUP BY子句中的列对vt3中的行分组生成vt4
HAVING：对vt4应用HAVING筛选器只有使< having_condition> 为true的组才插入vt5
SELECT：处理select列表产生vt6
DISTINCT：将重复的行从vt6中去除产生vt7
ORDER BY：将vt7的行按order by子句中的列列表排序生成一个游标vc8
LIMIT：从vc8的开始处选择指定数量或比例的行生成vt9 并返回调用者

参考： https://www.cnblogs.com/annsshadow/p/5037667.html
三、索引
类型：

主键索引：primary，数据的物理存储顺序
唯一索引：unique index
普通索引：index
复合索引：最左前缀原则

选择索引的数据字段：

越小的数据类型通常更好
简单的数据类型更好
尽量避免NULL

无法使用索引的情况：


以%开头的like查询
例如：
explain select * from order where number like '%201703'



数据类型出现隐式转换的时候也不会使用索引
例如：explain select * from order where number = 20170328104740498530



复合索引的情况下，不满足最左前缀原则，则不会使用索引
例如：explain select a.* from order as a where a.uid = 1 and a.status = 2



用 or 分割开的条件，如果 or 前的条件中的列有索引，而后面的列中没有索引，那么涉及的索引都不会被用到
例如：explain select a.* from order as a where a.uid = 1 or a.status=2



字段进行运算、或格式转化后，将无法使用索引
例如：explain select a.* from order as a where from_unixtime(a.create_time, '%Y%m%d') = '20170101'



!= 、 not in 无法使用索引
例如：explain select * from order  where create_time not in (13423424232)



查询条件使用了索引，就一定会用到吗？
如果mysql估计使用索引扫描比全表扫描更慢，则不使用索引。(扫描数据超过30%，都会走全表)	



参考：

https://dev.mysql.com/doc/refman/5.5/en/optimization-indexes.html

https://www.cnblogs.com/tgycoder/p/5410057.html
四、SQL语句建议


书写SQL时要注意缩进
select 
from table1 as t1 
	 inner join table2 as t2 on t1.col1 = t2.cols
where 
group by 
having
order by
limit



INSERT：格式 NSERT INTO  TABLE1(col1, col2) VALUES (‘yayun’,23)


大量数据写入，一定要使用批量的方式：INSERT INTO  TABLE1(col1, col2) VALUES (‘yayun’,23),(‘tom’,26),(‘atlas’,32),(‘david’,25)…


避免使用 SELECT * 语句， 只返回需要的数据字段


当在SQL语句中连接多个表时, 为每个表都起别名
Select A.ID, A.col1, B.col2
from table1 A 
	inner join table2 B on A.ID=B.ID 
where 。。。



合理写WHERE子句，不要写没有 WHERE 条件的 SQL 语句


杜绝不必要的子查询和连接表，多余排序
select count(*) 
from userinfo as a
	left join user as b on a.id = b.uid 			#这个连接真的需要吗？
	left join user_bank as c on a.id = c.uid		#一个还不够，又来一个？
where uid in (7704,11027,.....)
order by a.reg_time desc			#这个排序有用吗？



合并对同一表同一条件的多次 UPDATE
update tablename set col1 = '1111'  where id = 1
update tablename set col2 = '2222'  where id = 1

这两个语句应该合并成以下一个语句
update tablename set col1 = '1111', col2 = '2222'  where id = 1



避免 IN 子句，当子句中有多个值且表数据较多时，速度下降明显，可以采用表关联查询来代替


OR 改写为 IN (OR 的效率更低)


使用 union all 替代 union (union有去重开销)


能使用 inner join 就不使用 left join（思考：left join 后的 on 条件 和  where 条件 的区别）


exists、not exists 当子查询的表很大时，性能很差，可改为 left join 或 inner join


SQL语句尽可能简单，复杂查询可以借助临时表或内存表


简单的事务，事物会锁表/行，尽可能的让事物快速执行完成


参数的传递：SQL 语句的编写，变量不要直接拼接到语句中，


结论：

尽量少的查询数据
使用子查询时，确保子查询数据量要小
合理使用索引

五、explain及其输出
作用：

显示mysql如何使用索引来处理select语句以及连接表

EXPLAIN 列的解释：


id：执行序号，数字大的先执行，数字相同，从上到下执行


select_type：查询的类型，主要是区别普通查询和联合查询、子查询之类的复杂查询

– SIMPLE：简单查询，没有使用 UNION、子查询等
例如：explain select * from user where id = 1

– PRIMARY：在嵌套的查询中是最外层的SELECT语句，在UNION查询中是最前面的SELECT语句
– SUBQUERY：子查询中的第一个 SELECT
例如： 
explain
select o.number 
from order as o
where o.uid =  (
	select a.id from user as a where a.id = 1
)

– DEPENDENT SUBQUERY：子查询中的第一个 SELECT， 并且依赖外部查询

– UNION： 使用了 UNION 的第二个 select

– DEPENDENT UNION：使用了 UNION 的第二个 select，并且依赖外部查询

– UNION RESULT：UNION 结果
例如：explain
select o.number 
from order as o
where uid in (
	select a.id from user as a where a.id in (1,10,20)
	union  
	select b.id from user as b where b.id in (11,21,31)
)

上面的写法会优化成下面这样执行
explain 
select o.number from order o 
where exists  (
	select a.id from user as a where a.id in (1,10,20) and a.id = o.uid
	union  
	select b.id from user as b where b.id in (11,21,31) and b.id = o.uid
);

– DERIVED：派生表，该临时表是从子查询派生出来的，位于FROM中的子查询
例如：explain select b.number from (select * from order as a) as b



table：查询的表

– <unionM,N>：UNION 查询结果

– < derivedN>： 派生表，FROM 子查询结果


type：访问类型

– system：这是const连接类型的一种特例，表中只有一行数据

– const：表示只有一行匹配，只读取一次，查询前读取，当查询条件是主键或唯一索引字段时（高效）
例如：explain SELECT * FROM `user` WHERE id = 501

– eq_ref：唯一性索引扫描，对于每个索引键，表中只有一条记录与之匹配。常见于主键或唯一索引扫描
例如：explain SELECT * FROM user as a inner join `order` as b on a.id = b.uid

– ref：非唯一性索引扫描，返回匹配某个单独值的所有行。常见于使用非唯一索引即唯一索引的非唯一前缀进行的查找
例如：explain select * from `user`  WHERE  username = 'love001'

– index_merge： 索引合并
例如：explain SELECT * FROM `order` WHERE id = 10 and deal_id = 100 

– range：限制范围的索引扫描，（=、 <>、>、>=、<、<=、BETWEEN 、 IN ）
例如：explain select * from `user`  WHERE  id > 10 and id < 20;

– index：按索引次序扫描，先读索引，再读实际的行，不需要额外排序
例如：explain select * from `user`  order by id desc;

– All：全表扫描，性能最差
例如：explain select * from user where create_time >= unix_timestamp('2017-01-01');



possible_keys：可能使用到的索引，如果是空的，没有相关的索引


key：实际使用到的索引，NULL 表示没有用到索引


key_len：显示使用的索引的长度，在不损失精确性的情况下，长度越短越好


ref：显示哪些列或常量和key中指定的索引一起做为筛选条件从表中选择数据
例如：
explain 
select a.* 
from order as a 
	inner join user as b on a.uid = b.id
where b.id <=10 



rows：查询时必须检查的行数， 预估值


Extra：额外补充信息

– Using filesort：排序没有用到合适的索引排序，需要做一次额外排序操作

– Using index：只使用索引中的信息,而不需要进一步读取实际的行来检索表中的信息

– Using temporary：使用到了临时表， 通常使用了 GROUP BY 或 ORDER BY 时 用到

– Using where：使用了where条件


参考：https://dev.mysql.com/doc/refman/5.7/en/explain-output.html
欢迎关注【程序员学习交流群】