-- Create table create table TECHNOLOGYCOMPANY ( ID VARCHAR2(32) default SYS_GUID() not null, FLOWID VARCHAR2(50), CONPANYID NUMBER, ISCOMMUNICATION VARCHAR2(10) ) tablespace USERS pctfree 10 initrans 1 maxtrans 255 storage ( initial 64K minextents 1

数据库:mysql5.5 表类型:InnoDB 数据量:100W条 第一种情况: 主键采用uuid 32位. 运行查询语句1:SELECT COUNT(id) FROM test_varchar; 运行查询语句2:SELECT * FROM test_varchar WHERE vname='00004629-b052-11e1-96aa-002655b28d7b'; 运行查询语句3:SELECT * FROM test_varchar WHERE id='00004599b05211e196a

不易于存储:UUID太长,16字节128位,通常以36长度的字符串表示,很多场景不适用. 信息不安全:基于MAC地址生成UUID的算法可能会造成MAC地址泄露,这个漏洞曾被用于寻找梅丽莎病毒的制作者位置. ID作为主键时在特定的环境会存在一些问题,比如做DB主键的场景下,UUID就非常不适用: ① MySQL官方有明确的建议主键要尽量越短越好[4],36个字符长度的UUID不符合要求. All indexes other than the clustered index are known as

uuid为主键,插入时自动更新 -- Create table create table TECHNOLOGYCOMPANY ( ID VARCHAR2(32) default SYS_GUID() not null, FLOWID VARCHAR2(50), CONPANYID NUMBER, ISCOMMUNICATION VARCHAR2(10) ) tablespace USERS pctfree 10 initrans 1 maxtrans 255 storage ( initial

我们先了解下InnoDB引擎表的一些关键特征: InnoDB引擎表是基于B+树的索引组织表(IOT): 每个表都需要有一个聚集索引(clustered index): 所有的行记录都存储在B+树的叶子节点(leaf pages of the tree): 基于聚集索引的增.删.改.查的效率相对是最高的: 如果我们定义了主键(PRIMARY KEY),那么InnoDB会选择其作为聚集索引: 如果没有显式定义主键,则InnoDB会选择第一个不包含有NULL值的唯一索引作为主键索引: 如果也没有这样的

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

InnoDB引擎表是基于B+树的索引组织表(IOT): 每个表都需要有一个聚集索引(clustered index): 所有的行记录都存储在B+树的叶子节点(leaf pages of the tree): 基于聚集索引的增.删.改.查的效率相对是最高的: 如果我们定义了主键(PRIMARY KEY),那么InnoDB会选择其作为聚集索引: 如果没有显式定义主键,则InnoDB会选择第一个不包含有NULL值的唯一索引作为主键索引: 如果也没有这样的唯一索引,则InnoDB会选择内置6字节长的RO

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

记得A项目组是一个物流管理系统,后台采用了Oracle数据库.在系统中的核心表托运单表中,关于主键采用何种数据类型,是 sequence 还是用GUID , 大家起了争论. 从网络搜索得到的结论看,一般的意见总结为:1. SYS_GUID()比sequence复杂:2.SYS_GUID做主键,则表.索引存储开销多:3.SYS_GUID索引查询比sequence慢: 小结 从实践来看, 使用SYS_GUID() 做主键的优点多于负面影响.特别是在多个数据库数据集成时,GUID 的优点显而易见. 综

使用Guid做主键和int做主键性能比较 在数据库的设计中我们常常用Guid或int来做主键,根据所学的知识一直感觉int做主键效率要高,但没有做仔细的测试无法 说明道理.碰巧今天在数据库的优化过程中,遇到此问题,于是做了一下测试. 测试环境: 台式电脑 Pentiun(R) 4 Cpu 3.06GHz Win XP professional  1.5G DDR RAM  SQL Server 2005 个人版 测试过程:首先创建测试数据库Test1.创建Test_Guid表,创建Test_In

场景: 产品表数据量较大想用Guid做表的主键,并在此字段上建立聚簇索引. 因为Guid是随机生成的,生成的值大小是不确定的,每次生成的数可能很大,也可能很小.这样会影响插入的效率 1.NEWSEQUENTIALID和newid()的区别 NEWSEQUENTIALID() 和 NEWID()都可以产生uniqueidentifier类型的,GUID.NEWID()产生的GUID是无序的,随机的. 而NEWSEQUENTIALID()是SQL SERVER2005新特性,NEWSEQUENTIA

我们公司的数据库全部是使用GUID做主键的,很多人习惯使用int做主键.所以呢,这里总结一下,将两种数据类型做主键进行一个比较. 使用INT做主键的优点: 1.需要很小的数据存储空间,仅仅需要4 byte . 2.insert和update操作时使用INT的性能比GUID好,所以使用int将会提高应用程序的性能. 3.index和Join 操作,int的性能最好. 4.容易记忆. 5.支持通过函数获取最新的值,如:Scope_Indentity() . 使用INT做主键的缺点 1.如果经常有合并

Oracle查找表的外键引用关系 select t1.table_name, t2.table_name as "TABLE_NAME(R)", t1.constraint_name, t1.r_constraint_name as "CONSTRAINT_NAME(R)", a1.column_name, a2.column_name as "COLUMN_NAME(R)" from user_constraints t1, user_cons

从Data Ghost的blog得知,原来可以用Oracle来生成UUID,做法很简单,如下: select sys_guid() from dual;  数据类型是 raw(16) 有32个字符.

一个数据表,需要两个字段联合起来一块做主键的时候.举例如下: 直接用sql语句的话如下 ALTER TABLE `表名` ADD PRIMARY KEY ( `表中字段名1` , `表中字段名2` ) ; 或者在phpmyadmin中操作,如下图: 完成后,这时候插入数据就会发现,a_id和b_id组合来看,数据有重复会提示插入错误的 设置后,我又后悔了,要取消数据表的主键,sql语句如下: ALTER TABLE `abcdefg` DROP PRIMARY KEY;

ORACLE: 1.查主键名称: select * from user_constraints where table_name = 'AAA' and constraint_type ='P'; 查主键对应的列: select * from user_cons_columns where table_name = 'AAA' and constraint_name = 'PK_AAA'; (PK_AAA 是主键名) 2.查索引名称: select * from user_indexes whe

为什么要为innodb表设置自增列做主键? 1.使用自增列做主键,写入顺序是自增的,和B+数叶子节点分裂顺序一致 2.表不指定自增列做主键,同时也没有可以被选为主键的唯一索引,InnoDB就会选择内置的rowid作为主键,写入顺序和rowid增长顺序一致 所以InnoDB表的数据写入顺序能和B+树索引的叶子节点顺序一致的话,这时候存取效率是最高

当我们默认新建一个ASP.NET MVC项目的时候,使用的身份认证系统是ASP.NET Identity.但是这里的Identity使用的主键为String类型的GUID.当然这是大多数系统首先类型.但是因为历史原因,而我们公司所有项目主键都是用的Int类型(这里不讨论int和GUID的优劣)所以默认的String类型GUID就不能满足我们的需求,所以进行一些扩展,让其支持Int类型.下图为默认使用String做主键的ASP.NET MVC ApplicationUser继承自IdentityU

window下的sqlplus可以通过箭头键,来回看历史命令,用起来非常的方便. 但是在Linux下,会出现各种乱码,非常不方便,如下图所示,每次打错一个字符就需要重新打一遍. 解决办法:rlwrap 可以用来支持Oracle下sqlplus历史命令的回调功能,提高效率. 解决过程: 1.首先下载rlwrap和readline: ? 1 2 readline-6.3.tar.gz   rlwrap-0.30.tar.gz 2.安装readline包 ? 1 2 3 4 5 tar -zxvf r

Oracle中生成uuid的方法 下载LOFTER客户端 在Oracle SQL 提供了一个生成uuid的函数sys_guid: http://download.oracle.com/docs/cd/E11882_01/server.112/e17118/functions187.htm#i79194 http://en.wikipedia.org/wiki/Universally_unique_identifier SQL> select sys_guid() from dual ; SYS_

转自:https://blog.csdn.net/zxh2075/article/details/78488141 之前有一项工作是将mysql的数据库实现转移到oracle,遇到了自增主键实现的问题.   首先介绍一下MySQL和Oracle的背景知识   1)MySQL建表时必须有一个主键(PRIMARY KEY), 每条主键内容必须唯一(Unique), 所以经常使用一个”ID”字段作为主键,给它一个”auto_increment”属性,让”ID”字段每条记录都自增”1″.   比如下表: