数据库主键

原文： http://blog.csdn.net/sunsnow8/archive/2005/01/10/246615.aspx 或许大家都设计过数据库,也为表定义过主键,今天我想阐述的是,应该如何正确的设计一个主键,在以往的一些资料中,都没有提及到主键设计的原则.我为此总结了一下: 1.是否要采用GUID作为主键 用GUID作主键有它的优势与不足.优势是GUID具有唯一性,在任何情况下,可以产生全球唯一的值.这是GUID最大的优势,也方便数据导入,比如要求从另一个系统中把数据导入进来,那么,不用担心,导入时,会导致主键冲突.不足是GUID值太复杂.不易记忆,因为有时,难免我们会用记录的方式,来进行记录判断.而且数据太长,影响数据库效率.GUID的产生不是以一定的次序产生,对于按主键物理排序的数据库来说,如果在记录的前部插入一条记录,可能会导致后面N次方的数据条数后移.这将导致数据插入效率.因此GUID的采用应该要慎重. 2.是否要采用自动递增的方式 对于以前谈到的主键,要求唯一性,因此大家都用自动递增的方式.这样的方式是非常不可取的.可能是为了方便插入记录时,不必去人为创建主键值.以为这样会方便,其实不是的.带来的麻烦要远远胜于这种所谓的"方便".第一:数据导入不方便,经常会有从另一系统导入数据进来,自动递增的主键,将不允许原表中的ID被导入进来.这会导致主键丢失.第二

或许大家都设计过数据库,也为表定义过主键,今天我想阐述的是,应该如何正确的设计一个主键,在以往的一些资料中,都没有提及到主键设计的原则.我为此总结了一下: 1.是否要采用GUID作为主键 用GUID作主键有它的优势与不足.优势是GUID具有唯一性,在任何情况下,可以产生全球唯一的值.这是GUID最大的优势,也方便数据导入,比如要求从另一个系统中把数据导入进来,那么,不用担心,导入时,会导致主键冲突.不足是GUID值太复杂.不易记忆,因为有时,难免我们会用记录的方式,来进行记录判断.而且数据太长,影响数据库效率.GUID的产生不是以一定的次序产生,对于按主键物理排序的数据库来说,如果在记录的前部插入一条记录,可能会导致后面N次方的数据条数后移.这将导致数据插入效率.因此GUID的采用应该要慎重. 2.是否要采用自动递增的方式 对于以前谈到的主键,要求唯一性,因此大家都用自动递增的方式.这样的方式是非常不可取的.可能是为了方便插入记录时,不必去人为创建主键值.以为这样会方便,其实不是的.带来的麻烦要远远胜于这种所谓的"方便".第一:数据导入不方便,经常会有从另一系统导入数据进来,自动递增的主键,将不允许原表中的ID被导入进来.这会导致主键丢失.第二:对于象订单这样的有主外键的表来说,如果订单的"主档表"主键是自动生成的.那么在保存一个订单时,会要求对主档表与明细表同进行事务保存,而此时

数据库版本：5.6.16 问题： 开发来电话说仓库无法下单，程序插入数据提示：入库单 xxxx1589762285确认失败：Duplicate entry '8388607' for key 'PRIMARY' 查看数据库表结构： show create table table_name; 表结构的字段为主键自增，应该没问题啊，仔细一看发现表结构id类型如下： `id` mediumint(8) NOT NULL AUTO_INCREMENT 字段类型为mediumint，支持的最大值为8388607，确定问题。 修改表结构的id字段类型，修改的时候一定要注意加上auto_increment，否则修改完，主键自增为失效 alter table table_name modify id bigint not null aotu_increment; 修改成功后，联系开发，让仓库那边重新试一下，没问题！ 来源： https://www.cnblogs.com/hankyoon/p/5169700.html

1.若主键没有设置自增长，也会出现 Duplicate entry '8388607' for key 'PRIMARY' ； 2.问题： 开发来电话说仓库无法下单，程序插入数据提示： 入库单 xxxx1589762285确认失败：Duplicate entry '8388607' for key 'PRIMARY' 查看数据库表结构： show create table table_name; 表结构的字段为主键自增，应该没问题啊，仔细一看发现表结构id类型如下： `id` mediumint(8) NOT NULL AUTO_INCREMENT 字段类型为 mediumint，支持的最大值为8388607，确定问题。 修改表结构的id字段类型，修改的时候一定要注意加上 auto_increment，否则修改完，主键自增为失效 alter table table_name modify id bigint not null aotu_increment; 修改成功后，联系开发，让仓库那边重新试一下，没问题！ 来源： https://www.cnblogs.com/jerrypro/p/6484189.html

引言 在面试中，大家应该经历过如下场景 面试官:"用过mysql吧，你们是用自增主键还是UUID？" 你:"用的是自增主键" 面试官:"为什么是自增主键？" 你:"因为采用自增主键，数据在物理结构上是顺序存储，性能最好，blabla..." 面试官:"那自增主键达到最大值了，用完了怎么办？" 你:"what，没复习啊！！" (然后，你就可以回去等通知了！) 这个问题是一个粉丝给我提的，我觉得挺有 意(KENG)思(B)! 于是，今天我们就来谈一谈，这个自增主键用完了该怎么办！ 正文 简单版 我们先明白一点，在mysql中，Int整型的范围如下 类型 最小值 最大值 存储大小 Int(有符号) -2147483648 2147483648 4 bytes Int(无符号) 0 4294967295 4 bytes 我们以无符号整型为例，存储范围为0～4294967295，约43亿！我们先说一下，一旦自增id达到最大值，此时数据继续插入是会报一个主键冲突异常如下所示 //Duplicate entry '4294967295' for key 'PRIMARY' 那解决方法也是很简单的，将Int类型改为BigInt类型，BigInt的范围如下 类型 最小值 最大值 存储大小 BigInt(有符号) -9223372036854775808 9223372036854775808 8

原文: 杂谈自增主键用完了怎么办 引言 在面试中，大家应该经历过如下场景 面试官:"用过mysql吧，你们是用自增主键还是UUID？" 你:"用的是自增主键" 面试官:"为什么是自增主键？" 你:"因为采用自增主键，数据在物理结构上是顺序存储，性能最好，blabla..." 面试官:"那自增主键达到最大值了，用完了怎么办？" 你:"what，没复习啊！！" (然后，你就可以回去等通知了！) 这个问题是一个粉丝给我提的，我觉得挺有 意(KENG)思(B)! 于是，今天我们就来谈一谈，这个自增主键用完了该怎么办！ 正文 简单版 我们先明白一点，在mysql中，Int整型的范围如下 类型 最小值 最大值 存储大小 Int(有符号) -2147483648 2147483648 4 bytes Int(无符号) 0 4294967295 4 bytes 我们以无符号整型为例，存储范围为0～4294967295，约43亿！我们先说一下，一旦自增id达到最大值，此时数据继续插入是会报一个主键冲突异常如下所示 //Duplicate entry '4294967295' for key 'PRIMARY' 那解决方法也是很简单的，将Int类型改为BigInt类型，BigInt的范围如下 类型 最小值 最大值 存储大小 BigInt(有符号) -9223372036854775808

1. 常见约束类型 （1）primary key 单一主键约束，primary key（字段名1，字段名2） 联合主键 （2）foreign key 外键约束 （3）unique 唯一约束 ，取值不能重复，但允许有一个为空 （4）null 为空约束（系统默认的） （5）not null 非空约束 （6）default 值 默认约束，给定字段一个默认值， 添加字符串型默认值要使用单引号,表示为'值’。 如果是整型则不需要加任何符号； 如果要添加的是中文默认值，则需要加上 DEFAULT CHARSET=utf8; 使用英文字符则 不需要。 （7）auto_increment 自增约束，默认情况下初始值和增量都为1。 2. 创建表（包含常见约束） create table 表名 ( 字段名 数据类型 [列级约束] [列级约束], //多个约束一起使用，约束之间空格隔开 字段名 数据类型 [列级约束] [列级约束], ..... foreign key 本表中的字段名 references 父表名（字段名且是父表的主键）, //表级约束 [foreign key 本表中的字段名 references 父表名（字段名）,] [constraint 外键约束名 foreign key（外键名）references 主表名（主键名）] ); 来源： CSDN 作者： Forever+Young

文章来自何凳成博客 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 并发控制中

　　好程序员Web前端教程入门之MySQL命名规范及使用技巧，不懂MySQL的前端不是一个好前端，作为Web应用方面最好的关系数据库管理系统应用软件之一，MySQL体积小、速度快、总体拥有成本低，尤其是开放源码这一特点，一般中小型网站的开发都选择MySQL作为网站数据库。接下来的好程序员Web前端课程就给大家简单分享MySQL命名规范及使用技巧。 　　命名规范 1、库名、表名、字段名必须使用小写字母，并采用下划线分割。 a)MySQL有配置参数lower_case_table_names，不可动态更改，Linux系统默认为0，即库表名以实际情况存储，大小写敏感。如果是1，以小写存储，大小写不敏感。如果是2，以实际情况存储，但以小写比较。 b)如果大小写混合使用，可能存在abc、Abc、ABC等多个表共存，容易导致混乱。 c)字段名显示区分大小写，但实际使⽤用不区分，即不可以建立两个名字一样但大小写不一样的字段。 d)为了统一规范， 库名、表名、字段名使用小写字母。 2、库名、表名、字段名禁止超过32个字符。 　　库名、表名、字段名支持最多64个字符，但为了统一规范、易于辨识以及减少传输量，禁止超过32个字符。 3、库名、表名、字段名禁止使用MySQL保留字。 　　当库名、表名、字段名等属性含有保留字时，SQL语句必须用反引号引用属性名称，这将使得SQL语句书写

继续，这是第五章了。我发现了，写文章比写程序还要有难度。另外，大家期待的高人——吉日嘎拉，已经露头了，他在第四章里面留言了，而且留了很多，回复的比较晚，可能有些Tx没有看到，如果您感兴趣可以去看看，如果不感兴趣就算了。 通用权限想要写的文章目录：（这是第五章） 1 、 简介、数据库的总体结构 2 、 介绍人员表组 3 、 介绍组织结构表组 4 、 介绍角色表组 5 、 介绍“项目自我描述表组” 6 、 权限到节点 7 、 权限到按钮 8 、 权限到列表（表单、查询） 9 、 权限的验证 10 、 资源方面的权限 11 、 角色管理的程序（给客户用的） 12 、 权限下放 13 、 个性化设置 项目描述表组 这里的表比较多，主要分为两个部分，一个是“字典信息”，这里就不介绍了，感兴趣的话，请下载数据库说明文档；另一个就是装载配置信息的表。 项目描述，顾名思义就是想要用数据（记录）的形式来描述一个项目，当然不能所有的事情都能用数据的形式描述出来，只有和数据相关的地方才行。最初的目的是给我的几个自定义控件赋值用的，比如表格控件、表单控件、查询控件等，他们都需要很多的信息给他们的属性赋值，如果直接在代码里面写的话，那还不如直接拖拽控件简单呢，所以我就把需要的属性都放在了“表”里面。一开始并没有想到权限，后来才发现，只要修改一下SQL语句，就可以达到“权限”的目的，包括资源权限。同理