diff --git a/技术规范/数据库设计规范_v1.0.4.md b/技术规范/数据库设计规范_v1.0.4.md
index 1197002..98add42 100644
--- a/技术规范/数据库设计规范_v1.0.4.md
+++ b/技术规范/数据库设计规范_v1.0.4.md
@@ -163,6 +163,7 @@ ENTITY 表示业务实体名称，可以根据需要有多个单词组成（1-3
 视图的命名以V_开头
 ##### <font  color= #8470FF>Ø规范</font>：视图其它命名规范
 
+
 参考表的命名规范
 
 ##### <font  color= #3CB371>Ø建议</font>：视图的列名
@@ -170,6 +171,9 @@ ENTITY 表示业务实体名称，可以根据需要有多个单词组成（1-3
 一般与基表一致，但是根据需要可以与基表的列名不同。
 
 
+## 索引命名规范
+##### <font  color= #8470FF>Ø规范</font>：前缀规范
+索引的命名以IDX_开头,中间接表名，后面接字段名，如:IDX_TRENTBASE_PRIPID
 
 # 基本设计规范
 
@@ -286,3 +290,69 @@ DDL定义必须符合本设计规范，通过脚本校验工具（规避关键
 > 1. 表内的每一个记录都只能被表达一次；
 > 2. 表内的每一个记录都应该被唯一的标识（有唯一键）；
 > 3. 表内不应该存储依赖于其他键的非键信息。
+
+
+# 表的优化与列类的选择
+总结：数据库优化无非就两个方面：“空间换时间，时间换空间”。几十年前内存比较小，那个时候写程序就是一个字节一个字节的扣，看谁用的内存少， 现在硬件都是廉价的，1T的固态加上上百G的内存都不算什么，所以现在都是什么东西都是往内存一扔，如，以前有1G的文本，要统计数量，这个在现在就比较落伍了，直接往内存一扔，暴力统计下就可以了。第三点就是磁盘上多费点，换取时间的取胜。
+
+1、定长与变长分离
+如：id int，占4个字节，char(4)占4和字符长度，也是定长。
+
+即每一单元的值的字节是固定的
+核心且常用字段，宜建成定长，放在一张表
+如：用户姓名，等级是常用的，放在一张表里面，而E-mail,电话这些信息要点进去才能看，可以放在另外一张表
+
+
+而varchar,text,blob这种变长字段，合适存放一张表，并用主键和核心表关联起来
+
+2、常用字段和不常用字段要分离
+需要结合网站具体的业务来分析，分析字段的查询场景，查询频率低的字段，拆分出来。
+
+3、在一对多需要关联统计的字段上，添加冗余字段，用于统计分析
+数据库设计一般有范式，范式越高，表就拆分的越细，但是这样设计不好，我们在设计中一般是反范式。
+比如论坛，栏目，下面有个统计今日发文的数量，一般是 两表联合查询，这样比较消耗资源，我们可以添加一个【数量】的字段，每次发文就加1，每天清零，这样增加速度
+
+列类型的选择
+1、字段类型的优先级：
+整型>date,time>char>varchar>text
+列的特点分析：
+1>整型：定长，没有国家、地区之分，没有字符集的差异
+比如：tinyint 1,2,3,4,5 <----> char(1) a,b,c,d,e
+从空间上，都是占用1个字节，但是 order by 排序，前者快
+原因：后者需要考虑字符集与校对集（排序规则、大小写）
+比如【 a B c D】 我们正常来说排序就是【 a B c D】 ，但是计算机是【  B  D a c】 
+
+2>time定长，运算快，节省空间，考虑失去，写sql时不方便 where>'2005-10-12'
+3>enum 能起约束表值的目的，内部用整数型来存储，单与char联查时，内部要经历串与值的转化
+4>char 定长， 考虑字符集和排序，校对集
+5>varchar,不定长，要考虑字符集的转换与排序时的校对集，速度慢
+6>text 等大字段 无法使用内存临时表（排序操作只能在磁盘上进行）
+
+以性别为例:
+char(1),3个字长字节
+enum('男','女') //内部转成数字来存，多了一个转换过程
+tingint ,//0 1 2//定长字节
+
+2、够就行，不要慷慨
+原因：大的字段浪费内存，影响速度
+以年龄为例tinyint unsigned not null，可以存储255岁，足够，用int浪费了3个字节
+以varchar(100)，varchar(300)存储相同的内容，单在表联查时，varchar(300)要花更多内存
+
+
+3、尽量避免使用NULL()--mysql数据库的
+原因:NULL，不利于索引，要用特殊的字节来标注；
+在磁盘上占据的空间其实更大（mysql5.7已对null做了改进，但查询还是不便）
+
+# 索引
+数据库查询只会用到一个索引
+
+1、在where 条件常用的列上，都加上索引
+例：where id=3 and price>100 //查询栏目3，价格为100元以上的商品
+误：id上和price上都加上索引
+答：只能用上id或price索引，因为是独立的索引，同时只能用上1个
+
+2、在多列上建立索引后，查询哪个列，索引都将发生作用
+误：多列索引上，索引发挥作用，需要满足左前提要求
+
+# 表更新
+1、所有的执行语句必须加上事务，确定没有问题才能提交，更新数据范围不能超过100列，如果超过这个数，就必须DBA联系处理
\ No newline at end of file