尽量为innodb表指定主键

最新推荐文章于 2024-07-09 12:45:00 发布
原创 最新推荐文章于 2024-07-09 12:45:00 发布 · 908 阅读 · 0 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。

本文介绍了InnoDB数据库中不指定主键时系统的行为，并强调了指定主键的重要性以提高并发性能。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

如果不指定主键，InnoDB会产生一个全局的rowid序列。所有InnoDB非主键表共享这一序列，并发性能较差，因此建议所有InnoDB表，指定主键。
8.1.2 创建数据表时指定主键
weixin_41275260的博客
06-25 2020
8.1.2　创建数据表时指定主键 在MySQL中创建数据表时，可以为数据表指定主键。主键又被称为主码，包含表中的一列或者多列，能够唯一标识表中的一行记录。同时，主键列的数据必须唯一，并且不能为空。主键可以分为单列主键和多列联合主键。 1．单列主键 单列主键只包含数据表中的一个字段，可以在定义数据列的同时指定主键，也可以在定义完数据表中的所有列之后指定主键。 （1）在定...
InnoDB rowid管理
帅的数说
04-01 860
1、流程原理图2、讲解在innodb表中，并不是每个行记录都存有row ID，只有表定义没有主键时，才会使用rowid并作为主键。rowid的分配是全局的，所有的表都共享这个ID，即从在dict_sys->mutex锁内获取dict_sys->row_id中的值。并不是每次插入操作都将rowid的值写入到字典页面中，插入操作相对于建表等操作频繁多了，所以如果每次都写入字典页面中的话，将...
MySQL InnoDB数据表不设置主键
weixin_42379509的博客
11-11 948
3、第三种情况：用户既没有定义主键，也没有定义唯一索引，那么InnoDB会自动生成一个不可见的ROW_ID的列名为GEN_CLUST_INDEX的聚簇索引，该列是一个6字节的自增数值，随着插入而自增。而且不设置主键不单单影响到查询，在进行写操作的时候，由于ROW_ID是共享的，这意味着插入的时候需要共享该序列，那么高并发插入的时候为了保持唯一性就避免不了锁的竞争，进而影响性能。由以上分析可以推论，在建表的时候无论如何都要设置主键，如果没有可用作主键的字段，可以设计一个业务无关的字段，比如xx_id。
有关MySQL InnoDB在索引中自动添加主键的问题
12-14
（一）原理 　　只要用户定义的索引字段中包含了主键中的字段，那么这个字段不会再被InnoDB自动加到索引中。但如果用户的索引字段中没有完全包含主键字段，InnoDB会把剩下的主键字段加到索引末尾。 　　（二）例子 　　例子一： CREATE TABLE t (   a char(32) not null primary key，   b char(32) not null，   KEY idx1 (a，b)，   KEY idx2 (b，a) ) Engine=InnoDB; 　　idx1和idx2两个索引内部大小完全一样，没有区别 　　例子二： CREA
InnoDB表主键的选择
crj2951的博客
07-15 236
在《InnoDB存储引擎》书中看到InnoDB表都是有主键的，如果没有显示定义主键，则InnoDB首先判断表中是否有非空的唯一索引，如果有，该列即为主键。如果有多个单一列唯一索引，则按照唯一索引顺序，排在前的为主键。 ...
临时表、内存表、自增主键疑难杂症
小诚信驿站
04-13 481
文章目录一、临时表1.0、区别1.1、临时表的特性1.2、临时表的应用（临时表名重复）1.3、主备中如何使用临时表（主库上不同的线程创建同名的临时表是没关系的，但是传到备库执行是怎么处理的呢？）1.4、为什么不能用 rename 修改临时表的改名。1.5、group by的使用二、内存表2.1、如果你维护的 MySQL 系统里有内存表，怎么避免内存表突然丢数据，然后导致主备同步停止的情况。2.2、将数据保存到 InnoDB 表用来持久化三、为什么自增主键不连续3.1、自增值保存在哪儿？3.2、自增值修改机制
【MySQL精通之路】InnoDB(9)-表和页压缩(1)-表压缩
Anakki的博客
05-24 1531
由于处理器和高速缓冲存储器的速度比磁盘存储设备更快，因此许多工作负载都是磁盘有关的。数据压缩能够以提高CPU利用率的小成本实现更小的数据库大小减少I/O和提高吞吐量。压缩对于读密集型应用程序尤其有价值，因为在具有足够RAM以将频繁使用的数据保存在内存中的系统上。使用创建的InnoDB表可以在磁盘上使用比配置的innodb_page_size值更小的页面大小。较小的页面需要较少的I/O来读取和写入磁盘，这对SSD设备尤其有价值。压缩页面大小是通过或参数指定的。不同的页面大小要求将表放在FPT表空间或。
InnoDB调优-分区表
张张张小胜的博客
07-12 2549
分区表是MySQL数据库在 5.1 版本时引入的新特性，主要用于数据库高可用性的管理
InnoDB引擎底层解析
choice~的博客
07-09 577
InnoDB的内存结构和磁盘存储结构图总结如下：其中的Insert/Change Buffer主要是用于对二级索引的写入优化，Undo空间则是undo日志一般放在系统表空间，但是通过参数配置后，也可以用独立表空间存放，所以用虚线表示。
【6. InnoDB 引擎底层解析】
努力学习
12-13 862
InnoDB 引擎底层解析 ​ MySQL 对于我们来说还是一个黑盒，我们只负责使用客户端发送请求并等待 服务器返回结果，表中的数据到底存到了哪里？以什么格式存放的？MySQL 是以 什么方式来访问的这些数据？这些问题我们统统不知道。要搞明白查询优化背后 的原理，就必须深入 MySQL 的底层去一探究竟，而且事务、锁等的原理也要求 我们必须深入底层。 InnoDB 记录存储结构和索引页结构 ​ InnoDB 是一个将表中的数据存储到磁盘上的存储引擎，所以即使关机后重 启我们的数据还是存在的。而真正处理数
mysql指定主键的第二种方式
weixin_43142543的博客
03-28 842
use school; create table if not exists info ( id int(4) zerofill primary key auto_increment, #指定主键的第二种方式 name varchar(10) not null, cardid int(18) not null unique key, hobby varchar(50)); #if not exists:表示检测要创建的表是否存在，如果不存在就继续创建 #int(4) zerofill:表示若数值不满四位数
MySQL面试题1---innodb的表必须指定主键吗
qq_43785075的博客
09-04 1013
对于Innodb存储引擎的表，尽量手工指定主键。（不是必须手工指定主键） 记录默认会按照一定的顺序保存，如果有明确定义的主键，则按照主键顺序保存。 如果没有主键，但是有唯一索引，那么就是按照唯一索引的顺序保存。 如果既没有主键又没有唯一索引，那么表中会自动生成一个内部列，按照这个列的顺序保存。 按照主键或者内部列进行的访问是最快的，所以Innodb表尽量自己指定主键。 当表中同时有几个列都是唯一的，都可以作为主键的时候，要选择最常作为访问条件的列作为主键，提高查询的效率。 Innodb表的普通索引都会保存主
优化 | InnoDB表一定要用自增列做主键
老叶茶馆
04-10 2107
明白InnoDB表一定要用自增列做主键的理由
为什么推荐InnoDB引擎使用自增主键？
奋斗、
07-29 9319
原文地址：http://www.ywnds.com/?p=8735 在使用InnoDB存储引擎时，如果没有特别的需要，请永远使用一个与业务无关的自增字段作为主键，除非高并发写入操作可能需要衡量自增主键，后面会讲。 经常看到有帖子或博客讨论主键选择问题，有人建议使用业务无关的自增主键，有人觉得没有必要，完全可以使用如学号或身份证号这种唯一字段作为主键。不论支持哪种论点，大多数论据都是业务
MySQL InnoDB数据表缺少主键会怎样
b_just的博客
07-03 2768
问题 MySQL数据表使用InnoDB作为存储引擎的时候，数据结构就是使用B+树，而数据本身存储在主键索引上，也就是通常所说的聚簇索引，也就是每个表都需要有个聚簇索引树，但是，在建表的时候却发现可以不用指定主键，那么MySQL对于没有指定主键的表示如何处理的呢？ InnoDB索引 对于InnoDB，可以简单地把所有数据视为索引，每一个索引都对应一个B+数，而主键对应的索引就是聚簇索引，表的所有数据都存储在聚簇索引上，而除了聚簇索引的普通索引存储的只是主键的引用，所以，查询的时候对于普通索引需要进行回表
数据库系列之InnoDB中的主键选择
牧羊人的方向
08-12 1391
InnoDB存储引擎中主键的正确使用对插入性能会有很大的提升，本文简要介绍了innodb中主键和聚簇索引，以及建议自增列作为主键的理由。
为什么InnoDB表必须有主键，并且推荐使用整型的自增主键？
LZHHuo的博客
02-02 8367
innoDB索引文件和数据文件是在一起的 frm：表结构；ibd：索引文件和数据文件 问：为什么InnoDB表必须有主键。并且推荐使用整型的自增主键： 1、如果设置了主键，那么InnoDB会选择主键作为聚集索引、如果没有显式定义主键，则InnoDB会选择第一个不包含有NULL值的唯一索引作为主键索引、如果也没有这样的唯一索引，则InnoDB会选择内置6字节长的ROWID作为隐含的聚集索引(RO...
为什么说InnoDB必须要有主键并且推荐使用自增整型主键呢？
a1_HelloWord的博客
02-16 4615
1.InnoDB存储引擎的数据结构必须需要一个主键才可以组织起来，如果用户使用InnoDB存储引擎建立表的时候，没有指定主键，则Mysql会自动的帮你找到一个合适的唯一索引作为主键，若找不到符合条件唯一索引条件的字段时，会生成类似于ROW_ID的虚拟列充当该InnoDB表的主键；2.整型的存储比字段类型要小，而且应为是InnoDB存储引擎使用的是B+Tree数据结构，在进行查询数据是需要对每个元素进行比较，而整型的对比效率是高于其他数据结构的，字符串等。...
InnoDB 层系统字典表 | 全方位认识 information_schema（IFS)
老叶茶馆
11-21 548
在《Server 层混杂信息字典表 | 全方位认识 information_schema》中，我们详细介绍了information_schema下的状态变量、系统变量、进程状态、字符集和...
主键ID和机台主键ID有啥区别
最新发布
08-07
<think>首先，用户的问题是：“我想理解主键ID和机台主键ID在数据库设计中的区别 请问数据库设计中主键ID和机台主键ID的区别”。我需要基于提供的引用内容来回答。 回顾引用内容： - 引用[1]：解释了主键和外键的区别，主键唯一标识表的记录。 - 引用[2]：讨论了分布式ID、系统ID、业务ID和主键之间的关系。强调业务ID可能变化，但主键ID不应改变；如果业务ID作为主键，当业务ID变化时会影响数据完整性。 - 引用[3]：详细说明了主键的创建和作用。包括使用自增ID作为主键的优点（如提高查询和插入性能），以及为什么避免使用业务相关字段作为主键（因为业务变化可能导致问题）。 - 引用[4]：提到MySQL主键设计，即使不指定主键，InnoDB也会创建一个隐藏的ROWID作为主键。 用户的问题是关于“主键ID”和“机台主键ID”的区别。在引用中，没有直接提到“机台主键ID”。这可能是一个特定术语，或许是“业务主键ID”的误写或特定上下文。在引用[3]中，提到了“业务主键”和“非业务主键”。 - “业务主键”：基于业务字段的主键，如图书编号。 - “非业务主键”（或代理主键）：自增ID，与业务无关。 用户说“机台主键ID”，可能指的是“机器主键ID”或类似，但更可能是一个打字错误或特定术语。在上下文中，我假设“机台主键ID”可能意指“业务主键ID”，因为“机台”可能是一个业务实体，如设备或机器的ID。 因此，我将“主键ID”解释为通用的数据库主键（通常是代理主键，如自增ID），而“机台主键ID”解释为业务主键（基于业务字段，如机器ID）。 基于引用内容，关键点如下： 1. **主键ID（代理主键）**：通常是自增整数，与业务无关。优点包括：索引效率高、插入性能好（因为连续值减少页分裂）、业务变化不影响主键。缺点：可能浪费空间，但引用强调其性能优势。 2. **业务主键（如机台主键ID）**：基于业务字段，如机器序列号或图书编号。优点：业务逻辑完整、安全性高。缺点：如果业务字段变化，主键需要更新，影响数据完整性；性能可能较差（如果字段不规则）。 从引用[3]："业务主键和非业务主键"部分： - 自增主键（非业务主键）：优点：索引所占空间小、增删改查效率高、业务变化不需要更新主键。缺点：无法转移数据库（意思是如果业务迁移，可能需要处理ID映射）。 - 业务主键：优点：保证业务逻辑的完整性、安全性高、可以转移数据库。缺点：效率低、业务变化需要修改主键。 在数据库设计中，推荐使用代理主键（自增ID）作为主键，而不是业务主键，以避免业务变化带来的问题。 现在，构建回答： - **结构清晰**：逐步解释。 - **使用中文**：回答必须用中文。 - **LaTeX格式**：行内数学表达式用$...$，独立公式用$$...$$。但在这个问题中，可能不需要数学公式，除非涉及计算。如果有变量或例子，可以适当添加。 - **添加引用标识**：在相关部分末尾自然地添加[^n]。 - **生成相关问题**：在回答后添加相关问题。 回答大纲： 1. **解释主键ID**：基于引用，主键ID是数据库表的主键，通常使用自增整数作为代理主键。 2. **解释机台主键ID**：假设是业务主键，基于特定业务字段如机器ID。 3. **区别**：对比两者的优缺点和应用场景。 4. **推荐**：在数据库设计中，优先使用代理主键（主键ID），而业务字段（如机台ID）可以作为唯一约束或索引。 最后，生成相关问题。</think>### 主键ID与机台主键ID在数据库设计中的区别 在数据库设计中，主键（Primary Key）是用于唯一标识表中每条记录的核心机制。用户提到的“主键ID”和“机台主键ID”分别代表了不同的设计理念和应用场景。我将基于数据库原理和参考引用内容，逐步解释它们的区别，帮助您清晰理解。 #### 1. **主键ID（代理主键或逻辑主键）** - **定义**：主键ID是数据库表中一个与业务逻辑无关的标识符，通常使用自增整数（如`INT`或`BIGINT`类型）实现。它唯一标识表中的每条记录，但不直接反映业务含义。 - **特点**： - **与业务无关**：它只负责技术层面的唯一性和索引效率，不依赖于任何业务规则。例如，在用户表中，主键ID可能是一个自增数字（如`id INT AUTO_INCREMENT PRIMARY KEY`），而实际业务字段（如用户名或邮箱）则作为普通列。 - **性能优势**：由于主键ID是连续递增的值，它在存储和查询时能显著提高效率。引用[^3]指出：“自增主键可以提高查询和插入的性能”，因为数据在B+树索引中按顺序存储，减少了页分裂和碎片化。数学上，这可以表示为索引操作的时间复杂度为$O(\log n)$，其中$n$是记录数。 - **稳定性**：主键ID一旦创建，就不应更改，确保了数据完整性。引用[^2]强调：“业务ID可能会因为业务的变化而变化，而主键ID一旦确定，就不应该发生改变。” - **适用场景**：适用于大多数表设计，尤其是当业务需求可能变化时。例如，在设备管理系统中，主键ID作为内部标识，而业务字段（如设备序列号）单独存储。 #### 2. **机台主键ID（业务主键）** - **定义**：机台主键ID是基于业务字段（如机器序列号、设备编号）的主键，它直接与业务逻辑相关。这里的“机台”可能指具体的设备或机器实体（如工厂中的生产线设备），因此机台主键ID通常是业务字段本身（如`machine_id VARCHAR(20) PRIMARY KEY`）。 - **特点**： - **业务相关性**：它直接映射到现实世界的业务标识，例如机台的唯一序列号。这有助于业务逻辑的完整性，但容易受业务规则变化影响。 - **潜在风险**：如果业务字段变化（如机台序列号因重新分配而更新），主键需要修改，可能导致数据不一致或外键冲突。引用[^2]警告：“如果把业务ID和主键ID设置为一样的，那么当业务ID需要改变时，就可能会影响到数据库的主键，从而影响到数据的完整性。” - **性能问题**：业务字段（如字符串类型）作为主键时，索引效率较低。因为非连续值（如随机字符串）会导致B+树索引频繁分裂，增加插入和查询开销。引用[^3]提到：“聚簇索引的主键值应尽量是连续增长的值，而不是随机值（不要用随机字符串或UUID）。” - **适用场景**：仅当业务标识绝对稳定且唯一时使用。例如，在小型系统中，机台ID本身是全局唯一且不变的，可以作为主键简化设计。 #### 3. **关键区别对比** 下表总结了主键ID与机台主键ID的核心差异： | 特性 | 主键ID（代理主键） | 机台主键ID（业务主键） | |--------------|--------------------------------------|--------------------------------------| | **本质** | 技术标识，与业务无关（如自增整数） | 业务标识，直接映射业务实体（如机器序列号） | | **稳定性** | 高，一旦创建不改变 | 低，业务变化可能导致主键更新 | | **性能** | 高，连续值优化索引效率（$O(\log n)$） | 较低，不规则值增加页分裂风险 | | **数据完整性** | 强，避免业务变化影响 | 弱，业务更新可能破坏引用关系 | | **适用性** | 通用，推荐用于大多数表设计 | 有限，仅当业务ID绝对稳定时使用 | - **设计建议**：在数据库设计中，优先使用主键ID（代理主键）作为表的主键，因为它提供更好的性能和稳定性。机台ID等业务字段可以作为唯一约束（如`UNIQUE`索引）或普通列，而不是主键。引用[^3]支持这一观点：“还是设置一个与业务无关的自增ID作为主键，然后增加一个图书编号的唯一性约束。”这确保了业务逻辑的灵活性，同时维护技术效率[^3]。 #### 4. **实际示例** 假设设计一个“机台管理表”： - **使用主键ID（推荐）**： ```sql CREATE TABLE machines ( id INT AUTO_INCREMENT PRIMARY KEY, -- 代理主键，与业务无关 machine_id VARCHAR(20) UNIQUE, -- 机台业务ID，作为唯一约束 name VARCHAR(50), location VARCHAR(100) ); ``` 这里，`id`是主键ID，确保高效索引；`machine_id`是机台业务ID，用于业务查询，但不作为主键。 - **使用机台主键ID（不推荐，除非业务稳定）**： ```sql CREATE TABLE machines ( machine_id VARCHAR(20) PRIMARY KEY, -- 业务主键，风险较高 name VARCHAR(50), location VARCHAR(100) ); ``` 如果`machine_id`变化（如重新编号），需要更新所有相关外键，易出错。 总之，主键ID侧重于数据库内部效率和稳定性，而机台主键ID是业务导向的标识。在设计中，分离两者能平衡性能和业务需求[^1][^2][^3]。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值