数据库主键

该文为《 MySQL 实战 45 讲》的学习笔记，感谢查看，如有错误，欢迎指正 一、索引简介 索引就类似书本的目录，作用就是方便我们更加快速的查找到想要的数据。 索引的实现方式比较多，常见的有 哈希表 ， 有序数组 ， 搜索树 。 1.1 哈希表 哈希表 是将数据以 key-value 的形式存储起来，简单来说就是将 key 通过哈希函数换算成数组中的一个确定的位置，将 value 存到这个位置去。当 key 比较多时，有可能换算出相同的位置，此时可以通过链表来解决。在查询时先找到位置，再对该位置的多个 value 进行遍历。 哈希表适合用于等值查询 ，由于是无序的，不适合用来做区间查询。 1.2 有序数组 有序数组 在等值查询和区间查询上效率都很高。由于是有序的，可以通过二分法快速得到结果。也支持范围查询。但是也有一个缺点，如果要在中间插入一个数据，那么后面的所有记录都要向后挪一位，成本太高了。 因此， 有序数组只适用于静态存储引擎 。 例如我们要保存2019年的出生人口信息，就适合用有序数组。 1.3 搜索树 常见的搜索树有 二叉 ，也有 多叉 。 二叉树 的特点是： 每个节点的左儿子小于父节点，父节点又小于右儿子。 多叉树 的特点是： 每个节点有多个儿子，儿子之间的大小保证从左到右递增。 由于索引不止存在内存中，还会写到磁盘上，而读磁盘越多，查询效率越慢

数据库约束的种类 约束名 约束关键字 主键 primary key 唯一 unique 非空 not null 外键 foreign key 检查约束 check 注:mysql 不支持，sql支持 主键约束 创建主键方式 在创建表的时候给字段添加主键 字段名 字段类型 PRIMARY KEY 例1: CREATE TABLE tb_info ( id INT PRIMARY KEY, name VARCHAR(30), age INT ); 例2: CREATE TABLE tb_info ( id INT, name VARCHAR(30), age INT, PRIMARY KEY(id) ); 在已有表中添加主键 ALTER TABLE 表名 ADD PRIMARY KEY(字段名); 例： ALTER TABLE tb_info ADD PRIMARY KEY(id); 删除主键的方式 删除单表主键约束 ALTER TABLE 表名 DROP PRIMARY KEY; 删除有外键连接的表的主键 第一步：解除外键约束 ALTER TABLE 外键表 DROP FOREIGN KEY 外键名称 第二步：删除主键 ALTER TABLE 主键表 DROP PRIMARY KEY; 如：删除tb1的主键 这里有两个表，tb2的外键连接tb1的主键 第一步：解除与tb2的外键约束

1.命名规范 1.库名、表名、字段名必须使用小写字母，并采用下划线分割。 a)MySQL有配置参数lower_case_table_names，不可动态更改，linux系统默认为 0，即库表名以实际情况存储，大小写敏感。如果是1，以小写存储，大小写不敏感。如果是2，以实际情况存储，但以小写比较。 b)如果大小写混合使用，可能存在abc，Abc，ABC等多个表共存，容易导致混乱。 c)字段名显示区分大小写，但实际使⽤用不区分，即不可以建立两个名字一样但大小写不一样的字段。 d)为了统一规范， 库名、表名、字段名使用小写字母。 2.库名、表名、字段名禁止超过32个字符。 库名、表名、字段名支持最多64个字符，但为了统一规范、易于辨识以及减少传输量，禁止超过32个字符。 3.使用INNODB存储引擎。 INNODB引擎是MySQL5.5版本以后的默认引擘，支持事务、行级锁，有更好的数据恢复能力、更好的并发性能，同时对多核、大内存、SSD等硬件支持更好，支持数据热备份等，因此INNODB相比MyISAM有明显优势。 4.库名、表名、字段名禁止使用MySQL保留字。 当库名、表名、字段名等属性含有保留字时，SQL语句必须用反引号引用属性名称，这将使得SQL语句书写、SHELL脚本中变量的转义等变得⾮非常复杂。 5.禁止使用分区表。 分区表对分区键有严格要求；分区表在表变大后，执⾏行DDL

1、分类 　　MySQL索引分为 普通索引、唯一索引、主键索引、组合索引、全文索引 。索引不会包含有null值的列，索引项可以为null（唯一索引、组合索引等），但是只要列中有null值就不会被包含在索引中。 （1）普通索引：create index index_name on table(column)； 或者创建表时指定，create table(..., index index_name column); （2）唯一索引：类似普通索引，索引列的值必须唯一（可以为空，这点和主键索引不同） create unique index index_name on table(column)；或者创建表时指定unique index_name column （3）主键索引：特殊的唯一索引，不允许为空，只能有一个，一般是在建表时指定primary key(column) （4）组合索引：在多个字段上创建索引，遵循最左前缀原则。alter table t add index index_name(a,b,c); 　　 最左前缀原则 ： https://mp.weixin.qq.com/s/RemJcqPIvLArmfWIhoaZ1g （5）全文索引：主要用来查找文本中的关键字，不是直接与索引中的值相比较，像是一个搜索引擎，配合match against使用，现在只有char，varchar

引言 近期由于复习了一下mysql的内容，有些心得。随手讲其中一部分知识，都是一些烟哥自己平时工作的总结以及经验。大家看完，其实能避开很多坑。而且很多问题，都是面试中实打实会问到的！ 比如 OK，具体有下面这些问题 1、为什么一定要设一个主键？ 2、你们主键是用自增还是UUID? 3、主键为什么不推荐有业务含义? 4、表示枚举的字段为什么不用enum类型？ 5、货币字段用什么类型? 6、时间字段用什么类型? 7、为什么不直接存储图片、音频、视频等大容量内容? 8、字段为什么要定义为NOT NULL? 其实上面这些问题，我最早想法是，每个问题都可以啰嗦出一篇文章。后来由于良心发现，烟哥就决定用一篇文章将这些问题都讲明白。 当然，我给的回答可能并非标准答案，毕竟是自己的一些工作总结。各位读者有更好的回答，也欢迎交流！ 这里我要说一下，我用mysql只用过 innodb 存储引擎，其他的引擎真没用过。因此我的回答，都是基于 innodb 存储引擎中的。 正文 问题1:为什么一定要设一个主键？ 回答 :因为你不设主键的情况下，innodb也会帮你生成一个隐藏列，作为自增主键。所以啦，反正都要生成一个主键，那你还不如自己指定一个主键，在有些情况下，就能显式的用上主键索引，提高查询效率！ 问题2:主键是用自增还是UUID? 回答 :肯定答自增啊。innodb 中的主键是聚簇索引

　　索引的目的在于提高查询效率，它的作用就相当于一本书的目录； 1. 常见的索引模型 1.1 哈希表 　　优点：适用于等值查询的场景； 　　缺点：范围查询效率较低； 1.2 有序数组 　　优点：范围查询和等值查询效率较高； 　　缺点：插入、删除操作效率较低； 　　适用于静态存储引擎，保存一些不会修改的数据； 1.3 搜索树 　　二叉树是一个经典的数据结构，增删改查效率都不错。不过由于索引需要存储在磁盘中，使用二叉树时，当节点数量很大时，树的高度会变的很高，一次查询可能访问很多数据块，由于磁盘IO问题，导致效率偏低； 　　为了查询中尽量减少磁盘IO，必须访问尽量少的数据块，N叉树就是一个不错的选择；N叉树由于 读写性能上的优点 ，以及 适配磁盘的访问模式 ，已经广泛的用于搜索引擎。 　　磁盘IO是非常高昂的操作， 当进行一次磁盘IO时，不光把当前磁盘地址的数据，而是把相邻的数据也都读取到内存缓冲区内 ，因为 局部预读性原理 告诉我们，当计算机访问一个地址的数据的时候，与其相邻的数据也会很快被访问到。每一次IO读取的数据我们称之为一页(page)。具体一页有多大数据跟操作系统有关，一般为4k或8k，也就是我们读取一页内的数据时候，实际上才发生了一次磁盘IO。 　　设计数据库时，我们可以将N叉树的一个节点的大小设计为刚好一个操作系统的数据页大小

原网址:http://www.cnblogs.com/zc22/archive/2011/05/30/2063365.html 我们的游戏上个星期经历了第一个数据合服。简单说，就是把2个数据库合并在一个数据库，让2个服务器的玩家一起玩。 过程简直是惊心动魄，最终还是安全完成任务。 本文就分享下合服的各种技术细节。 需求说明： -------------------------- 要把2个服务器玩家合并，首先外部对玩家而言是不变的，包括了登陆游戏的URL，游戏中的角色等；但是物理上，确是一台服务器一个数据库。 简单的说，一服的玩家用一服入口登陆，玩一服账号；二服的玩家用二服入口登陆，玩二服账号； 即使我只有1个账号，但是不同入口登陆，依然能使用不同游戏账号进行游戏。 数据库设计 -------------------------- 要实现合服，首先表主键必须全部使用代码生成，并用服务器编码作为前缀。 例如我的一服表主键就是 001GMxxxxxxxxxxxxxxxx。 二服就是002GMxxxxxxxxxxxxxxxx。这样合服的时候，就不需要对数据进行预处理了。直接导入。 其次，使用平台用户使用一个账号，登陆不同服，要获得不同账号，因此在游戏的玩家表，要通过服务器编码进行区分，例如： Usr_Profile :usercode 主键 :username 平台账号

作者：格物 https://shockerli.net/post/1000-line-mysql-note/ 选择类型 -- PHP角度 1. 功能满足 2. 存储空间尽量小，处理效率更高 3. 考虑兼容问题 -- IP存储 ---------- 1. 只需存储，可用字符串 2. 如果需计算，查找等，可存储为4个字节的无符号int，即unsigned 1) PHP函数转换 ip2long可转换为整型，但会出现携带符号问题。需格式化为无符号的整型。 利用sprintf函数格式化字符串 sprintf("%u", ip2long('192.168.3.134')); 然后用long2ip将整型转回IP字符串 2) MySQL函数转换(无符号整型，UNSIGNED) INET_ATON('127.0.0.1') 将IP转为整型 INET_NTOA(2130706433) 将整型转为IP 列属性（列约束） 1. PRIMARY 主键 - 能唯一标识记录的字段，可以作为主键。 - 一个表只能有一个主键。 - 主键具有唯一性。 - 声明字段时，用 primary key 标识。 也可以在字段列表之后声明 例：create table tab ( id int, stu varchar(10), primary key (id)); - 主键字段的值不能为null。 -

https://segmentfault.com/a/1190000010991930 索引(key)是存储引擎用于快速找到记录的一种数据结构。它和一本书中目录的工作方式类似——当要查找一行记录时，先在索引中快速找到行所在的位置信息，然后再直接获取到那行记录。 在MySql中，索引是在存储引擎层而不是服务器层实现的，所以不同的存储引擎对索引的实现和支持都不相同。 B-TREE索引 B-TREE索引是使用最多的索引。很多存储引擎采用的都是B-TREE数据结构的变体实现该索引，例如InnoDB使用的是B+TREE，即每个叶子节点都包含指向下一个叶子节点的指针，从而方便叶子节点范围遍历。 不同存储引擎使用B-TREE索引的方式也不同。例如MyISAM使用前缀压缩技术使索引更小，而InnoDB则按照原数据格式进行存储。再如MyISAM索引通过数据的物理位置引用被索引的行，而InnoDB则根据主键引用被索引的行。 B-TREE中的所有值都是按顺序存储的，每个叶子页到根的距离相同。下图展示了InnoDB中的B-TREE索引是如何工作的： 当查找一行记录时，存储引擎会先在索引中搜索。从索引的根节点开始，通过比较节点页的值和要查找的值逐层进入下层节点，最底层叶子节点的指针指向的是被索引的数据。这样的查找方式避免了全表扫描，加快访问数据的速度。此外因为B-Tree对索引列是顺序存储的

1. 什么是索引? 索引是一种数据结构,可以帮助我们快速的进行数据的查找. 2. 索引是个什么样的数据结构呢? 索引的数据结构和具体存储引擎的实现有关, 在MySQL中使用较多的索引有Hash索引,B+树索引等,而我们经常使用的InnoDB存储引擎的默认索引实现为:B+树索引. 3. Hash索引和B+树所有有什么区别或者说优劣呢? 首先要知道Hash索引和B+树索引的底层实现原理: hash索引底层就是hash表,进行查找时,调用一次hash函数就可以获取到相应的键值,之后进行回表查询获得实际数据.B+树底层实现是多路平衡查找树. 对于每一次的查询都是从根节点出发,查找到叶子节点方可以获得所查键值,然后根据查询判断是否需要回表查询数据. 那么可以看出他们有以下的不同: hash索引进行等值查询更快(一般情况下),但是却无法进行范围查询. 因为在hash索引中经过hash函数建立索引之后,索引的顺序与原顺序无法保持一致,不能支持范围查询.而B+树的的所有节点皆遵循(左节点小于父节点,右节点大于父节点,多叉树也类似),天然支持范围. hash索引不支持使用索引进行排序,原理同上. hash索引不支持模糊查询以及多列索引的最左前缀匹配.原理也是因为hash函数的不可预测. AAAA 和 AAAAB 的索引没有相关性. hash索引任何时候都避免不了回表查询数据,而B+树在符合某些条件