Nutz是一组轻便小型的框架的集合, 各个部分可以被独立使用,把SSH的精华封装在一个1M左右的jar包中,Nutz不对其他任何第三方库产生依赖,如果不考虑数据库链接和日志的话,创建完美的Web应用只需要一个Nutz的jar包。
作为产品而言,就算是再优秀,如果没有优良的使用文档,也是白搭。这也是Nutz的优势所在,很少见到文档像Nutz这样详细的开源框架。
总之,小菜认为Nutz乃国产良心精品。
但是,Nutz 再怎么好,也是个人维护的开源框架,总会遇到种种问题。
今天小菜在实体索引注解方面遇到了点问题,啥问题呢:根本不知道索引注解怎么用。。。
但令小菜意外的是,整个度娘和谷歌,竟然搜不到一丁点答案,官方也没有说明。。。
最后还是在GitHub里找到了点线索,现在把使用方法共享一下!
假设有如下实体:
![](https://i-blog.csdnimg.cn/blog_migrate/8f900a89c6347c561fdf2122f13be562.gif)
![](https://i-blog.csdnimg.cn/blog_migrate/961ddebeb323a10fe0623af514929fc1.gif)
1 /** 2 * 用户 3 * @author xx 4 * 5 */ 6 @Table("t_user") 7 public class User { 8 /** 9 * 主键 10 */ 11 @Id 12 private long id; 13 14 //其他属性...... 15 16 } 17 18 /** 19 * 用户操作记录 20 * @author xx 21 * 22 */ 23 @Table("t_user_record") 24 public class UserRecord { 25 26 /** 27 * 主键 28 */ 29 @Id 30 private long id; 31 /** 32 * 用户id(外键) 33 */ 34 @Column("user_id") 35 private long userId; 36 /** 37 * 创建时间 38 */ 39 @Column("create_date") 40 private Date createDate; 41 42 //其他属性...... 43 44 }
这两个实体描述了用户和用户使用系统而产生的记录,很明显的关联关系。
虽然小菜没有配置一对多映射,但是我们也应该清楚UserRecord实体中的userId属性是一个外键,会在关联两个表的时候使用,而userId又可能有很多很多,不具备有限性,所以这个字段必须加索引。
既然提到索引,就多介绍一点,索引不是乱加的,加多了严重影响写入的速度,这个大家应该都知道,有些字段,可能只有有限的几个值,比如性别,加上索引意义不太。
废话太多了。。。进入正题。。。
我们现在要在UserRecord实体的userId属性上加索引,这么写:
![](https://i-blog.csdnimg.cn/blog_migrate/8f900a89c6347c561fdf2122f13be562.gif)
![](https://i-blog.csdnimg.cn/blog_migrate/961ddebeb323a10fe0623af514929fc1.gif)
1 /** 2 * 用户操作记录 3 * @author xx 4 * 5 */ 6 @Table("t_user_record") 7 @TableIndexes({@Index(name="idx_user_record_user_id",fields={"userId"},unique=false)}) 8 public class UserRecord { 9 10 /** 11 * 主键 12 */ 13 @Id 14 private long id; 15 /** 16 * 用户id(外键) 17 */ 18 @Column("user_id") 19 private long userId; 20 /** 21 * 创建时间 22 */ 23 @Column("create_date") 24 private Date createDate; 25 26 //其他属性...... 27 28 }
只需在实体类上加@TableIndexes注解即可,然后里边每一个@Index注解可以理解成一个索引的声明。
比如说想定义多个索引:
![](https://i-blog.csdnimg.cn/blog_migrate/8f900a89c6347c561fdf2122f13be562.gif)
![](https://i-blog.csdnimg.cn/blog_migrate/961ddebeb323a10fe0623af514929fc1.gif)
1 @TableIndexes({@Index(name="idx_user_record_user_id",fields={"userId"},unique=false), 2 @Index(name="index_name",fields={"fieldName1","fieldName2"},unique=false)})
@Index注解中具体参数说明如下:
name 索引名称。由于索引是全局的,为了避免冲突,名称中建议加上表名。
fields 索引属性集合,也就是说在哪些属性上创建索引。因为索引不仅仅可以加在一个字段上,加在多个字段上叫联合索引。注意,小菜一直在强调属性,fields中的值是实体属性名称,而不是数据库表中的字段名称。
unique 是否是唯一索引。索引大致有三种类型:普通索引、唯一索引、全文索引。普通索引没得说,就是简单的加一个索引,unique=false就是普通索引;唯一索引就是在普通索引的基础上加了一个唯一性约束,保证该字段不重复,unique=true就是唯一索引;全文索引比较复杂,一个表只能建一个,针对超长字符串搜索优化,Nutz不支持,一般也用不到,小菜就不多说啦!
文末,小菜再多说点联合索引的知识。
我们经常会用到这样的SQL语句:
1 SELECT * FROM T_TABLE WHERE FIELD1=? AND FIELD2=? AND FIELD3=?
如果这样的查询非常频繁,数据量又比较大,我们就得考虑在FIELD1、FIELD2、FIELD3上加索引,但是一下子加三个单独的索引很浪费,所以可以在FIELD1、FIELD2、FIELD3上加一个联合索引。
另外,在加联合索引时,如果某个字段被单独查询的概率比较大,那么要把这个字段靠前。就拿刚刚的例子说,如果FIELD2会经常被单独查询,那么就按照FIELD2、FIELD1、FIELD3的顺序加联合索引。
本来挺简单的一件事,小菜说了这么多,文章到此结束,祝读者学习顺利!