数据库主键

　　　　 1、自动增长identity 适用于MySQL、DB2、MS SQL Server，采用数据库生成的主键，用于为long、short、int类型生成唯一标识 使用SQL Server 和 MySQL 的自增字段，这个方法不能放到 Oracle 中，Oracle 不支持自增字段，要设定sequence（MySQL 和 SQL Server 中很常用） 数据库中的语法如下： MySQL：create table t_user(id int auto_increment primary key, name varchar(20)); SQL Server：create table t_user(id int identity(1,1) primary key, name varchar(20)); <id name="id" column="id" type="long"> <generator class="identity" /> </id> 2、sequence DB2、Oracle均支持的序列，用于为long、short或int生成唯一标识 数据库中的语法如下： Oracle：create sequence seq_name increment by 1 start with 1; 需要主键值时可以调用seq_name.nextval或者seq_name

1、自动增长identity 适用于MySQL、DB2、MS SQL Server，采用数据库生成的主键，用于为long、short、int类型生成唯一标识 使用SQL Server 和 MySQL 的自增字段，这个方法不能放到 Oracle 中，Oracle 不支持自增字段，要设定sequence（MySQL 和 SQL Server 中很常用） 数据库中的语法如下： MySQL：create table t_user(id int auto_increment primary key, name varchar(20)); SQL Server：create table t_user(id int identity(1,1) primary key, name varchar(20)); <id name="id" column="id" type="long"> <generator class="identity" /> </id> 2、sequence DB2、Oracle均支持的序列，用于为long、short或int生成唯一标识 数据库中的语法如下： Oracle：create sequence seq_name increment by 1 start with 1; 需要主键值时可以调用seq_name.nextval或者seq_name.curval得到

做项目时发现我们项目居然是直接用时间戳做为自定义主键，导致批量新增时报错，就查了一波自定义主键策略，集众家之所长，汇成这篇文章。 ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- 1.数据库管理系统自增长主键策略 优点：简单，不需要程序特别处理。字段长度小，占用存储空间小，无论是在内存还是硬盘上。类型为数字类型，方便内部的比较和排序，对于查找有优势。如果同时也将其建立为聚集索引，那么其他列上的非聚集索引所需存储的内容会更少。由于其顺序增长，磁盘碎片少。 缺点：这种方法对以后如果项目移植到其他数据库上改动会比较大，oracle和db2采用Sequence，mysql和sqlserver采用自增长，通用性不强。仅为代理键，无实际意义。 （对于系统中大部分实际的业务功能采用1的自增长策略，这样可以减少开发工作量，并且性能和并发都有保障。如果项目需要进行移植，业务功能这部分则会有变动，做二次开发可暂时不考虑移植性。如果数据不会删除可以考虑使用自增列，如果会删除且删除频繁则会造成主键的极大浪费。） 2

在先前的文章《 又拍网架构中的分库设计 》中， 我有提到过MySQL分库设计中的主键选择问题。在这篇文章里我想对这个问题进行展开讨论， 以此作为对上一篇文章的一个补充。 前面提到 又拍网 采用了全局唯一的字段作为主键。比如拿照片表为例， 虽然不同用户的照片数据存放在不同的Shard（或者说MySQL节点/实例, 请参考《 又拍网架构中的分库设计 》）上， 但是每一张照片拥有整个站点唯一的ID作为标示。 为什么要全局唯一？ 我们在对数据库集群作扩容时，为了保证负载的平衡，需要在不同的Shard之间进行数据的移动， 如果主键不唯一，我们就没办法这样随意的移动数据。起初，我们考虑采用组合主键来解决这个问题。 一般会以 user_id 和一个自增的 photo_id 来作为主键，这的确能解决移动数据可能带来的主键冲突问题， 但是就像在“ 又拍网架构中的分库设计 ”中描述的那样当Shard之间的数据发生关系后， 我们需要用更多的字段来组成主键以保证唯一性，因此主键的索引会变的很大，从而影响查询性能， 同时也会影响写入性能。 其次，每个Shard由两台MySQL服务器组成，而这两台服务器采用master-master的复制方式， 以保证每个Shard一直可写。master-master复制方式必须保证在两台服务器上各自插入的数据有不同的主键， 不然当复制到另外一台时就会出现主键重复错误

1：暂不能用 Navicat的安装与配置 : 下载地址： http://pan.baidu.com/s/lslvzqzF 密码：4eqp 2：设计数据库 3：实现数据库 实际项目开发中是不设置外键的，都是通过程序保持数据的完整性，一致性。 【商品分类】主键：c_id 【商品表】主键：p_id ;p_price用数据类型decimal 10；p_image varchar 255; [用户表]主键：id ;tel int 11; [订单表]主键：order_id;order_state tinyint 1(1表示已支付，2表示未支付，0表示); 来源： https://www.cnblogs.com/jiafeng1996/p/12332988.html

原文： https://zhuanlan.zhihu.com/p/107592567 全局唯一 不能出现重复的ID号，既然是唯一标识，这是最基本的要求。 趋势递增 为什么要趋势递增呢？ 第一，由于我们的分布式ID，是用来标识数据唯一性的，所以多数时候会被定义为主键或者唯一索引。 第二，大多数互联网公司使用的数据库是MySQL，存储引擎为innoDB，对于BTree索引来讲，数据以自增顺序来写入的话，b+tree的结构不会时常被打乱重塑，存取效率是最高的，在主键的选择上面我们应该尽量使用有序的主键保证写入性能。 单调递增：保证下一个ID一定大于上一个ID，例如事务版本号、IM增量消息、排序等特殊需求。 信息安全 由于数据是递增的，所以，恶意用户的可以根据当前ID推测出下一个，非常危险，所以，我们的分布式ID尽量做到不易被破解。如果ID是连续的，恶意用户的扒取工作就非常容易做了，直接按照顺序下载指定URL即可；如果是订单号就更危险了，竞对可以直接知道我们一天的单量。所以在一些应用场景下，会需要ID无规则、不规则。 数据库自增方案缺点： 1.高并发下性能不佳，主键产生的性能上限是数据库服务器单机的上限 2.水平扩展困难，严重依赖数据库，扩容需要停机 Flicker方案： [flicker算法原文] http://code.flickr.com/blog/2010/02/08/ticket

提到数据库索引，我想你并不陌生，在日常工作中会经常接触到。比如某一个SQL查询比较慢，分析完原因之后，你可能就会说“给某个字段加个索引吧”之类的解决方案。但到底什么是索引，索引又是如何工作的呢？今天就让我们一起来聊聊这个话题吧。 数据库索引的内容比较多，我分成了上下两篇文章。索引是数据库系统里面最重要的概念之一，所以我希望你能够耐心看完。在后面的实战文章中，我也会经常引用这两篇文章中提到的知识点，加深你对数据库索引的理解。 一句话简单来说，索引的出现其实就是为了提高数据查询的效率，就像书的目录一样。一本500页的书，如果你想快速找到其中的某一个知识点，在不借助目录的情况下，那我估计你可得找一会儿。同样，对于数据库的表而言，索引其实就是它的“目录”。 索引的常见模型 索引的出现是为了提高查询效率，但是实现索引的方式却有很多种，所以这里也就引入了索引模型的概念。可以用于提高读写效率的数据结构很多，这里我先给你介绍三种常见、也比较简单的数据结构，它们分别是哈希表、有序数组和搜索树。 下面我主要从使用的角度，为你简单分析一下这三种模型的区别。 哈希表是一种以键-值（key-value）存储数据的结构，我们只要输入待查找的值即key，就可以找到其对应的值即Value。哈希的思路很简单，把值放在数组里，用一个哈希函数把key换算成一个确定的位置，然后把value放在数组的这个位置。 不可避免地

索引其实就是为了提高数据查询的效率，就像书的目录一样 索引常见的三种模型： ①哈希表：k-v结构,适用于只有等值查询的场景，范围查询效率低 【插入速度很快：计算key值即可存储】 ②有序数组：等值查询和范围查询的性能就都非常优秀 【查询性能最好，效率都是二分法O(log(N)),但插入成本太高（插入一个记录就必须挪动后面所有记录）】 ∴ 有序数组索引只适用于静态存储引擎 ③搜索树：数据库使用的都是N叉搜索树 【由于读写上的性能优点，以及适配磁盘的访问模式，已经被广泛应用在数据库引擎中】 使用N叉而不使用二叉的原因: 虽然二叉搜索树效率最高，但是 索引不止存在内存中，还要写到磁盘上 。 树高决定访问数据块的时间 ， 在机械硬盘时代，从磁盘随机读一个数据块需要 10 ms 左右的寻址时间。对于一个 100 万行的表， 如果使用二叉树来存储，单独访问一个行可能需要 20 个 10 ms 的时间。 一个查询想尽量少读磁盘，查询过程必须访问尽量少的数据块 所以 虽然二叉树搜索效率高，但往往查询可能很慢； 为了提升查询效率，使用N叉树， “N 叉”树中的“N”取决于数据块的大小 以 InnoDB 的一个整数字段索引为例，N 差不多是 1200。这棵树高是 4 的时候，就可以存 1200 的 3 次方个值，这已经 17 亿了。 而树根的数据块总在内存中的，一个 10 亿行的表上一个整数字段的索引

阅读目录 一 存储引擎介绍 二 表介绍 三 创建表 四 查看表结构 五 数据类型 六 表完整性约束 七 修改表ALTER TABLE 八 复制表 九 删除表 一 存储引擎介绍 存储引擎即表类型，mysql根据不同的表类型会有不同的处理机制 1. 什么是存储引擎 mysql中建立的库===>文件夹 库中建立的 表 ===> 文件 现实生活中我们用来存储数据的文件有不同的类型，每种文件类型对应各自不同的处理机制 ：比如处理文本用txt类型，处理表格用excel，处理图片用png等 数据库中的表也应该有不同的类型， 表的类型不同 ，会对应mysql不同的 存取机制 ，表类型又称为 存储引擎 。 存储引擎说白了就是如何存储数据、如何为存储的数据建立索引和如何更新、查询数据等技术的实现方 法。因为在关系数据库中数据的存储是以表的形式存储的，所以存储引擎也可以称为表类型（即存储和 操作此表的类型） 在Oracle 和SQL Server等数据库中只有一种存储引擎，所有数据存储管理机制都是一样的。而MySql 数据库提供了多种存储引擎。用户可以根据不同的需求为数据表选择不同的存储引擎，用户也可以根据 自己的需要编写自己的存储引擎 SQL 解析器、SQL 优化器、缓冲池、存储引擎等组件在每个数据库中都存在,但不是每 个数据库都有这么多存储引擎。MySQL

转载自： http://www.cnblogs.com/zhhh/archive/2011/04/21/2023355.html 。 三大范式一直没有记住，看了这个有了理解！挺好的记着，以后忘了，可以再看看！ 为了建立冗余较小、结构合理的数据库，设计数据库时必须遵循一定的规则。在关系型数据库中这种规则就称为范式。范式是符合某一种设计要求的总结。要想设计一个结构合理的关系型数据库，必须满足一定的范式。 在实际开发中最为常见的设计范式有三个： 1 ．第一范式 第一范式是最基本的范式。如果数据库表中的所有字段值都是不可分解的原子值，就说明该数据库表满足了第一范式。 第一范式的合理遵循需要根据系统的实际需求来定。比如某些数据库系统中需要用到“地址”这个属性，本来直接将“地址”属性设计成一个数据库表的字段就行。但是如果系统经常会访问“地址”属性中的“城市”部分，那么就非要将“地址”这个属性重新拆分为省份、城市、详细地址等多个部分进行存储，这样在对地址中某一部分操作的时候将非常方便。这样设计才算满足了数据库的第一范式，如下表所示。 用户信息表 编号 姓名 性别 年龄 联系电话 省份 城市 详细地址 1 张红欣 男 26 0378-23459876 河南 开封 朝阳区新华路23号 2 李四平 女 32 0751-65432584 广州 广东 白云区天明路148号 3 刘志国 男 21 0371