唯一索引

主键（PRIMARY KEY） 表通常具有包含唯一标示表中每一行的值的一列或者一组列。这样的一列或者多列称为表的主键（PK），用于强制表的尸体完整性。在创建或者修改表时，您可以通过定义PK约束来创建主键。 一个表只能有一个PK约束，并且PK约束中的列不能接受空值。由于PK约束可以保证数据的唯一性，因此经常对标识列定义这种约束。 如果为表指定了PK约束，数据库引擎将通过为主键列创建唯一索引来强制数据的唯一性。当在查询中使用主键时，此索引还可以用来对数据进行快速访问。因此，所选的主键必须遵守创建唯一索引的规则。 创建主键时，数据库引擎会自动创建唯一的索引来强制实施PK约束的唯一性要求。如果表中不存在狙击索引或未显示指定非聚集索引，则将创建唯一的聚集索引以强制实施PK约束。 聚集索引 聚集索引给予数据行的兼职在表内排序和存储这些数据行。每个表只能有一个聚集索引，因为数据行本身只能按一个顺序存储。 每个表几乎都对列定义聚集索引来实现下列功能： 可用于经常使用的查询。 提供高度唯一性。 两者的比较 主键 聚集索引 用途 强制表的实体完整性 对数据行的排序，方便查询用 一个表多少个 一个表最多一个主键 一个表最多一个聚集索引 是否允许多个字段来定义 一个主键可以多个字段来定义 一个索引可以多个字段来定义 是否允许null值 如果要创建的数据列中数据存在null，无法创建主键

普通索引和唯一索引 我们已经介绍过索引的结构和索引的几种优化，我们再来看一下相同语句在不同索引类型的执行过程 这里普通索引和唯一索引的情况有所不同 查询过程 对于普通索引来说，查找到满足条件的第一个记录后，需要查找下一个记录， 直到碰到第一个不满足条件的记录。 对于唯一索引来说，由于索引定义了唯一性，查找到第一个满足条件的记录后，就会停止继续检索 这个不同带来的性能差距会有多少呢? 基本上差不多 InnoDB 的数据是按数据页为单位来读写的。也就是说，当需要读一条记录的时候，并不是将这个记录本身从磁盘读出来，而是以页为单位，将其整体读入内存。在 InnoDB 中，每个数据页的大小默认是 16KB。 因为引擎是按页读写的，所以说，当找到记录的时候，它所在的数据页就都在内存里了。那么，对于普通索引来说，要多做的那一次“查找和判断下一条记录”的操作 更新过程 当需要更新一个数据页时，如果数据页在内存中就直接更新，而如果这个数据页还没有在内存中的话，在不影响数据一致性的前提下，InooDB 会将这些更新操作缓存在 change buffer 中，这样就不需要从磁盘中读入这个数据页了。在下次查询需要访问这个数据页的时候，将数据页读入内存，然后执行 change buffer 中与这个页有关的操作。通过这种方式就能保证这个数据逻辑的正确性 虽然名字叫作 change buffer

有些人可能对主键和聚集索引有所混淆，其实这两个是不同的概念，下面是一个简单的描述。不想看绕口文字者，直接看两者的对比表。尤其是最后一项的比较。 主键（PRIMARY KEY ） 来自MSDN的描述： 表通常具有包含唯一标识表中每一行的值的一列或一组列。这样的一列或多列称为表的主键 (PK)，用于强制表的实体完整性。在创建或修改表时，您可以通过定义 PRIMARY KEY 约束来创建主键。 一个表只能有一个 PRIMARY KEY 约束，并且 PRIMARY KEY 约束中的列不能接受空值。由于 PRIMARY KEY 约束可保证数据的唯一性，因此经常对标识列定义这种约束。 如果为表指定了 PRIMARY KEY 约束，则 SQL Server 2005 数据库引擎 将通过为主键列创建唯一索引来强制数据的唯一性。当在查询中使用主键时，此索引还可用来对数据进行快速访问。因此，所选的主键必须遵守创建唯一索引的规则。 创建主键时，数据库引擎 会自动创建唯一的索引来强制实施 PRIMARY KEY 约束的唯一性要求。如果表中不存在聚集索引或未显式指定非聚集索引，则将创建唯一的聚集索引以强制实施 PRIMARY KEY 约束。 聚集索引 聚集索引基于数据行的键值在表内排序和存储这些数据行。每个表只能有一个聚集索引，因为数据行本身只能按一个顺序存储。 每个表几乎都对列定义聚集索引来实现下列功能：

一般，我们看到术语“索引”和“键”交换使用，但实际上这两个是不同的。索引是存储在数据库中的一个物理结构，键纯粹是一个逻辑概念。键代表创建来实施业务规则的完整性约束。索引和键的混淆通常是由于数据库使用索引来实施完整性约束。 接下来我们看看数据库中的主键约束、唯一键约束和唯一索引的区别。 SQL> select * from v$version; BANNER -------------------------------------------------------------------------------- Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production PL/SQL Release 11.2.0.1.0 - Production CORE 11.2.0.1.0 Production TNS for Linux: Version 11.2.0.1.0 - Production NLSRTL Version 11.2.0.1.0 - Production SQL> create table test ( 2 id int, 3 name varchar2(20), 4 constraint pk_test primary key(id)) 5 tablespace users;

mysql修改列 mysql增加列，修改列名、列属性，删除列语句 mysql修改表名，列名，列类型，添加表列，删除表列 alter table test rename test1; --修改表名 alter table test add column name varchar(10); --添加表列 alter table test drop column name; --删除表列 alter table test modify address char(10) --修改表列类型 ||alter table test change address address char(40) alter table test change column address address1 varchar(30)--修改表列名 mysql修改表 表的结构如下: mysql> show create table person; | person | CREATE TABLE `person` ( `number` int(11) DEFAULT NULL, `name` varchar(255) DEFAULT NULL, `birthday` date DEFAULT NULL ) ENGINE=MyISAM DEFAULT CHARSET=utf8 | 删除列: ALTER TABLE

文章来自何凳成博客 1 背景 MySQL/InnoDB 的加锁分析，一直是一个比较困难的话题。我在工作过程中，经常会有同事 咨询这方面的问题。同时，微博上也经常会收到MySQL 锁相关的私信，让我帮助解决一些 死锁的问题。本文，准备就MySQL/InnoDB 的加锁问题，展开较为深入的分析与讨论，主要 是介绍一种思路，运用此思路，拿到任何一条SQL 语句，就能完整的分析出这条语句会加 什么锁？会有什么样的使用风险？甚至是分析线上的一个死锁场景，了解死锁产生的原因。 注 ：MySQL 是一个支持插件式存储引擎的数据库系统。本文下面的所有介绍，都是基于InnoDB 存储引擎，其他引擎的表现，会有较大的区别。 1.1 MVCC：Snapshot Read vs Current Read MySQL InnoDB 存储引擎，实现的是基于多版本的并发控制协议——MVCC (Multi-Version Concurrency Control) (注：与MVCC相对的，是基于锁的并发控制，Lock-Based ConcurrencyControl)。MVCC 最大的好处，相信也是耳熟能详：读不加锁，读写不冲突。在读多些少的OLTP 应用中，读写不冲突是非常重要的，极大的增加了系统的并发性能，这也是为什么现阶段，几乎所有的 RDBMS，都支持了 MVCC。 在 MVCC 并发控制中

接口幂等性的解决方案 在编程中，幂等操作的特点是其任意多次执行所产生的影响均与一次执行的影响相同。幂等函数指的是那些使用相同参数重复执行也能获得相同结果的函数。这些函数不会影响系统状态，也不用担心重复执行会对系统造成改变。比如说getIdCard()函数和setTrue()函数就是幂等函数。 幂等在我的理解里就是，一个操作不论被执行多少次，产生的效果和返回的结果都是一样的。 一个幂等的操作典型如：把编号为5的记录的A字段设置为0这种操作不管执行多少次都是幂等的。 一个非幂等的操作典型如：把编号为5的记录的A字段增加1这种操作显然就不是幂等的。 幂等的方案 1.查询操作：Select是天然的幂等操作。 查询一次和查询多次，在数据不变的情况下，查询的结果都是一样的。 2.删除操作：删除操作也是幂等的，删除一次和删除多次都是把数据删除。 因为删除操作通常是定向的，比如通过id去删除数据，如果该id在数据库中存在对应记录，则删除该记录；如果该id在数据库中不存在对应记录，也是执行的删除记录操作，只是没有实质性地删除到记录而已，却也不会有其他的副作用。 但是如果删除操作具有返回值的话，可能返回的结果会不一样，比如删除一条记录之后返回这条记录中的某个值，如果删除的数据不存在（已经在第一次的删除请求中被删除了），返回的就是空值了。 3.唯一索引

1》索引的含义和特点： 　 　　索引是什么，索引相当于字典里面的目录序表，比如查询一个“星”字，如果不按照拼音来找的话，那么我们需要把整个字典全部遍历查询一边。才能查到这个字， 如果按照拼音来找的，那么只需要在几页音序表中查询。就可以通过音序就快速查到，这个字在字典的哪一页。在数据库中，索引是建立在表上面的，索引可以很大程 度上提高数据库的查询，同时也提高了数据库的性能，不同的存储引擎定义了索引的最大长度和索引的数量，所有的存储引擎对每个表最少支持16个索引，索引的长度 最少支持位256字节； 　　索引优点： 　　　　其优点可以提高数据的检索速度，针对于有依赖关系的子表和父表，在联合查询的时候可以提高查询速度。 　　索引的缺点： 　　　　创建和维护索引需要消耗时间，索引需要占用物理空间，每一个索引都需要占用一定的物理空间，大量的索引会影响插入数据，数据库系统会按照索引进行排 序，这样降低了插入数据的速度； 　　 解决办法：在插入数据时，先临时删除表的索引，然后插入数据，数据插入完成后，再创建索引。 2》索引的分类： 　　Mysql的索引类型有：普通索引，唯一性索引，全文索引，单列索引、多列索引和空间索引等； 　　1>普通索引 　　　　创建普通索引时，不附加任何限制条件，，这类索引可以创建在任何的数据类型上面， 　　2>唯一性索引 　　　 使用unique参数可以设置唯一索引

在使用TOAD来操作Oracle数据库时，会注意到创建约束时有Primary Key、Check、Unique和Foreign Key四种类型的约束，这与SQL Server中的约束没有什么区别，这里的Check约束除了用于一般的Check约束外，在Oracle中也用于非空约束的实现。也就是说如果一个字段不允许为空，则系统将会创建一个系统的Check约束，该约束定了某字段不能为空。 除了约束，还有另外一个概念是索引，在TOAD中创建索引的界面如下： 我们可以注意到在唯一性组中有三个选项：不唯一、唯一和主键。那么创建索引时的唯一、主键与创建约束时候的唯一约束和主键约束有什么区别呢？ 这里的可能容易产生误解，其实创建主键的结果是一样的，不管是在创建约束时创建还是创建索引时创建，都会创建一个主键约束和对应的一个唯一索引。 创建唯一约束与创建唯一索引有所不同： 创建唯一约束会在Oracle中创建一个Constraint，同时也会创建一个该约束对应的唯一索引。 创建唯一索引只会创建一个唯一索引，不会创建Constraint。 也就是说其实唯一约束是通过创建唯一索引来实现的。对于前端开发人员来说这两者有什么区别吗？好像没有。都是不能插入重复的值。在删除时这两者也有一定的区别，删除唯一约束时可以只删除约束而不删除对应的索引，所以对于的列还是必须唯一的，而删除了唯一索引的话就可以插入不唯一的值。

概括： 这里说的聚集索引是聚簇索引 聚簇索引即建立在聚簇上的索引，创建聚簇索引时，需要对已有表数据重新进行排序（若表中已有数据），即删除原始的表数据后再将排序结果按物理顺序插回，故聚簇索引建立完毕后，建立聚簇索引的列中的数据已经全部按序排列。 一个表中只能包含一个聚簇索引，但该索引可以包含多个列。 B-树索引中，聚簇索引的叶层就是数据页。 非聚簇索引类似书本索引，索引与数据存放在不同的物理区域，建立非聚簇索引时数据本身不进行排序。一个表中科含多个非聚簇索引。 B-树索引中，非聚簇索引的叶层仍是索引页，其以指针指向数据页实际存储位置。 详解，列子： 非聚集索引与聚集索引具有相同的 B 树结构，它们之间的显著差别在于以下两点： 基础表的数据行不按非聚集键的顺序排序和存储。 非聚集索引的叶层是由索引页而不是由数据页组成。 非聚集索引既可以建在堆表结构上也可以建在聚集索引表上；非聚集索引中的每个索引行都包含非聚集键值和行定位符。此定位符指向聚集索引或堆中包含该键值的数据行。 如果表是堆则行定位器是指向行的指针。该指针由文件标识符 (ID) 、页码和页上的行数生成。整个指针称为行 ID (RID) 。 如果表包含有聚集索引，则行定位器是行的聚集索引键。如果聚集索引不是唯一的索引， SQL Server 将添加在内部生成的值（称为唯一值）以使所有重复键唯一。此四字节的值对于用户不可见