InnoDB与UUID

  CakePHP本身有一个uuid实现,所以一直以来,我都在尝试使用uuid做主键的可能性。虽然MySQL是我最常用的数据库,但是和 auto_increment_int主键相比,我对uuid主键更有好感,一方面是因为uuid的数据库无关性,另一方面是当你想把程序分布在多台服务器上时,uuid操作更简单。

不过MySQL还没有原生的uuid支持,在和innodb表类型配合时,可能会出现一些问题:

  首先,innodb会对主键进行物理排序,这对auto_increment_int是个好消息,因为后一次插入的主键位置总是在最后。但是对uuid来说,这却是个坏消息,因为uuid是杂乱无章的,每次插入的主键位置是不确定的,可能在开头,也可能在中间,在进行主键物理排序的时候,势必会造成大量的 IO操作影响效率。

  幸运的是,CakePHP的uuid算法最开始那部分的字符串是基于时间戳的,所以单就CakePHP的uuid而言,不存在这个问题,如果是其他的uuid算法,这个问题一定要仔细考虑。

  其次,因为其他的索引要和主键关联,当主键是uuid时,和int相比必然会占用更大的空间,在较大的空间上检索肯定比在较小的空间上检索耗时。

  这个问题解决起来办法不多,比较常见的方式是主键仍然用auto_increment_int来做,而另加一个uuid做唯一索引,表外键关联什么的,还用uuid来做,也就是说auto_increment_int只是一个形式上的主键,而uuid才是事实上的主键,这样,一方面int主键不会浪费太多空间,另一方面,还可以继续使用uuid。

  还有一个问题是在MySQL里使用uuid,一般是用char(36)来声明字段,如果列编码是gbk/utf8这样的复杂的编码,会拖累主键的效率,这时候,我们那字段编码转换成ascii/latin1这样的简单编码会好一些。

补充资料:5 ways to make hexadecimal identifiers perform better on MySQL

本文来自CSDN博客,转载请标明出处:http://blog.csdn.net/zf213/archive/2009/06/06/4247435.aspx

时间: 2024-11-07 00:38:38

InnoDB与UUID的相关文章

mysql中InnoDB表为什么要建议用自增列做主键

InnoDB引擎表的特点 1.InnoDB引擎表是基于B+树的索引组织表(IOT) 关于B+树 (图片来源于网上) B+ 树的特点: (1)所有关键字都出现在叶子结点的链表中(稠密索引),且链表中的关键字恰好是有序的; (2)不可能在非叶子结点命中; (3)非叶子结点相当于是叶子结点的索引(稀疏索引),叶子结点相当于是存储(关键字)数据的数据层; 2.如果我们定义了主键(PRIMARY KEY),那么InnoDB会选择主键作为聚集索引.如果没有显式定义主键,则InnoDB会选择第一个不包含有NU

MySQL 使用自增ID主键和UUID 作为主键的优劣比较详细过程(从百万到千万表记录测试)

测试缘由 一个开发同事做了一个框架,里面主键是uuid,我跟他建议说mysql不要用uuid用自增主键,自增主键效率高,他说不一定高,我说innodb的索引特性导致了自增id做主键是效率最好的,为了拿实际的案例来说服他,所以准备做一个详细的测试.   作为互联网公司,一定有用户表,而且用户表UC_USER基本会有百万记录,所以在这个表基础上准测试数据来进行测试.            测试过程是目前我想到的多方位的常用的几种类型的sql进行测试,当然可能不太完善,欢迎大家留言提出更加完善的测试方

InnoDB存储引擎的B+树索引算法

关于B+树数据结构 ①InnoDB存储引擎支持两种常见的索引. 一种是B+树,一种是哈希. B+树中的B代表的意思不是二叉(binary),而是平衡(balance),因为B+树最早是从平衡二叉树演化来的,但是B+树又不是一个平衡二叉树. 同时,B+树索引并不能找到一个给定键值的具体行.B+树索引只能找到的是被查找数据行所在的页.然后数据库通过把页读入内存,再在内存中进行查找,最后得到查找的数据. 再说一下平衡二叉树: 这是一幅平衡二叉树,左子树的值总是小于根的值,右子树的值总是大于根的键值,因

MySQL:InnoDB存储引擎的B+树索引算法

很早之前,就从学校的图书馆借了MySQL技术内幕,InnoDB存储引擎这本书,但一直草草阅读,做的笔记也有些凌乱,趁着现在大四了,课程稍微少了一点,整理一下笔记,按照专题写一些,加深一下印象,不枉读了一遍书.与此同时,也加深一下对MySQL的了解,认识了原理,对优化的原则才有把握,对问题的分析才有源头. 关于B+树数据结构 ①InnoDB存储引擎支持两种常见的索引. 一种是B+树,一种是哈希.B+树中的B代表的意思不是二叉(binary),而是平衡(balance),因为B+树最早是从平衡二叉树

[转载]MySQL UUID() 函数

目录 目录 一 引子 二 MySQL UUID() 函数 三 复制中的 UUID()四 UUID_SHORT() 函数 3.1 实验环境介绍 3.2 搭建复制环境 3.3 基于 STATEMENT 模式 3.4 基于 MIXED 模式 3.5 基于 ROW 模式 五 小结 六 Ref 文/温国兵 一 引子 在 MySQL 中,可以有如下几种途径实现唯一值: 自增序列 UUID() 函数 程序自定义 UUID 基于 16 进制,由 32 位小写的 16 进制数字组成,如下: aaaaaaaa-bb

InnoDB: Error: Table "mysql"."innodb_table_stats" not found索引表没找到,主从停止

InnoDB: Error: Table "mysql"."innodb_table_stats" not found. 导致:Seconds_Behind_Master: 27360  mysql主从同步停止 stop slave; 会一直卡住,service mysqld restart后,马上又会停止同步,出现同样问题. 初步判断: 因为innodb_table_stats表丢失,导致主从同步出现问题. 解决办法: 新建innodb_index_stats/i

Mysql技术内幕——InnoDB存储引擎

一.mysql体系结构和存储引擎 1.1.数据库和实例的区别 数据库:物理操作系统或其他形式文件类型的集合.在mysql下数据库文件可以是frm,myd,myi,ibd结尾的文件. 数据库实例:由数据库后台进程/线程以及一个共享内存区组成.数据库实例才是真正用来操作数据库文件的. mysql数据库是单进程多线程的程序,与sql server比较类似.也就是说,Mysql数据库实例在系统上的表现就是一个进程. 1.2.mysql的体系结构 mysql由连接池组件.管理服务和工具组件.sql接口组建

[MySQL FAQ]系列 — 为什么InnoDB表要建议用自增列做主键

[MySQL FAQ]系列 — 为什么InnoDB表要建议用自增列做主键 http://imysql.com/2014/09/14/mysql-faq-why-innodb-table-using-autoinc-int-as-pk.shtml 我们先了解下InnoDB引擎表的一些关键特征: InnoDB引擎表是基于B+树的索引组织表(IOT): 每个表都需要有一个聚集索引(clustered index): 所有的行记录都存储在B+树的叶子节点(leaf pages of the tree):

MySQL UUID函数的详解(转)

MySQL UUID函数的详解 MySQL中可以有二类用于生成唯一值性质的工具:UUID()函数和自增序列,那么二者有何区别呢?我们就此对比下各自的特性及异同点: l  都可以实现生成唯一值的功能: l  UUID是可以生成时间.空间上都独一无二的值:自增序列只能生成基于表内的唯 一值,且需要搭配使其为唯一的主键或唯一索引: l  实现方式不一样,UUID是随机+规则组合而成的,而自增序列是控制一个值逐步增长的: l  UUID产生的是字符串类型值,固定长度为:36个字符,而自增序列产生的是整数