数据库主键

　　在一个分布式环境中，我们习惯使用GUID做主键，来保证全局唯一，然后，GUID做主键真的合适吗？ 　　其实GUID做主键本身没有问题，微软的很多项目自带DB都是使用GUID做主键的，显然，这样做是没有问题的。然而，SQL Server默认会将主键设置为聚集索引，使用GUID做聚集索引就有问题了。很多时候程序员容易接受SQL Server这一默认设置，但无序GUID做聚集索引显然是低效的。 　　那么，我们在项目中如何避免这一问题呢？ 　　主要的思路还是两方面——方案一，选择合适的列作为聚集索引；方案二，使用有序的主键。 1 方案一，选择合适的列做聚集索引 　　选择原则很简单——字段值尽量唯一，字段占用字节尽量小，字段值很少修改，字段多用于查询范围数据或排序的数据。 　　之所以是根据以上原则选择，主要还是基于B+树数据索引问题，这部分内容都比较基础，这里就不举例验证了，以上原则还是比较公认的，即便读者不太理解其中原理，也请记住这一选择规则。 　　常见的备选项——自增列（Id）和时间列（CreateTime）。 　　聚集索引的最大用处就是帮助范围查询快速定位，从而减小数据库IO的消耗来提升查询效率。对于范围查询我们更多的应用在自增列和时间列上，因为这两列本身反应了数据的创建顺序，符合多数范围查询的场景需要。 　　大部分时候，我们仍然可以使用GUID做主键，只需要重新设置聚集索引就行。

原文: http://blog.gqylpy.com/gqy/253 目录 普通索引 唯一索引 主键索引 组合索引 正确使用索引的情况 索引的注意事项 执行计划 axplain 慢日志记录 分页性能相关方案 索引是数据库中专门用于帮助用户快速查找数据的一种数据结构. 类似于字典中的目录，查找字典内容可以根据目录查找到数据的存放位置，然后直接获取. 作用：约束和加速查找 常见的几种索引： - 普通索引 - 唯一索引 - 主键索引 - 联合索引（多列） -- 联合主键索引 -- 联合唯一索引 -- 联合普通索引 无索引和有索引的区别： 无索引： 从前往后一条一条查询. 有索引： 创建索引的本质，就是创建额外的文件，以某种格式存储，查询的时候，先去额外的文件找，确定了位置，然后再去原始表中直接查询，但是创建的索引越多，越会对硬盘有损耗. ——————————— 建立索引的目的： 额外的文件保存特殊的数据结构 查询快，但是插入更新删除依旧慢 创建索引之后，必须命中索引才能有效 索引的种类： hash索引： 查询单条快，范围查询慢 btre类索引： b+树，层数增多，数据量指数级增长 （InnoDB默认支持btree索引，这里就使用它） 索引名词： 覆盖索引： 在索引文件中直接获取数据 （例如：select name from userinfo where name = 'zyk';)

作为免费又高效的数据库，mysql基本是首选。良好的安全连接，自带查询解析、sql语句优化，使用读写锁（细化到行）、事物隔离和多版本并发控制提高并发，完备的事务日志记录，强大的存储引擎提供高效查询（表记录可达百万级），如果是InnoDB，还可在崩溃后进行完整的恢复，优点非常多。即使有这么多优点，仍依赖人去做点优化，看书后写个总结巩固下，有错请指正。 　　完整的mysql优化需要很深的功底，大公司甚至有专门写mysql内核的，sql优化攻城狮，mysql服务器的优化，各种参数常量设定，查询语句优化，主从复制，软硬件升级，容灾备份，sql编程，需要的不是一星半点的知识与时间来掌握，作为一名像俺这样的菜鸟开发，强吃这么多消化不了也没意义：没地儿用啊，况且还有运维和dba，还不如把手头的业务写好，也就是写好点的sql，而且很多sql语句优化跟索引还是有很大关系的。 　　首先，mysql的查询流程大致是：mysql客户端通过协议与mysql服务器建立连接，发送查询语句，先检查查询缓存，如果命中，直接返回结果，否则进行语句解析，有一系列预处理，比如检查语句是否写正确了，然后是查询优化（比如是否使用索引扫描，如果是一个不可能的条件，则提前终止），生成查询计划，然后查询引擎启动，开始执行查询，从底层存储引擎调用API获取数据，最后返回给客户端。怎么存数据、怎么取数据，都与存储引擎有关。然后

1062 Duplicate entry '...' for key 'PRIMARY指的是主键重复或者唯一索引重复。 本来mysql表中未设主键和唯一索引，准备加上，但是设置的时候总是提示1062，提示的数据我看了，只有一行，并没有重复。 开始疯狂百度、谷歌，有说主从插入重复的，我直接把从数据库删了，依然报错、崩溃！！！ 最后发现问题所在，把存储引擎由MyISAM 改成InnoDB，虽然依然有提示1062，但是提示的数据都是重复的， 也就是说当存储引擎是MyISAM 时，设置主键或者唯一索引时，如果有重复数据会提示1062但是提示的数据是最新一条的数据（错误的，没办法判断到底哪条有重复），当存储引擎是InnoDB时会提示正确的重复的那条数据。 来源： https://www.cnblogs.com/lwx521/p/11410377.html

目录 MySQL主键设计原则 主键设计的常用方案 自增ID UUID 自定义序列表 如何解决水平分片的需求 UUID 独立的序列库 复合标识符 带分库策略的自定义序列表 主键的必要性 主键的数据类型选择 在项目过程中遇到一个看似极为基础的问题，但是在深入思考后还是引出了不少问题，觉得有必要把这一学习过程进行记录。 MySQL主键设计原则 MySQL主键应当是对用户没有意义的。 MySQL主键应该是单列的，以便提高连接和筛选操作的效率 永远也不要更新MySQL主键 MySQL主键不应包含动态变化的数据，如时间戳、创建时间列、修改时间列等 MySQL主键应当有计算机自动生成。 主键设计的常用方案 自增ID 优点 ： 1、数据库自动编号，速度快，而且是增量增长，聚集型主键按顺序存放，对于检索非常有利。 2、 数字型，占用空间小，易排序，在程序中传递方便。 缺点 ： 1、不支持水平分片架构，水平分片的设计当中，这种方法显然不能保证全局唯一。 2、表锁 在MySQL5.1.22之前，InnoDB自增值是通过其本身的自增长计数器来获取值，该实现方式是通过表锁机制来完成的（AUTO-INC LOCKING）。锁不是在每次事务完成后释放，而是在完成对自增长值插入的SQL语句后释放，要等待其释放才能进行后续操作。比如说当表里有一个auto_increment字段的时候

范式一： 一范式就是属性不可分割。属性是什么？就是表中的字段。 不可分割的意思就按字面理解就是最小单位，不能再分成更小单位了。 这个字段只能是一个值，不能被拆分成多个字段，否则的话，它就是可分割的，就不符合一范式。 不过能不能分割并没有绝对的答案，看需求，也就是看你的设计目标而定。 举例： 学生信息组成学生信息表，有姓名、年龄、性别、学号等信息组成。 姓名不可拆分吧？所以可以作为该表的一个字段。 但我要说这个表要在国外使用呢？人家姓和名要分开，都有特别的意义，所以姓名字段是可拆分的，分为姓字段和名字段。 简单来说，一范式是关系数据库的基础，但字段是否真的不可拆分，根据你的设计目标而定。 范式二： 二范式就是要有主键，要求其他字段都依赖于主键。 为什么要有主键？没有主键就没有唯一性，没有唯一性在集合中就定位不到这行记录，所以要主键。 其他字段为什么要依赖于主键？因为不依赖于主键，就找不到他们。更重要的是，其他字段组成的这行记录和主键表示的是同一个东西，而主键是唯一的，它们只需要依赖于主键，也就成了唯一的。 如果有同学不理解依赖这个词，可以勉强用“相关”这个词代替，也就是说其他字段必须和它们的主键相关。因为不相关的东西不应该放在一行记录里。 举例： 学生信息组成学生表，姓名可以做主键么？ 不能！因为同名的话，就不唯一了，所以需要学号这样的唯一编码才行。 那么其他字段依赖于主键是什么意思

一. 数据切分 关系型数据库本身比较容易成为系统瓶颈，单机存储容量、连接数、处理能力都有限。当单表的数据量达到1000W或100G以后，由于查询维度较多，即使添加从库、优化索引，做很多操作时性能仍下降严重。此时就要考虑对其进行切分了，切分的目的就在于减少数据库的负担，缩短查询时间。 数据库分布式核心内容无非就是数据切分（Sharding） ，以及切分后对数据的定位、整合。数据切分就是将数据分散存储到多个数据库中，使得单一数据库中的数据量变小，通过扩充主机的数量缓解单一数据库的性能问题，从而达到提升数据库操作性能的目的。 数据切分根据其切分类型，可以分为两种方式： 垂直（纵向）切分和水平（横向）切分 1、垂直（纵向）切分 垂直切分常见有垂直分库和垂直分表两种。 垂直分库 就是根据业务耦合性，将关联度低的不同表存储在不同的数据库。做法与大系统拆分为多个小系统类似，按业务分类进行独立划分。与"微服务治理"的做法相似，每个微服务使用单独的一个数据库。如图： 垂直分表 是基于数据库中的"列"进行，某个表字段较多，可以新建一张扩展表，将不经常用或字段长度较大的字段拆分出去到扩展表中。在字段很多的情况下（例如一个大表有100多个字段），通过"大表拆小表"，更便于开发与维护，也能避免跨页问题，MySQL底层是通过数据页存储的，一条记录占用空间过大会导致跨页，造成额外的性能开销

一、索引概念 1.什么是索引： 索引在MySQL中也叫做“键”，是存储引擎用于快速找到记录的一种数据结构。 索引就是一种数据结构，类似于书的目录。意味着以后再查数据应该先找目录再找数据，而不是用翻页的方式查询数据 本质都是：通过不断地缩小想要获取数据的范围来筛选出最终想要的结果，同时把随机的事件变成顺序的事件（比如书没目录就只能随机翻），也就是说，有了这种索引机制，我们可以总是用同一种查找方式来锁定数据（永远就是按照索引去找，不用正着翻反着翻了）。 补充：innodb引擎只有表结构和数据两个文件夹，不像myisam三个文件有单独的索引文件，表结构中不可能放别的，所以索引是和数据放在一个文件中的 2.三种索引（键）： primary key unique key index key 注意foreign key不是用来加速查询用的，不在我们研究范围之内, 上面三种key前两种除了有加速查询的效果之外还有额外的约束条件(primary key:非空且唯一，unique key:唯一)，而index key没有任何约束功能只会帮你加速查询 3.索引的影响（缺点）: 在表中有大量数据的前提下，创建索引速度会很慢 （例如一本书特别厚，你需要一页一页去查看有什么内容一页一页建目录，所以如果数据量特别大时你命令敲完之后，终端会卡很长一段时间去疯狂的建索引） 在索引创建完毕后

关系型数据库的三大范式： 第一范式（1NF）：要求数据库表的每一列都是不可分割的原子数据项 假如有一列是存放地址：xx省xx市，但是在存取数据时需要按照xx省xx市两个因素来操作，那么该数据库的表就不满足1NF 第二范式（2NF）： 在第一范式的基础上，确保数据库表中的每一列都和主键相关，而不能只与主键的某一部分相关 第三范式（3NF）：在2NF的基础上，需要确保数据表中的每一列数据都和主键直接相关而不能间接相关 来源： https://www.cnblogs.com/lijiangjun/p/11399439.html

前言 使用Mybatis的开发者，大多数都会遇到一个问题，就是要写大量的SQL在xml文件中， 除了特殊的业务逻辑SQL之外，还有大量结构类似的增删改查SQL 。而且，当数据库表结构改动时，对应的所有SQL以及实体类都需要更改。这工作量和效率的影响或许就是区别增删改查程序员和真正程序员的屏障。这时，通用Mapper便应运而生…… 什么是通用Mapper 通用Mapper就是 为了解决单表增删改查 ，基于Mybatis的插件。开发人员不需要编写SQL， 不需要在DAO中增加方法，只要写好实体类，就能支持相应的增删改查方法 。 如何使用 以MySQL为例，假设存在这样一张表： CREATE TABLE `test_table` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `name` varchar(255) DEFAULT '', `create_time` datetime DEFAULT NULL, `create_user_id` varchar(32) DEFAULT NULL, `update_time` datetime DEFAULT NULL, `update_user_id` varchar(32) DEFAULT NULL, `is_delete` int(8) DEFAULT NULL, PRIMARY KEY (`id