uuid

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 前些天看到网上有人说：“Mysql InnoDB 引擎 主键不适合用UUID ， 若要用UUID的话可考虑用 自增ID做物理主键，UUID做逻辑主键。” 带着以上问题，本人做了如下测试： 先自报测试环境： 测试电脑配置如图： MySQL 5.1（社区版） my.ini配置如下 [client] port = 3306 socket = MySQL [mysqld] port = 3306 socket = MySQL key_buffer_size = 64M max_allowed_packet = 16M thread_cache_size = 8 thread_concurrency = 8 max_connections = 100 table_open_cache = 2048 sort_buffer_size = 8M read_buffer_size = 2M read_rnd_buffer_size = 24M net_buffer_length = 2K thread_stack = 1024K server-id = 1 character-set-server=utf8 default-storage-engine=INNODB [mysqldump] quick max_allowed

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> Oracle： <insert id="insert" parameterType="vo.Category"> <selectKey resultType="java.lang.Short" order="BEFORE" keyProperty="id"> SELECT SEQ_TEST.NEXTVAL FROM DUAL </selectKey> insert into category (id,name_zh, parent_id, show_order, delete_status, description ) values ( #{id,jdbcType=NUMBER}, #{nameZh,jdbcType=VARCHAR}, #{parentId,jdbcType=NUMBER}, #{showOrder,jdbcType=NUMBER}, #{deleteStatus,jdbcType=NUMBER}, #{description,jdbcType=VARCHAR} ) </insert> MySQL： 针对自增主键的表，在插入时不需要主键，而是在插入过程自动获取一个自增的主键，比如MySQL，可以采用如下两种配置方式： <insert id="insert" parameterType="vo

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 关于自增主键和UUID的比较，可以从数据插入前，插入中，插入三个阶段进行比较，他们有各自的有点，当然也有各自的不足。下面就分三个阶段说说优缺点。 插入前 1）UUID 需要手动维护，要求是保证每次生成的数据都是不一致的，然后我们需要手写sql插入，如果代码逻辑中含有大量这种非业务相关的代码，其实是很不友好的，所以尽量透明。但是在代码中（Java）你可以在未插入之前就知道了主键ID，这个在有关联表需要插入时非常不错。 2）自增主键 插入前无需维护，编写的sql也不用管这个字段，数据库自己维护，对写程序来说完全透明。缺点就是插入前代码中（Java）并不知道主键。 插入中 1）UUID 长度相对比较大，如果大批量数据插入，在网络传输间，实际上这个字段占用的空间是不容小觑的，当然一般的程序不会担心这个，因为选用 Hibernate 的人，基本不会在乎某个字段的事。另外，既然是主键那么必然要考虑主键的唯一性，如何做这个唯一的校验呢？尤其是并发情况下，如果有多个相同的键同时插入怎么办？所以我觉得这里会有个锁（可能是锁索引，也可能是锁表），因此使用UUID并发插入肯定会发生阻塞的。这个可以去试验一下，开两个事务，使用相同的ID插入，后一个插入肯定会被阻塞，所以我觉得这里肯定有一个判断是否已经存在键的代码，而且是同步的

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 需求缘起   几乎所有的业务系统，都有生成一个记录标识的需求，例如： 1. 消息标识：message-id 2. 订单标识：order-id 3. 帖子标识：tiezi-id   这个记录标识往往就是数据库中的唯一主键，数据库上会建立聚集索引（cluster index），即在物理存储上以这个字段排序。这个记录标识上的查询，往往又有分页或者排序的业务需求，例如： 1. 拉取最新的一页消息： SELECT message-id ORDER BY time LIMIT 100 2. 拉取最新的一页订单： SELECT order-id ORDER BY time LIMIT 100 3. 拉取最新的一页帖子： SELECT tiezi-id ORDER BY time LIMIT 100   所以往往要有一个time字段，并且在time字段上建立普通索引（non-cluster index）.我们都知道普通索引存储的是实际记录的指针，其访问效率会比聚集索引慢，如果记录标识在生成时能够基本按照时间有序，则可以省去这个time字段的索引查询： SELECT message-id ORDER BY message-id LIMIT 100   再次强调，能这么做的前提是message-id的生成基本是趋势时间递增的