公司最近开发了一个新项目，设计表时由于有些字段需要对外展示，所以使用了雪花算法生成的id做主键。
不过有位同事对此提出了异议，认为雪花算法生成的id不是的，会对MySQL的性能造成影响。
经过交流，发现持有这种认知的还有好几位同事，估摸着对此有疑问的朋友也不少，所以今天我们来分析一下， 用雪花算法生成的id做主键，对MySQL性能到底有没有影响？MySQL必须使用连续递增的主键才能发挥最大性能？
既然要分析不同主键的性能，那么就得先了解一下MySQL的数据是如何存储的。
相信只要稍微了解过MySQL的朋友估计都知道，MySQL的InnoDB引擎采用B+树来存储数据，为了数据的安全性，这些数据最终会持久化到磁盘上。
那么我们在查询或者修改数据时，如果每次都把数据全部从磁盘加载到内存好像不太现实，每次只读一条数据又太浪费IO，那怎么办呢？
于是设计MySQL的这些大神们提出了页的概念，即将数据保存到很多个页上面，内存和磁盘交互时以页为单位。
默认情况下，一个页的大小是16KB，也就是说，每次从磁盘会最少加载16KB的数据到内存里。反过来，每次最少把16KB的数据从内存中持久化到磁盘。
这样，时间和空间都利用到了，最大化的保证了性能。
当然，页的种类也有很多，比如保存表空间信息的页，undo日志页，存放数据的数据页等，本文中我们只讨论数据页和目录页。
下图就是一个InnoDB数据页的结构，大家心里有一个印象即可。
User Records就是用来真正保存我们的数据的，我们看一下数据是如何在页中保存的。
需要特别注意的是， 为了性能，这些记录是按照主键的大小按从小到大顺序排放的，最终组成一个单向链表。 另外每个数据页都会生成一个页目录， 通过主键查找某一条记录时通过二分查找法即可快速找到需要的数据。
上面我们提过，一个页默认只有16KB，也就是说存储的数据是有限的，所以当要存储很多数据时，就需要申请很多数据页，如下所示：
从上图中我们可以看到，每个数据页都保存了很多条记录，相邻页之间还通过双向链表保存着联系。
需要注意的是，这些数据页在物理空间上不一定是连续的地址。
到这里我们知道了MySQL通过数据页来存储数据，但是随着表数据的增多，会带来一个很明显的问题：页太多了不好管理。
所以InnoDB的大神们又设计了目录页（目录页+数据页就组成了一颗索引树）。
看名字也知道，目录页只是一个目录，不会存储具体的数据。
它保存的数据其实特别简单：
从上图中我们可以看到，页30是一个目录页（可以把他当做树的根节点），页10、页28、页9、页20是真正存放数据的数据页。
在目录页中，会存放每一个数据页的最小主键id以及对应的页号，并且按照主键id排序。
在数据页中，数据也是按照主键从小到大排序的，并且后一个页的最小记录会比上一个页的最大记录大，总体来说，这些页的数据是递增的。
注意！是递增，但是并没有要求顺序递增。
因为对于二分查找法来说，只要数据是有序递增的，就可以保证其快速查找到我们需要的数据了。
以查找id=8的记录为例，首先在根节点通过二分查找法找到记录5，对应的页号是28，然后找到页28，通过二分法找到主键为8的记录。
现在回到我们的问题，雪花算法生成的id会对MySQL性能造成影响吗？
雪花算法的一大特性是什么呢？
大致递增。
换句话说，只要是递增的，哪怕我们用JAVA的ATOMICInteger或者通过redis的incrmentBy来生成主键id也没问题。
雪花算法就不过多介绍了，有想了解的朋友可以看一下这篇文章。雪花算法介绍。
另外再多说一句：MySQL自增主键虽然申请时是表级全局递增的，但是最后保存到表中就不一定了。
举个简单的例子，批量保存10条数据，由于某些原因，这个事务操作回滚了。当你再插入一条数据时，你会发现上次申请的10个id已经被浪费掉了，表中的id是从11开始的。
MySQL的数据结构和索引是一个庞大的系统，很难通过一篇简单的文章将其彻底讲清楚，如果你对本文有不同见解，也欢迎在评论区交流。
sql中sequence的用法
insert into PRODUCT (你建的序列,PRD_DESCRIPTION) values (id,description） 在每次插入数据的时候，id都会按你建的序列的增量自动增加。 sequence就是所谓的序列号，每次取的时候它会自动增加，一般用在需要按序列号排序的地方。 1、 create sequence你首先要有create sequence或者create any sequence权限，create sequence emp_sequenceINCREMENT BY 1 -- 每次加几个Start WITH 1 -- 从1开始计数NOMAXVALUE -- 不设置最大值NOCYCLE -- 一直累加，不循环CACHE 10;一旦定义了emp_sequence，你就可以用CURRVAL，NEXTVALCURRVAL=返回sequence的当前值NEXTVAL=增加sequence的值，然后返回sequence值比如：emp__可以使用sequence的地方：- 不包含子查询、snapshot、VIEW的 SELECT 语句- INSERT语句的子查询中- NSERT语句的VALUES中- UPDATE 的 SET中可以看如下例子：INSERT INTO emp VALUES(, LEWIS, CLERK,7902, SYSDATE, 1200, NULL, 20);SELECT FROM DUAL;但是要注意的是：- 第一次NEXTVAL返回的是初始值；随后的NEXTVAL会自动增加你定义的INCREMENT BY值，然后返回增加后的值。 CURRVAL 总是返回当前sequence的值，但是在第一次NEXTVAL初始化之后才能使用CURRVAL，否则会出错。 一次NEXTVAL会增加一次sequence的值，所以如果你在同一个语句里面使用多个NEXTVAL，其值就是不一样的。 明白？- 如果指定CACHE值，oracle就可以预先在内存里面放置一些sequence，这样存取的快些。 cache里面的取完后，oracle自动再取一组到cache。 使用cache或许会跳号， 比如数据库突然不正常down掉（shutdown abort),cache中的sequence就会丢失. 所以可以在create sequence的时候用nocache防止这种情况。 2、 Alter sequence你或者是该sequence的owner，或者有ALTER ANY sequence权限才能改动sequence。 可以alter除start值之外的所有sequence参数。 如果想要改变start值，必须drop sequence再re-create。 例子：ALTER sequence emp_sequenceINCREMENT BY 10MAXVALUE CYCLE -- 到后从头开始NOCACHE;影响sequence的初始化参数：sequence_CACHE_ENTRIES =设置能同时被cache的sequence数目。 可以很简单的Drop sequenceDROP sequence order_seq;sequence的用法：create seqence sequence_name[start with n1] ----------------->n1到n5都是整数；start with 生成的第一个n1值[increment by n2]-----------------> increment by n2 递增量,可以为正整数或负整数，指明每一次增加多少[maxvalue n3|no maxvalue]----------------->maxvalue最大值，no maxvalue用于指定序列没有上限[minvalue n4|no minvalue]----------------->minvalue 最小值，no minvalue,没有指定最小下限[cache n5|no cache] ----------------->cache 用高速缓存中可以预分配的序列号个数,默认是20。 如果缓存中的序列号没有用完就关闭数据库等其它原因.使用 sequenceCURRVAL 和 NEXTVAL 能够在以下情况使用:insert的values字句、select中的select列表、update中的set字句CURRVAL 和 NEXTVAL 不能够在以下情况使用:子查询、视图和实体化视图的查询、带distinct的select语句、带 group by和order by的select语句、带union或intersect或minus的select语句、select中的where字句、create table与alter table中的default值、check约束条件。 删除sequencedrop sequence seq_a;当删除sequence后，对应它的同义词会被保留，但是引用时会报错。 oracle rac环境中的sequenceoracle为了在rac环境下为了sequence的一致性，使用了三种锁：row cache lock、SQ锁、SV锁。 row cache lock的目的是在sequence指定nocache的情况下调用过程中保证序列的顺序性；SQ锁是应用于指定了cache+noorder的情况下调用过程中。 SV 锁（dfs lock handel) 是调用期间拥有的锁。 前提是创建sequence时指定了cache 和order属性 (cache+order)。 order参数的目的是为了在RAC上节点之间生成sequence的顺序得到保障。 创建sequence赋予的cache值较小时，有enq:sq-contention等待增加的趋势。 cache的缺省值是20.因此创建并发访问多的sequence时，cacheh值应取大一些。 否则会发生enq:sq-contention等待事件。 rac上创建sequence时，如果指定了cache大小而赋予noorder属性，则各节点将会把不同范围的sequence值cache到内 存上。 若两个节点之间都必须通过依次递增方式使用sequence，必须赋予如下的order属性（一般不需要这样做）”sql> create sequence seq_b cache 100 order”。 如果是已赋予了cache+order属性的sequence，oracle使用SV锁进行同步。 SV锁争用问题发生时的解决方法与sq锁 的情况相同，就是将cache 值进行适当调整。 在RAC多节点环境下，Sequence的Cache属性对性能的影响很大。 应该尽量赋予cache+noorder属性，并要给予足够的 cache值。 如果需要保障顺序，必须赋予cache+order属性。 但这时为了保障顺序，实例之间需要不断的交换数据。 因此性能稍差。 扩展资料：seqence的作用：sequence号是数据库系统按照一定规则自增的数字序列，因为自增所以不会重复。 目前就我所了解的sequence的作用主要有两个方面。 一：作为代理主键，唯一识别；二：用于记录数据库中最新动作的语句，只要语句有动作(insert/delete等)，sequence号都会随着更新，所以我们可以根据sequence号来select出更新的语句。
请大伙给我解释一下数据库设计的基本原则！
设计数据库不应该有这些： 1数据冗余 2不一致性 3插入异常 4删除异常
这图就出现了问题 如人工智能的学分不一致有两个文化学这就出现了以上的问题 所以要杜绝 我们可以这样分为两个表 如下：
右边的表只要把人工智能的删除一个就好了（画错了不好意思）
在就是函数的一些关系 如函数依赖 ：
v函数依赖设R(U)是一个属性集U上的关系，X和Y是U的子集。如果属性集合X中每个属性的值构成的集合唯一地决定了属性集合Y中每个属性的值构成的集合，则属性集合Y函数依赖于属性集合X，计为：X→Y如下表所示，知道了“课程名”的值，即可知道“授课学时”的值。称“授课学时”函数依赖于“课程名”，或“课程名”可以决定“授课学时”，记作课程名→授课学时。还有这个
v部分函数依赖：如果非主属性B函数依赖于构成某个候选关键字的一组主属性A的某一个真子集，则称B部分函数依赖于A。 v如“学分”函数依赖于主关键字{学号、课程}。 但决定“学分”的只是“课程”，与“学号”无关，则称“学分”部分函数依赖于{学号、课程} 。
传递关系：
v传递函数依赖的关系：在R (U)中，如存在X，Y，Z包含于U，且满足：X—>Y，Y—>Z，则称Z传递函数依赖于X。 v学生住宿的楼号依赖于学号，学生应交的住宿费是由楼号决定的，即“收费”依赖于“楼号”，“楼号”依赖于“学号”，则“收费”传递函数依赖于“学号”。
接下来的就是要符合范式：
第一范式：
任何符合关系定义的表即满足第一范式。
ID Name Sex Age Male Female 101 张三 Y 20 102 李四 Y 21v第二范式定义：如果一个关系不存在部分依赖关系，那么该关系就属于第二范式。 凡是以单个属性作为主关键字的关系自动就是第二范式。 因为主关键字只有一个，不会存在部分依赖的情况。 因此，第二范式只是针对主关键字是组合属性的关系。
第三范式v定义：一个关系如果是第二范式的，并且没有传递依赖关系，则该关系就是第三范式。 v每个非主属性不部分依赖于关键字，也不传递依赖于关键字的关系。
关系规范化的目的：解决关系模式中存在的插入、删除异常，以及数据冗余问题，基本思想：围绕函数依赖的主线，对一个关系模式进行分解，使关系从较低级范式变换到较高级范式。
以上也就是设计数据库基本注意的问题 我也是初学者 只能帮忙这些不知道是否对你有用！
4、空间数据库中,矢量数据的管理方式有哪些,各有什么优缺点?
1、文件-关系数据库混合管理方式不足：①属性数据和图形数据通过ID联系起来，使查询运算，模型操作运算速度慢；② 数据分布和共享困难；③属性数据和图形数据分开存储，数据的安全性、一致性、完整性、并发控制以及数据损坏后的恢复方面缺少基本的功能；④缺乏表示空间对象及其关系的能力。 因此，目前空间数据管理正在逐步走出文件管理模式。 2、全关系数据库管理方式对于变长结构的空间几何数据，一般采用两种方法处理。 ⑴ 按照关系数据库组织数据的基本准则，对变长的几何数据进行关系范式分解，分解成定长记录的数据表进行存储。 然而，根据关系模型的分解与连接原则，在处理一个空间对象时，如面对象时，需要进行大量的连接操作，非常费时，并影响效率。 ⑵ 将图形数据的变长部分处理成Binary二进制Block块字段。 3、对象-关系数据库管理方式由于直接采用通用的关系数据库管理系统的效率不高，而非结构化的空间数据又十分重要，所以许多数据库管理系统的软件商在关系数据库管理系统中进行扩展，使之能直接存储和管理非结构化的空间数据。 这种扩展的空间对象管理模块主要解决了空间数据的变长记录的管理，由数据库软件商进行扩展，效率要比前面所述的二进制块的管理高得多。 但是它仍然没有解决对象的嵌套问题，空间数据结构也不能内用户任意定义，使用上仍受到一定限制。 矢量图形数据与属性数据的管理问题已基本得到解决。 从概念上说，空间数据还应包括数字高程模型、影像数据及其他专题数据。 虽然利用关系数据库管理系统中的大对象字段可以分块存贮影像和DEM数据，但是对于多尺度DEM数据，影像数据的空间索引、无缝拼接与漫游、多数据源集成等技术还没有一个完整的解决方案。
发表评论