I、在java代码中,backend->src->main->resources-->application.properties,找到数据库链接地址和用户名、密码。地址不需要加接口,128位IPv4即可。(第一个用户名是自己Navicat显示的数据库名字)
II、连接数据库后,找到对应表,右键设计表,填写索引-唯一性校验、触发器-逻辑删除:
(举例bugfix榆林-226文件名称重复)
i.索引:(i) 名 栏位/字段 索引类型 索引方法
folderName_UNIQUE (选择)folder_name (选择)folder_name (选择)BTREE
ii.触发器-逻辑删除:
(i) 名 触发 插入 更新 删除(3选1)
erc_opc_config_protocolName (选择)Before (勾选)更新
(ii)
ALTER TABLE `ylng`.`eas_knowledge_folder`
ADD UNIQUE INDEX `folderName_UNIQUE`(`folder_name`);
CREATE TRIGGER `eas_knowledge_folder_folder_name` BEFORE UPDATE ON `eas_knowledge_folder` FOR EACH ROW BEGIN
IF
( new.dtime is not null && old.dtime is null )
THEN
SET new.folder_name = CONCAT(old.folder_name,'_',old.id);
END IF;
END;
(iii)SQL预览复制出来放到sql文件中,命名格式注意(bugs_224,226.sql),svn在实施文件->sql中
(iv)sql文件使用记事本打开,另存为,选择编码为utf-8
iii.Tips:栏位/字段可选多个,多选意味着每一项都不允许相同,比如同一文件夹下文件不允许重名。
III、索引方法:B树、B+树与HASH的区别、使用场景:
BTree:可以支持like模糊查询。
BTree索引是最常用的mysql数据库索引算法,因为它不仅可以被用在=、>、<、>=、<=、between这些比较操作符上,还可以用于like操作符。只要它的查询条件是一个不以通配符开头的常量则该索引生效;否则索引失效。
Hash:仅适用于对等比较(=、>、<、>=、<=、between)。
Hash索引只能用于对等比较,例如=、>、<、>=、<=、between。由于是一次定位数据,不像BTree索引需要从根节点到枝节点,最后才能访问到叶节点这样多次IO访问,所以检索效率远高于BTree索引。
问题:但是为什么使用BTree比Hash多呢?
i.Hash索引仅仅能满足=、>、<、>=、<=、between查询,不能使用范围查询。
ii.联合索引中,Hash索引不能利用部分索引键查询。
对于联合索引中的多个列,Hash要么全部使用,要么全部不适用,并不支持BTree支持的联合索引的最有前缀,也就是联合索引的前面一个或几个索引键进行查询时,Hash索引无法被利用。
iii.Hash索引无法避免数据的排序操作。
由于Hash索引中存放的是经过Hash计算之后的Hash值,而且Hash值的大小关系并不一定和Hash运算前的键值完全一样,所以数据库无法利用索引的数据来避免任何排序运算。
iv.Hash索引任何时候都不能避免表扫描。
Hash索引是将索引键通过Hash运算之后,将Hash运算结果的Hash值和所对应的行指针信息存放于一个Hash表中,由于不同索引键存在相同Hash值,所以即使满足某个Hash键值的数据的记录条数,也无法从Hash索引中直接完成查询,还是要通过访问表中的实际数据进行比较,并得到相应的结果。
v.Hash索引遇到大量Hash值相等的情况后性能并不一定会比BTree高。
对于选择性比较低的索引键,如果创建Hash索引,那么将会存在大量记录指针信息存于同一Hash值相关联。这样要定位某一条记录时就会非常麻烦,会浪费多次表数据访问,从而造成整体性能低下。
vi.Hash索引查找数据基本上能一次定位数据,当然有大量碰撞的话性能也会下降。而BTree索引就得在节点上挨个查找了,很明显在数据精确查找方面Hash索引的效率要高于BTree索引的;
vii.因为Hash算法是基于等值计算的,所以对于like等范围查找Hash索引不支持;
viii.对于BTree支持的联合索引的最有前缀,hash也是无法支持的,联合索引中的字段要么全用要么全不用。
ix.hash不支持索引排序,索引值和计算出来的hash值大小并不一定一致。