数据库主键

主键： 主键是数据表的唯一索引，比如学生表里有学号和姓名，姓名可能有重名的，但学号确是唯一的，你要从学生表中搜索一条纪录如查找一个人，就只能根据学号去查找，这才能找出唯一的一个，这就是主键;如：id int(10) not null primary key auto_increment ；自增长的类型 ； 外键： 定义数据表 　　假如某个电脑生产商，它的数据库中保存着整机和配件的产品信息。用来保存整机产品信息的表叫做 Pc；用来保存配件供货信息的表叫做Parts。 　　在Pc表中有一个字段，用来描述这款电脑所使用的CPU型号； 　　在Parts 表中相应有一个字段，描述的正是CPU的型号，我们可以把它想成是全部CPU的型号列表。 　　很显然，这个厂家生产的电脑，其使用的CPU一定是供货信息表(parts)中存在的型号。这时，两个表中就存在一种约束关系(constraint)——Pc表中的CPU型号受到Parts 表中型号的约束。 　　首先我们来创建 parts 表： CREATE TABLE parts ( ... 字段定义 ..., model VARCHAR(20) NOT NULL, ... 字段定义 ... ); 　　接下来是Pc表： CREATE TABLE pc ( ... 字段定义 ..., cpumodel VARCHAR(20) NOT NULL, ...

主键： 主键是数据表的唯一索引，比如学生表里有学号和姓名，姓名可能有重名的，但学号确是唯一的，你要从学生表中搜索一条纪录如查找一个人，就只能根据学号去查找，这才能找出唯一的一个，这就是主键;如：id int(10) not null primary key auto_increment ；自增长的类型 ； 外键： 定义数据表 　　假如某个电脑生产商，它的数据库中保存着整机和配件的产品信息。用来保存整机产品信息的表叫做 Pc；用来保存配件供货信息的表叫做Parts。 　　在Pc表中有一个字段，用来描述这款电脑所使用的CPU型号； 　　在Parts 表中相应有一个字段，描述的正是CPU的型号，我们可以把它想成是全部CPU的型号列表。 　　很显然，这个厂家生产的电脑，其使用的CPU一定是供货信息表(parts)中存在的型号。这时，两个表中就存在一种约束关系(constraint)——Pc表中的CPU型号受到Parts 表中型号的约束。 　　首先我们来创建 parts 表： CREATE TABLE parts ( ... 字段定义 ..., model VARCHAR(20) NOT NULL, ... 字段定义 ... ); 　　接下来是Pc表： CREATE TABLE pc ( ... 字段定义 ..., cpumodel VARCHAR(20) NOT NULL, ...

查看索引 SHOW INDEX FROM 数据库表名 比如：SHOW INDEX FROM order_info; 添加索引 alter table 数据库add index 索引名称(数据库字段名称) 主键索引 ALTER TABLE `table_name` ADD PRIMARY KEY ( `column` ) 比如： ALTER TABLE order_info ADD PRIMARY KEY (order_id); UNIQUE(唯一索引) ALTER TABLE `table_name` ADD UNIQUE (`column`) INDEX(普通索引) mysql>ALTER TABLE `table_name` ADD INDEX index_name ( `column` ) FULLTEXT(全文索引) ALTER TABLE `table_name` ADD FULLTEXT ( `column` ) 删除索引 ALTER TABLE table_name DROP INDEX index_name DROP INDEX index_name ON talbe_name 多列索引 ALTER TABLE `table_name` ADD INDEX index_name ( `column1`, `column2`, `column3` ) 1.普通索引。

主键的必要性 有些朋友可能不提倡数据库表必须要主键，但在我的思考中，觉得每个表都应该具有主键，不管是单主键还是双主键，主键的存在就代表着表结构的完整性，表的记录必须得有唯一区分的字段，主键主要是用于其他表的外键关联，本记录的修改与删除，当我们没有主键时，这些操作会变的非常麻烦。 主键的无意义性 我强调主键不应该具有实际的意义，这可能对于一些朋友来说不太认同，比如订单表吧，会有“订单编号”字段，而这个字段呢在业务实际中本身就是应该具有唯一性，具有唯一标识记录的功能，但我是不推荐采用订单编号字段作为主键的，因为具有实际意义的字段，具有“意义更改”的可能性，比如订单编号在刚开始的时候我们一切顺利，后来客户说“订单可以作废，并重新生成订单，而且订单号要保持原订单号一致”，这样原来的主键就面临危险了。因此，具有唯一性的实际字段也代表可以作为主键。因此，我推荐是新设一个字段专门用为主键，此主键本身在业务逻辑上不体现，不具有实际意义。而这种主键在一定程序增加了复杂度，所以要视实际系统的规模大小而定，对于小项目，以后扩展不会很大的话，也查允许用实际唯一的字段作主键的。 主键的选择 我们现在在思考一下，应该采用什么来作表的主键比较合理，申明一下，主键的设计没有一个定论，各人有各人的方法，哪怕同一个，在不同的项目中，也会采用不同的主键设计原则。 第一：编号作主键 　

在我们的数据库设计中，不可逃避的就是数据库表的主键，可能有很多朋友没有深入思考过，主键的设计对整个数据库的设计影响很大，因此我们不得不要重视起来。 主键的必要性 : 有些朋友可能不提倡数据库表必须要主键，但在我的思考中，觉得每个表都应该具有主键，不管是单主键还是双主键，主键的存在就代表着表结构的完整性，表的记录必须得有唯一区分的字段，主键主要是用于其他表的外键关联，本记录的修改与删除，当我们没有主键时，这些操作会变的非常麻烦。 主键的无意义性 ： 我强调主键不应该具有实际的意义，这可能对于一些朋友来说不太认同，比如订单表吧，会有“订单编号”字段，而这个字段呢在业务实际中本身就是应该具有唯一性，具有唯一标识记录的功能，但我是不推荐采用订单编号字段作为主键的，因为具有实际意义的字段，具有“意义更改”的可能性，比如订单编号在刚开始的时候我们一切顺利，后来客户说“订单可以作废，并重新生成订单，而且订单号要保持原订单号一致”，这样原来的主键就面临危险了。因此，具有唯一性的实际字段也代表可以作为主键。因此，我推荐是新设一个字段专门用为主键，此主键本身在业务逻辑上不体现，不具有实际意义。而这种主键在一定程序增加了复杂度，所以要视实际系统的规模大小而定，对于小项目，以后扩展不会很大的话，也查允许用实际唯一的字段作主键的。 主键的选择 我们现在在思考一下，应该采用什么来作表的主键比较合理，申明一下

引言 在面试中，大家应该经历过如下场景 面试官:"用过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

关系型 数据库 ： 将复杂的数据结构转换为一个二维表格 即利用 关系模型把数据组织到 一个二维数据 表， 通过 SQL 即结构化查询语句去操作数据 ：后期学习Jpa面向对象查询语句jpql语句操作数据 Oracle Oracle( 甲骨文 / 神域 ) 运行稳定，可移植性高，功能齐全，性能超群！适用于大型企业领域。对企业收费。 DB2 IBM 速度快、可靠性好，适于海量数据，恢复性极强。适用于大中型企业领域。 SQL SERVER 微软 全面，效率高，界面友好，操作容易，但是不跨平台。适用于于中小型企业领域。 MYSQL AB-->SUN-->Oracle 开源免费，体积小，速度快。适用于于中小型企业领域。 非关系型数据库（Not Only SQL） 　　是在关系型数据库上提升 高性能、高并发而生 ； ①　 键值存储（ key-value ）： redis ， Memcached -- 内存数据库（快） ②　 列存储： Hbase ③　 文档型数据库： mongodb ④　 图形数据库： Graph 主键： 关系型数据库一张表中 唯一 的且 非空 称之为主键 （比如id，用户名不重名那种） 　　后期会称它用来保证记录（记录就是一张表一行数据，又称一个对象）的唯一性。简单来说，就是 同一张数据库表中，不允许存在多条相同主键的记录。 外键： 　　外键用于一张表与另一张表的关联

数据库中的主键 我一般采用 GUID，也就是下文中的第5种方式。 这篇文章总结得很全面，我是在CSDN上看到的，现在修改成最初出现的版本了 ：） 原文在： http://tintown.cnblogs.com/archive/2005/03/02/111459.html 数据库主键设计之思考 在我们的数据库设计中，不可逃避的就是数据库表的主键，可能有很多朋友没有深入思考过，主键的设计对整个数据库的设计影响很大，因此我们不得不要重视起来。 主键的必要性 : 有些朋友可能不提倡数据库表必须要主键，但在我的思考中，觉得每个表都应该具有主键，不管是单主键还是双主键，主键的存在就代表着表结构的完整性，表的记录必须得有唯一区分的字段，主键主要是用于其他表的外键关联，本记录的修改与删除，当我们没有主键时，这些操作会变的非常麻烦。 主键的无意义性 ： 我强调主键不应该具有实际的意义，这可能对于一些朋友来说不太认同，比如订单表吧，会有“订单编号”字段，而这个字段呢在业务实际中本身就是应该具有唯一性，具有唯一标识记录的功能，但我是不推荐采用订单编号字段作为主键的，因为具有实际意义的字段，具有“意义更改”的可能性，比如订单编号在刚开始的时候我们一切顺利，后来客户说“订单可以作废，并重新生成订单，而且订单号要保持原订单号一致”，这样原来的主键就面临危险了。因此，具有唯一性的实际字段也代表可以作为主键。因此

SQL级联更新，级联删除 今天做了个测试，搞清楚了级联更新，级联删除 级联删除：当我们没有对键加级联删除的时候，删除主键表中的数据（外键表有引用的数据）时，会报错，不能删除，必须先把相关联的外键数据 删除了，才能删除主键表的数据，但如果新建外键的时候设置了级联删除，那么当我们删除主键表的数据时，数据库就会自动帮我们把相 关联的外键表数据删除掉，这个好理解 级联更新：一直困扰我，级联更新有什么用，是更新什么东西呢，今天做了个测试(mssql)，终于搞清楚了一点，我们修改主键表中和外键表进 行关联的字段(一般是主键表的主键，mssql好像必须是主键)，如果我们没有设置级联更新，那么这个时候会提示不能更新，因为外键表 还有数据正在和这条数据进行关联，但是如果设置了级联更新，那么外键表的数据会自动帮我们更新 今天做了个测试，搞清楚了级联更新，级联删除 级联删除：当我们没有对键加级联删除的时候，删除主键表中的数据（外键表有引用的数据）时，会报错，不能删除，必须先把相关联的外键数据 删除了，才能删除主键表的数据，但如果新建外键的时候设置了级联删除，那么当我们删除主键表的数据时，数据库就会自动帮我们把相 关联的外键表数据删除掉，这个好理解 级联更新：一直困扰我，级联更新有什么用，是更新什么东西呢，今天做了个测试(mssql)，终于搞清楚了一点，我们修改主键表中和外键表进 行关联的字段

.场景介绍: ​ 开发过程中我们经常性的会用到许多的中间表,用于数据之间的对应和关联.这个时候我们关联最多的就是ID,我们在一张表中插入数据后级联增加到关联表中.我们熟知的mybatis在插入数据后返回的是插入成功的条数,那么这个时候我们想要得到相应的这条新增数据的ID,该怎么办呢? 2.插入数据返回自增主键ID方法(一) 在映射器中配置获取记录主键值 xml映射: 在xml中定义useGeneratedKeys为true,返回主键id的值,keyProperty和keyColumn分别代表数据库记录主键字段和java对象成员属性名 <!-- 插入数据:返回记录主键id值 --> <insert id="insert" useGeneratedKeys="true" keyProperty="id" keyColumn="id"> insert into stu (name,age) values (#{name},#{age}) </insert> 接口映射器 在接口映射器中通过注解 @Options 分别设置参数useGeneratedKeys，keyProperty，keyColumn值 // 返回主键字段id值 @Options(useGeneratedKeys = true, keyProperty = "id", keyColumn = "id") @Insert(