唯一索引

一、 MySQL 中的其他对象 1. 索引 MySQL 索引的建立对于 MySQL 的高效运行是很重要的，索引可以大大提高 MySQL 的检索速度。 1.1MySQL 中的索引类型 • 普通索引 • 唯一索引 • 主键索引 • 组合索引 • 全文索引 1.2 普通索引 是最基本的索引，它没有任何限制。 在创建索引时，可以指定索引长度。length 为可选参数，表示索引的长度，只有字符串 类型的字段才能指定索引长度，如果是 BLOB 和 TEXT 类型，必须指定 length。 创建索引时需要注意： 如果指定单列索引长度，length 必须小于这个字段所允许的最大字符个数。 查询索引：SHOW INDEX FROM table_name 1.2.1 直接创建索引 CREATE INDEX index_name ON table(column(length)) 示例 为 emp3 表中的 name 创建一个索引，索引名为 emp3_name_index create index emp3_name_index ON emp3(name) 1.2.2 修改表添加索引 ALTER TABLE table_name ADD INDEX index_name (column(length)) 示例 修改 emp3 表，为 addrees 列添加索引，索引名为 emp3_address

-----------转载-----------------------:原文: https://www.cnblogs.com/zjfjava/p/6922494.html 索引: 被用来快速找出在一个列上用一特定值的行。没有索引，MySQL不得不首先以第一条记录开始并然后读完整个表直到它找出相关的行。 表越大，花费时间越多。如果表对于查询的列有一个索引，MySQL能快速到达一个位置去搜寻到数据文件的中间，没有必要考虑所有数据。 如果一个表有1000行，这比顺序读取至少快100倍。注意你需要存取几乎所有1000行，它较快的顺序读取，因为此时我们避免磁盘寻道。 所有的MySQL 索引 (PRIMARY、UNIQUE和INDEX) 在B树中存储 。字符串是自动地压缩前缀和结尾空间。 索引用于： 快速找出匹配一个WHERE子句的行； 当执行联结时，从其他表检索行； 对特定的索引列找出MAX()或MIN()值； 如果排序或分组在一个可用键的最左面前缀上进行(例如，ORDER BY key_part_1,key_part_2)，排序或分组一个表。 如果所有键值部分跟随DESC，键以倒序被读取。 在一些情况中，一个查询能被优化来检索值，不用咨询数据文件。 如果对某些表的所有使用的列是数字型的并且构成某些键的最左面前缀，为了更快，值可以从索引树被检索出来。 PRIMARY KEY: mysql

主键索引：唯一切不为null；聚合索引（可以通过索引找到需要的数据） 普通索引：不唯一也可为null；非聚合索引（可以查到记录对应的主键值，再使用主键的值通过索引找到需要的数据） 唯一索引：唯一可为null；唯一约束放在一 个或者多个列上，这些列或列的组合必须有唯一的；创建唯一性的非聚簇索引，但是，也可以指定所创建的索|是聚簇索引。 来源： https://www.cnblogs.com/JimShi/p/11553666.html

/* 1.在innodb中每个数据页的大小默认是16KB 2.对于普通索引来说，在查询时查到满足条件的第一天记录的时候需要查找下一个记录，直到碰到第一个不满足 k=5 条件 的记录 3.对于唯一索引来说因为定义了唯一性，所以查到第一个满足条件的记录后就会停止查询 普通索引和唯一索引的性能差异微乎其微 change buffer 在内存中有缓存这mysql数据页，如果在更新的时候，把磁盘内容改了，但是内存数据还没改回出现数据不一致，这时候就需要 change buffer，innodb会将这些更新操作缓存在change buffer，下次如果需要访问这个数据页，将这个数据页读入内存，然后执行change buffer中有关这个数据页的操作，最终还是会将数据写入磁盘。 change buffer 这个操作应用到原数据页，得到新结果的过程叫做merge 那么什么情况下可以使用change buffer？ 唯一索引;对于唯一索引来说，所有的更新操作多会先判断这个操作是否违反了唯一约束，比如要插入一条（4,400）需要先判断一下表中是否存在k=4这条记录，并且是必须要将数据页读入内存才能判断。如果都已经读入内存了，，那直接更新内存会更快，就没必要使用change buffer， 因此唯一索引的更新就不能使用change buffer了，实际上也只有普通索引可以使用 change buffer

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

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

http://hedengcheng.com/?p=771 类似的文章：https://www.cnblogs.com/yelbosh/p/5813865.html 1.解释了为什么update insert delete 也属于当前读 2.分9种情况解释了rc rr级别下，当前读在mysql中是如何加锁的 2.1 select no update or share mode 操作在非seariable下均不加锁，采用的是快照读，mysql使用mvcc返回历史数据 2.2 对于当前读，分情况讨论 背景 MySQL/InnoDB的加锁分析，一直是一个比较困难的话题。我在工作过程中，经常会有同事咨询这方面的问题。同时，微博上也经常会收到MySQL锁相关的私信，让我帮助解决一些死锁的问题。本文，准备就MySQL/InnoDB的加锁问题，展开较为深入的分析与讨论，主要是介绍一种思路，运用此思路，拿到任何一条SQL语句，都能完整的分析出这条语句会加什么锁？会有什么样的使用风险？甚至是分析线上的一个死锁场景，了解死锁产生的原因。 注： MySQL是一个支持插件式存储引擎的数据库系统。本文下面的所有介绍，都是基于InnoDB存储引擎，其他引擎的表现，会有较大的区别。 MVCC：Snapshot Read vs Current Read MySQL InnoDB存储引擎

转载 http://blog.csdn.net/opensure/article/details/46227695 MySQL 加锁处理分析 标签： Database Deadlock Lock MySQL 2015-05-29 11:14 1101人阅读 评论 (0) 收藏 举报 分类： mysql（1） 目录 (?) [+] 1 背景 1 1.1 MVCC：Snapshot Read vs Current Read 2 1.2 Cluster Index：聚簇索引 3 1.3 2PL：Two-Phase Locking 3 1.4 Isolation Level 4 2 一条简单SQL的加锁实现分析 5 2.1 组合一：id主键+RC 6 2.2 组合二：id唯一索引+RC 6 2.3 组合三：id非唯一索引+RC 7 2.4 组合四：id无索引+RC 8 2.5 组合五：id主键+RR 9 2.6 组合六：id唯一索引+RR 9 2.7 组合七：id非唯一索引+RR 9 2.8 组合八：id无索引+RR 11 2.9 组合九：Serializable 12 3 一条复杂的SQL 12 4 死锁原理与分析 14 5 总结 16 背景 MySQL /InnoDB的加锁分析，一直是一个比较困难的话题。我在工作过程中，经常会有同事咨询这方面的问题。同时

链接地址： http://hedengcheng.com/?p=771 1 背景 1 1.1 MVCC：Snapshot Read vs Current Read 2 1.2 Cluster Index：聚簇索引 3 1.3 2PL：Two-Phase Locking 3 1.4 Isolation Level 4 2 一条简单SQL的加锁实现分析 5 2.1 组合一：id主键+RC 6 2.2 组合二：id唯一索引+RC 6 2.3 组合三：id非唯一索引+RC 7 2.4 组合四：id无索引+RC 8 2.5 组合五：id主键+RR 9 2.6 组合六：id唯一索引+RR 9 2.7 组合七：id非唯一索引+RR 9 2.8 组合八：id无索引+RR 11 2.9 组合九：Serializable 12 3 一条复杂的SQL 12 4 死锁原理与分析 14 5 总结 16 背景 MySQL/InnoDB的加锁分析，一直是一个比较困难的话题。我在工作过程中，经常会有同事咨询这方面的问题。同时，微博上也经常会收到MySQL锁相关的私信，让我帮助解决一些死锁的问题。本文，准备就MySQL/InnoDB的加锁问题，展开较为深入的分析与讨论，主要是介绍一种思路，运用此思路，拿到任何一条SQL语句，都能完整的分析出这条语句会加什么锁？会有什么样的使用风险？甚至是分析线上的一个死锁场景

MySQL 加锁处理分析 http://hedengcheng.com/?p=771 MySQL 加锁处理分析 1 背景 1 1.1 MVCC：Snapshot Read vs Current Read 2 1.2 Cluster Index：聚簇索引 3 1.3 2PL：Two-Phase Locking 3 1.4 Isolation Level 4 2 一条简单SQL的加锁实现分析 5 2.1 组合一：id主键+RC 6 2.2 组合二：id唯一索引+RC 6 2.3 组合三：id非唯一索引+RC 7 2.4 组合四：id无索引+RC 8 2.5 组合五：id主键+RR 9 2.6 组合六：id唯一索引+RR 9 2.7 组合七：id非唯一索引+RR 9 2.8 组合八：id无索引+RR 11 2.9 组合九：Serializable 12 3 一条复杂的SQL 12 4 死锁原理与分析 14 5 总结 16 背景 MySQL/InnoDB的加锁分析，一直是一个比较困难的话题。我在工作过程中，经常会有同事咨询这方面的问题。同时，微博上也经常会收到 MySQL锁相关的私信，让我帮助解决一些死锁的问题。本文，准备就MySQL/InnoDB的加锁问题，展开较为深入的分析与讨论，主要是介绍一种思 路，运用此思路，拿到任何一条SQL语句，都能完整的分析出这条语句会加什么锁