MySQL 制約ナレッジ ポイントの分析例

1. 制約の概要

1.1 データの整合性を確保するために制約が必要な理由

データ整合性とは、データの正確さ（Accuracy）と信頼性（Reliability）。これは、データベース内の意味規則に従わないデータを回避し、誤った情報の入出力による無効な操作やエラー メッセージを防ぐために提案されています。

データの整合性を確保するために、SQL 規範が制限するのは、 テーブルデータには追加の条件制限が適用されます 。次の 4 つの側面を考慮してください:

エンティティの整合性 ) : たとえば、同じテーブル内に、同一で区別できない 2 つのレコードが存在することはできません。

ドメインの整合性 ) : 例: 年齢層 0-120 、性別の範囲 」 男 / 女性 ''

参照整合性 ) : 例: 従業員がいる部門。この部門は部門テーブルで見つかる必要があります。

ユーザー定義の整合性 (ユーザー - 定義された誠実さ ) : 例: ユーザー名は一意である、パスワードを空にすることはできない、など。この部門のマネージャーの給与は、この部門の従業員の平均給与の 5% を超えてはなりません。 回。

1.2 制約とは - テーブル内のフィールドの制限

制約はテーブル レベルでの必須要件です。

許容可能 テーブルの作成時に制約を指定します ( テーブルの作成 ​ 声明） 、または テーブル作成後に渡される 他の机 ステートメントは

制約を指定しています 。

1.3 制約の分類

制約データ列の制限に従って、 制約は次のように分類できます。

単一列制約 : 各制約は 1 つの列のみを制約します

複数の列の制約 : 各制約は、制約のスコープに従って、複数のデータ列を制約できます。 、制約は次のように分割できます。

列レベルの制約 : 1 つの列にのみ適用でき、その後に列定義が続きます

テーブル レベルの制約 : 複数の列に適用できます。列と一緒にではなく、個別に定義できます

#列レベルの制約: テーブルレベルの制約:

	位置	サポートされる制約タイプ	制約名を指定できますか?
#列の後	構文はサポートされていますが、外部キーは効果がありません	##不可能です
すべての列で	デフォルトと空以外はサポートされませんが、その他はサポートされますサポートされています	はい (主キーは影響しません)	制約の役割による 1. NOT NULL 非 null 制約。特定のフィールドを空にできないことを規定します。 2. UNIQUE 一意制約。これは、特定のフィールドを空にすることができないことを規定します。テーブル全体で特定のフィールドを空にすることはできません 一意です 3. PRIMARY KEY 主キー (NULL ではなく一意) 制約 4. FOREIGN KEY 外部キー制約 5. CHECK チェック制約 6. DEFAULT デフォルト値制約 ##注: MySQL はチェック制約をサポートしていませんが、何の影響もなくチェック制約を使用できます テーブルの既存の制約の表示: # information_schema データベース名 (システム ライブラリ) # table_constraints テーブル名 (各テーブルの制約を特別に保存します) SELECT * FROM information_schema.table_constraints WHERE table_name = 'テーブル名'; 2. 非 null 制約 (NOT NULL) 2.1 関数 特定のフィールドを制限する/ 特定の列の値を空にすることはできません 2.2 キーワード NOT NULL 2.3 機能 1. デフォルト、すべてのタイプ 値INT、FLOAT、その他のデータ型を含む NULL も可能です 2. 非 null 制約は、テーブル オブジェクトの列にのみ指定できます。特定の列のみを独立して非 null に制限でき、非 null を組み合わせることはできません (列レベルの制約のみ、テーブルレベルの制約はありません) 3. テーブルには、空でないようにそれぞれ制限される多くの列を含めることができます。 4. 空の文字列 '' は NULL と等しくなく、0 は NULL と等しくありません 2.4 空ではない制約を追加します 2.4.1 CREATE で TABLE の場合に非 null 制約を追加します。 構文形式: CREATE TABLE 表名称( 字段名 数据类型, 字段名 数据类型 NOT NULL, 字段名 数据类型 NOT NULL ); 例: ##2.4.2 ALTER TABLE 時に非 null 制約を追加する 構文形式: alter table 表名称 modify 字段名 数据类型 not null ; 例: 2.5 非 null 制約の削除 構文形式: 1.alter table 表名称 modify 字段名 数据类型 NULL; #去掉not null，相当于修改某个非注解字段，该字段允 许为空 2.alter table 表名称 modify 字段名 数据类型; #去掉not null，相当于修改某个非注解字段，该字段允许为空 例: 3. 一意制約 (UNIQUE または UNIQUE KEY) 3.1 関数 # は、特定のフィールドを制限するために使用されます。 列の値を繰り返すことはできません。 3.2 キーワード UNIQUE 3.3 機能 1. 同じテーブルに複数の一意制約を設定できます。 2. 一意制約とは、特定の列の値が一意であること、または複数の列の組み合わせの値が一意であることです。 3. 一意制約により、列の値を空にすることができます。また、複数の NULL 値が許可されます。 4. 一意制約を作成するときに、一意制約に名前を付けないと、デフォルトで列名と同じになります。 5.MySQL は、デフォルトで一意制約カラムに一意のインデックスを作成します。 3.4 一意制約の追加 3.4.1 CREATE TABLE 時に一意制約を追加 構文形式: 1. 列レベルの制約 create table 表名称( 字段名 数据类型, 字段名 数据类型 unique, 字段名 数据类型 unique key, 字段名 数据类型 ); 2. テーブルレベルの制約 create table 表名称( 字段名 数据类型, 字段名 数据类型, 字段名 数据类型, [constraint 约束名] unique key(字段名) ); 例: 3.4.2 在ALTER TABLE 时添加唯一约束 语法格式： 1. alter table 表名称 add [constraint 约束名] unique key(字段列表); 2. alter table 表名称 modify 字段名 字段类型 unique; 注：字段列表中如果是一个字段，表示该列的值唯一。当存在两个或更多字段时，复合唯一指的是这些字段的组合是唯一的 举例： 3.4.3 添加复合唯一性约束 语法格式： 1.在  create table 时添加复合唯一约束 create table 表名称( 字段名 数据类型, 字段名 数据类型, 字段名 数据类型, [constraint 约束名] unique key(字段列表) ); 2.  在 alter table 时添加复合唯一约束 alter table 表名称 add [constraint 约束名] unique key(字段列表); 字段列表中写的是多个字段名，多个字段名用逗号分隔，表示那么是复合唯一，即多 个字段的组合是唯一的 举例： 3.5 删除唯一约束 1.添加唯一性约束的列上也会自动创建唯一索引。 2.删除唯一约束只能通过删除唯一索引的方式删除。 3.删除时需要指定唯一索引名，唯一索引名就和唯一约束名一样。 4.如果创建唯一约束时未指定名称，如果是单列，就默认和列名相同； 如果是组合列，那么默认和() 中排在第一个的列名相同。 也可以是自定义唯一性约束名。 语法格式： ALTER TABLE USER DROP INDEX 约束名; 查看表从索引： show index from 表名称 ; 举例： 4. PRIMARY KEY 约束（主键约束） 4.1 作用 用来唯一标识表中的一行记录。 4.2 关键字 primary key 4.3 特点 主键约束相当于唯一约束+非空约束的组合，主键约束列不允许重复，也不允许出现空值。 1. 一个表最多只能有一个主键约束，建立主键约束可以在列级别创建，也可以在表级别上创建。 2. 主键约束对应着表中的一列或者多列（复合主键） 3. 如果是多列组合的复合主键约束，那么这些列都不允许为空值，并且组合的值不允许重复。 4. MySQL的主键名总是    PRIMARY    ，就算自己命名了主键约束名也没用。 5. 当创建主键约束时，系统默认会在所在的列或列组合上建立对应的    主键索引    （能够根据主键查询的，就根据主键查询，效率更高）。如果删除主键约束了，主键约束对应的索引就自动删除了。 6. 需要注意的一点是，不要修改主键字段的值。由于主键是数据记录的唯一标识，若更改了主键值，有可能会损害数据完整性 4.4 添加主键约束 4.4.1 在CREATE TABLE 时添加主键约束 语法格式： 1.列级模式 create table 表名称( 字段名 数据类型 primary key, #列级模式 字段名 数据类型, 字段名 数据类型 ); 2.表级模式（注：    MySQL的主键名总是    PRIMARY    ，就算自定义了主键约束名也没用    ） create table 表名称( 字段名 数据类型, 字段名 数据类型, 字段名 数据类型, [constraint 约束名] primary key(字段名) #表级模式 ); 举例： 4.4.2 在CREATE TABLE 时添加复合主键约束 多列组合的复合主键约束，那么这些列都不允许为空值，并且组合的值不允许重复。 语法格式： create table 表名称( 字段名 数据类型, 字段名 数据类型, 字段名 数据类型, primary key(字段名1,字段名2) ); 字段1和字段2的组合是唯一的，也可以有更多个字段 举例： 4.4.3  在 ALTER TABLE 时添加（复合）主键约束 字段列表可以是一个字段，也可以是多个字段，如果是多个字段的话，是复合主键 语法格式： 1. ALTER TABLE 表名称 MODIFY 字段名 数据类型 PRIMARY KEY; 2. ALTER TABLE 表名称 ADD PRIMARY KEY(字段列表); 举例： 4.5 删除主键约束 删除主键约束，不需要指定主键名，因为一个表只有一个主键，     删除主键约束后，非空还存在。     （但在实际开发中，不会去删除表中的主键约束） 语法格式： alter table 表名称 drop primary key; 举例： 5. 自增列：AUTO_INCREMENT 5.1 作用 某个字段的值自增 5.2 关键字 auto_increment 5.3 特点和要求 1. 一个表最多只能有一个自增长列 2. 当需要产生唯一标识符或顺序值时，可设置自增长 3. 自增长列约束的列必须是键列（主键列，唯一键列） 4. 自增约束的列的数据类型必须是整数类型 5. 如果自增列指定了 0 和 null，会在当前最大值的基础上自增；如果自增列手动指定了具体值，直接 赋值为具体值 5.4 添加自增约束 5.4.1 在CREATE TABLE 时添加自增约束 语法格式： create table 表名称( 字段名 数据类型 primary key auto_increment, 字段名 数据类型 , 字段名 数据类型 , 字段名 数据类型 ); create table 表名称( 字段名 数据类型 , 字段名 数据类型 unique key auto_increment, 字段名 数据类型 ); 举例： 非法创建： 正确创建方式： 插入数据: 特殊情况(不推荐此写法)： 5.4.2 在 ALTER TABLE 时添加自增约束 语法格式： alter table 表名称 modify 字段名 数据类型 auto_increment; 举例： 5.5 删除自增约束 语法格式： alter table 表名称 modify 字段名 数据类型; 举例： 5.6 MySQL 8.0新特性—自增变量的持久化 在MySQL 8.0    之前，自增主键    AUTO_INCREMENT    的值如果大于    max(primary key)+1    ，在    MySQL    重启后，会重 置AUTO_INCREMENT=max(primary key)+1    ，这种现象在某些情况下会导致业务主键冲突或者其他难以发 现的问题。 下面通过案例来对比不同的版本中自增变量是否持久化。 案例： 对于MySQL5.7版本： 然后重启MySQL57服务器：（以管理员的身份运行） 从结果可以看出，新插入的0    值分配的是    4    ，按照重启前的操作逻辑，此处应该分配    6    。出现上述结果的主要原因是自增主键没有持久化。 在MySQL 5.7系统中，对于自增主键的分配规则，是由    InnoDB    数据字典内部一个    计数器    来决定的，而该计数器只在    内存中维护    ，并不会持久化到磁盘中。当数据库重启时，该计数器会被初始化。 对于MySQL8.0版本： 然后重启MySQL80服务器：（以管理员的身份运行） 从结果可以看出，自增变量已经持久化了。 MySQL 8.0将自增主键的计数器持久化到    重做日志    中。每次计数器发生改变，都会将其写入重做日志中。如果数据库重启，InnoDB    会根据重做日志中的信息来初始化计数器的内存值。 6. FOREIGN KEY 约束 6.1 作用 限定某个表的某个字段的引用完整性。 比如：员工表的员工所在部门的选择，必须在部门表能找到对应的部分。 6.2 关键字 FOREIGN KEY 6.3 主表和从表/父表和子表 主表（父表）：被引用的表，被参考的表 从表（子表）：引用别人的表，参考别人的表 例如：员工表的员工所在部门这个字段的值要参考部门表：部门表是主表，员工表是从表。 例如：学生表、课程表、选课表：选课表的学生和课程要分别参考学生表和课程表，学生表和课程表是主表，选课表是从表。 6.4 特点 1. 从表的外键列，     必须引用/参考主表的主键或唯一约束的列 因为被依赖/被参考的值必须是唯一的 2. 在创建外键约束时，如果不给外键约束命名，默认名不是列名，而是自动产生一个外键名（例如 student_ibfk_1;），也可以指定外键约束名。 3. 创建(CREATE)表时就指定外键约束的话，先创建主表，再创建从表 4. 删表时，先删从表（或先删除外键约束），再删除主表 5. 当主表的记录被从表参照时，主表的记录将不允许删除，如果要删除数据，需要先删除从表中依赖 该记录的数据，然后才可以删除主表的数据 6. 在“从表”中指定外键约束，并且一个表可以建立多个外键约束 尽管外键列和主表的被引用列的名称可以不同，但它们的数据类型必须相同，且具有相同的逻辑含义。如果类型不一样，创建子表时，就会出现错误。 8.     当创建外键约束时，系统默认会在所在的列上建立对应的普通索引。但是索引名是外键的约束名。（根据外键查询效率很高） 9. 删除外键约束后，必须 手动 删除对应的索引 6.5 添加外键约束 6.5.1 在 create table 时添加外键约束 语法格式： create table 主表名称( 字段1 数据类型 primary key, 字段2 数据类型 ); create table 从表名称( 字段1 数据类型 primary key, 字段2 数据类型, [CONSTRAINT <外键约束名称>] FOREIGN KEY（从表的某个字段) references 主表名(被参考字段) [on update xx][on delete xx]; ); -- FOREIGN KEY: 在表级指定子表中的列 -- REFERENCES: 标示在父表中的列 (从表的某个字段)的数据类型必须与主表名(被参考字段)的数据类型一致，逻辑意义也一样 (从表的某个字段)的字段名可以与主表名(被参考字段)的字段名一样，也可以不一样 举例： 正确的创建方式： 错误的创建方式： 添加数据： 修改数据： 删除数据： 6.5.2 在ALTER TABLE 时添加外键约束 通常情况下，表与表之间的关联是预先设计的，因此在创建表时会定义好外键约束。不过，如果需要修改表的设计（比如添加新的字段，增加新的关联关系），但没有预先定义外键约束，那么，就要用修改表的方式来补充定义。 语法格式： ALTER TABLE 从表名 ADD [CONSTRAINT 约束名] FOREIGN KEY (从表的字段) REFERENCES 主表名(被引用 字段) [on update xx][on delete xx]; 6.7 约束等级（级联） 1.  Cascade    方式    ：在父表上    update/delete    记录时，同步    update/delete    掉子表的匹配记录 2. Set null方式    ：在父表上    update/delete    记录时，将子表上匹配记录的列设为    null    ，但是要注意子 表的外键列不能为not null 3. No action方式    ：如果子表中有匹配的记录，则不允许对父表对应候选键进行    update/delete    操作 4 .Restrict方式 （默认）    ：同no action    ， 都是立即检查外键约束 5. Set default方式    （在可视化工具    SQLyog    中可能显示空白）：父表有变更时，子表将外键列设置成一个默认的值，但Innodb    不能识别 如果没有指定等级，就相当于Restrict方式。 对于外键约束，最好是采用: ON UPDATE CASCADE ON DELETE RESTRICT 的方式。 举例：（以 on update cascade on delete set null        为例） 1.创建表 2.添加数据 3.修改数据 4.删除数据 6.8 删除外键约束 流程如下： (1)第一步先查看约束名和删除外键约束 #查看某个表的约束名 SELECT * FROM information_schema.table_constraints WHERE table_name = &#39;表名称&#39;; ALTER TABLE 从表名 DROP FOREIGN KEY 外键约束名; （     2）第二步查看索引名和删除索引。（注意，只能手动删除） #查看某个表的索引名 SHOW INDEX FROM 表名称; ALTER TABLE 从表名 DROP INDEX 索引名; 注意： 删除外键约束后，必须 手动 删除对应的索引 举例： 6.9 开发场景 问题     1     ：如果两个表之间有关系（一对一、一对多），比如：员工表和部门表（一对多），它们之间是否     一定要建外键约束？ 答：不是的 问题     2     ：建和不建外键约束有什么区别？ 答：建外键约束，你的操作（创建表、删除表、添加、修改、删除）会受到限制，从语法层面受到限制。 例如：在员工表中不可能添加一个员工信息，它的部门的值在部门表中找不到。 不建外键约束，你的操作（创建表、删除表、添加、修改、删除）不受限制，要保证数据的     引用完整 性     ，只能依     靠程序员的自觉     ，或者是     在     Java     程序中进行限定     。例如：在员工表中，可以添加一个员工的信息，它的部门指定为一个完全不存在的部门。 问题     3     ：那么建和不建外键约束和查询有没有关系？ 答：没有 拓展： 在 MySQL     里，外键约束是有成本的，需要消耗系统资源。对于大并发的     SQL     操作，有可能会不适 合。比如大型网站的中央数据库，可能会     因为外键约束的系统开销而变得非常慢     。所以，     MySQL     允 许你不使用系统自带的外键约束，在     应用层面     完成检查数据一致性的逻辑。也就是说，即使你不 用外键约束，也要想办法通过应用层面的附加逻辑，来实现外键约束的功能，确保数据的一致性。 6.10 阿里开发规范 【 强制 】不得使用外键与级联，一切外键概念必须在应用层解决。 说明：（概念解释）学生表中的 student_id 是主键，那么成绩表中的      student_id      则为外键。如果更新学 生表中的 student_id      ，同时触发成绩表中的      student_id      更新，即为级联更新。外键与级联更新适用于      单机低并发      ，不适合      分布式      、      高并发集群      ；级联更新是强阻塞，存在数据库      更新风暴      的风险；外键影响 数据库的      插入速度      。 7. CHECK 约束 7.1 作用 检查某个字段的值是否符号xx     要求，一般指的是值的范围 7.2 关键字 CHECK 7.3 说明：MySQL 5.7 不支持 MySQL5.7 可以使用     check约束，但check约束对数据验证没有任何作用。添加数据时，没有任何错误或警告。 MySQL 8.0中可以使用check约束了     。 7.4 添加CHECK 约束 8. DEFAULT约束 8.1 作用 给某个字段/    某列指定默认值，一旦设置默认值，在插入数据时，如果此字段没有显式赋值，则赋值为默认值。 8.2 关键字 DEFAULT 8.3 添加默认值约束 8.3.1 在 CREATE TABLE时添加默认值约束 语法格式： 方式1： create table 表名称( 字段名 数据类型 primary key, 字段名 数据类型 unique key not null, 字段名 数据类型 unique key, 字段名 数据类型 not null default 默认值, ); 方式2： create table 表名称( 字段名 数据类型 default 默认值 , 字段名 数据类型 not null default 默认值, 字段名 数据类型 not null default 默认值, primary key(字段名), unique key(字段名) ); 说明：默认值约束一般不在唯一键和主键列上加 举例： 8.3.2 在 ALTER TABLE时添加默认值约束 语法格式： alter table 表名称 modify 字段名 数据类型 default 默认值; alter table 表名称 modify 字段名 数据类型 default 默认值 not null ; 注： 1.如果这个字段原来有非空约束，你还保留非空约束，那么在加默认值约束时，还得保留非空约束，否则非空约束就被删除了。 2.同理，在给某个字段加非空约束也一样，如果这个字段原来有默认值约束，你想保留，也要在modify语句中保留默认值约束，否则就删除了。 举例： 8.4 删除默认值约束 语法格式： 1.删除默认值约束，也不保留非空约束 alter table 表名称 modify 字段名 数据类型 ; 2.删除默认值约束，保留非空约束 alter table 表名称 modify 字段名 数据类型 not null ; 举例： 9. 面试 面试   1   、为什么建表时，加   not null default ''   或   default 0 答：不想让表中出现null   值。 面试   2   、为什么不想要   null   的值 ＃＃＃答え： (1) 比較するのは難しい。 ヌル は特別な値です。比較には特別な値のみを使用できます 無効である そして nullではありません 比べる。演算子が見つかった場合、通常は null を返します 。 (2) 効率は高くありません。インデックス作成パフォーマンスの向上への影響。したがって、テーブルを作成するときは、not null デフォルト '' を使用することがよくあります。 または デフォルト 0 インタビュー 3 、持ってくる 自動増加 制約のフィールド値は次のとおりです。 1 始まりましたか？ MySQL 内 では、AUTO_INCREMENT のデフォルトの初期値は 1 です。新しいレコードが追加されるたびに、フィールド値は自動的に 1 ずつ増加します。 。自動インクリメント属性 (AUTO_INCREMENT) を設定する場合、最初に挿入されたレコードの自動インクリメント フィールドの値を指定して、新しく挿入されたレコードの自動インクリメント フィールドの値が初期値から増加するようにすることもできます。テーブルに最初のレコードを挿入する場合など、同時にidを指定します 値は 5 、その後に挿入されたレコードは ID 値は次から変わります 6 上向きに増加し始めます。主キー制約を追加する場合、多くの場合、属性を自動的に追加するようにフィールドを設定する必要があります。 ＃＃＃＃＃＃インタビュー 4 すべてのテーブルがストレージ エンジンを任意に選択できるわけではありませんか? 外部キー制約 ( FOREIGN KEY) はエンジン間で使用できません。 (マスター テーブルとスレーブ テーブルで使用されるエンジンは同じである必要があります) MySQL は複数のストレージ エンジンをサポートしています。各テーブルは異なるストレージ エンジンを指定できます。外部キー制約を使用して、データ 参照整合性の観点から、テーブル間で外部キーを関連付ける必要があるが、異なるストレージ エンジンが指定されている場合、これらのテーブル間に外部キー制約を作成することはできません。したがって、ストレージ エンジンの選択は完全に任意というわけではありません。

以上がMySQL 制約ナレッジ ポイントの分析例の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。