記事のディレクトリ
- 3つのデータベースパラダイム？
- 権限に関連するMySQLテーブルとは何ですか？
- mysqlにはどのようなデータ型がありますか？
- スーパーキー、候補キー、主キー、および外部キーとは何ですか？
- SQLステートメントの主なタイプは何ですか？
- SQLフィールドにはどのような制約があるのか教えてください。
- SQL関連のクエリについて話しますか？
- SQLサブクエリについて話しますか？
- mysqlに存在するとの違いは何ですか？
- varcharとcharの違いは？選び方は？
- mysqlのint（10）、char（10）、varchar（10）の違いは何ですか？
- MySQLの削除、削除、切り捨ての違いは何ですか？
- MySQL binlogにはいくつの入力フォーマットがありますか？違いは何ですか？
- MySQLにはどのような種類のログがありますか？
- バイナリログとREDOログの違いは何ですか？
3つのデータベースパラダイム？
転載：https：//zhuanlan.zhihu.com/p/72197799
リレーショナルデータベースを設計する場合、合理的なリレーショナルデータベースは、さまざまな仕様や要件に準拠するように設計されます。これらのさまざまな仕様は、さまざまなパラダイムと呼ばれます。さまざまなパラダイムが標準以下で提示されます。パラダイムが高いほど、データベースの冗長性は低くなります。しかし、冗長性を減らすためにパラダイムを追求すると、データの読み取りと書き込みの効率が低下する場合があります。現時点では、パラダイムを逆転させ、時間のスペースを使用する必要があります。現在、リレーショナルデータベースには6つのパラダイムがあります。第1正規形（1NF）、第2正規形（2NF）、第3正規形（3NF）、バスコード正規形（BCNF）、第4正規形（4NF）、第5正規形（ 5NF、完全なパラダイムとしても知られています）。最小要件を満たすパラダイムは、第一正規形（1NF）です。第1正規形に基づいて、より多くの仕様をさらに満たすものを第2正規形（2NF）と呼びます。一般的に、データベースは第3正規形（3NF）を満たす必要があるだけです。したがって、ここでは3つのパラダイムに関連する知識のみを記録します。
1.第一正規形：各列の原子性を確保するため
また、と言うことができる、各列を分割することはできません。たとえば、次の表を見てください。
住所列は、州、都市、住所に分割できます。分解は次のとおりです
。2。最初の正規形に基づいて、非主キー列は完全に主キーに依存し、の一部にすることはできません。主キー。
たとえば、次の表を見てください。
上記の表は最初のパラダイムを満たしています。つまり、各フィールドを細分化することはできませんが、クレジットは非主キーコースに依存しているため、2番目のパラダイムが満たされないため、データが発生します。冗長性、例外の更新、例外の挿入、および例外の削除。変更後：
3。2番目のパラダイムに基づいて、非主キー列は主キーのみに依存し、他の非主キーには依存しません。
第3正規形は、第2正規形に関連しています。第3正規形は、第3正規形の定義によって記述されます。データベーステーブルの非キーフィールドに候補キーフィールドの転送関数依存性がない場合、これは、第3正規形、いわゆる転送関数従属性に準拠します。つまり、「A–> B–> C」の決定関係がある場合、Cの転送関数はAに依存します。つまり、テーブル内のフィールドと主キーは直接対応しており、他の中間フィールドに依存していません。率直に言って、フィールドの値を決定するのは主キーです。
たとえば、次の表を見てください。
3番目のパラダイムは2番目のパラダイムと少し似ています。このデータベーステーブル構造から、「name」、「age」、「college」と主キー「student ID」は直接関連しているが、「collegelocation」であることがわかります。および「大学の電話番号」「ただし、主キー「学生番号」とは直接関係ありません。「大学の電話」は「大学」と直接関係します。テーブル構造がこのように設計されている場合も、同じデータの冗長性が発生します。 、例外を更新し、2番目の通常の形式である異常のように挿入し、異常な問題を削除します。変更後：
権限に関連するMySQLテーブルとは何ですか？
MySQLサーバーは、パーミッションテーブルを介してデータベースへのユーザーのアクセスを制御します。パーミッションテーブルはmysqlデータベースに保存され、mysql_install_dbスクリプトによって初期化されます。これらの権限テーブルは、user、db、table_priv、columns_priv、およびhostです。
以下に、これらのテーブルの構造と内容について説明します。
- ユーザー権限テーブル：サーバーへの接続が許可されているユーザーアカウント情報を記録します。内部の権限はグローバルです。
- dbパーミッションテーブル：各データベースの各アカウントの操作パーミッションを記録します。
- table_privパーミッションテーブル：データテーブルレベルで操作パーミッションを記録します。
- columns_privパーミッションテーブル：レコードデータの列レベルの操作パーミッション。
- ホストパーミッションテーブル：dbパーミッションテーブルと連携して、特定のホストでのデータベースレベルの操作パーミッションをより詳細に制御します。この許可テーブルは、GRANTおよびREVOKEステートメントの影響を受けません。
mysqlにはどのようなデータ型がありますか？
| 分類 | タイプ名 | 説明 |
|---|---|---|
| 整数型 | tinyInt | 非常に小さい整数（8ビットバイナリ） |
| smallint | 小整数（16ビットバイナリ） | |
| ミディアムイント | 中型整数（24ビットバイナリ） | |
| int（整数） | 通常サイズの整数（32ビットバイナリ） | |
| 10進型 | 浮く | 単精度浮動小数点 |
| ダブル | 倍精度浮動小数点数 | |
| 10進数（m、d） | 厳密に圧縮された固定小数点数 | |
| 日付タイプ | 年 | YYYY 1901〜2155 |
| 時間 | HH：MM：SS -838：59：59〜838：59：59 | |
| 日付 | YYYY-MM-DD 1000-01-01〜9999-12-3 | |
| 日付時刻 | YYYY-MM-DD HH：MM：SS 1000-01-01 00：00：00〜9999-12-31 23:59:59 | |
| タイムスタンプ | YYYY-MM-DD HH：MM：SS 1970 01 01 00:00:01 UTC〜2038-01-19 03：14：07UTC | |
| テキスト、バイナリタイプ | チャーム） | Mは0から255までの整数です |
| VARCHAR（M） | Mは0〜65535の整数です | |
| TINYBLOB | 許容長0〜255バイト | |
| BLOB | 許容長0〜65535バイト | |
| MEDIUMBLOB | 許容長0〜167772150バイト | |
| LONGBLOB | 許容長0〜4294967295バイト | |
| TINYTEXT | 許容長0〜255バイト | |
| テキスト | 許容長0〜65535バイト | |
| MEDIUMTEXT | 許容長0〜167772150バイト | |
| LONGTEXT | 許容長0〜4294967295バイト | |
| VARBINARY（M） | 0〜Mバイトの長さの可変長バイト文字列を許可します | |
| BINARY（M） | 0〜Mバイトの長さの固定長バイト文字列を許可します |
スーパーキー、候補キー、主キー、および外部キーとは何ですか？
超键(super key): 在关系中能唯一标识元组的属性集称为关系模式的超键
候选键(candidate key): 不含有多余属性的超键称为候选键。也就是在候选键中，若再删除属性，就不是超键了！
主键(primary key): 用户选作元组标识的一个候选键程序主键
外键(foreign key)：如果关系模式R中属性K是其它模式的主键，那么k在模式R中称为外键。
例えば：
2つの表：
学生情報（学生ID番号、性別、年齢、身長と体重、寮番号）
寮情報（寮の建物番号）
- スーパーキー：「学生ID」または「ID番号」の2つの属性を含むセットがスーパーキーと呼ばれる限り、R1（学生IDの性別）、R2（ID番号の高さ）、R3（学生IDID番号） ）など。スーパーキーと呼ぶこともできます！
- 候補キー:(学生ID）や（ID番号）などの冗長な属性を含まないスーパーキーが候補キーであり、R1中学校IDの属性はタプルを一意に識別でき、性別属性があるかどうかは影響しません。タプルを一意に識別するかどうか！
- 主キー：多くの候補キーからユーザーが選択したキーが主キーです。たとえば、学生IDを主キーにする必要がある場合、ID番号を主キーにすることはできません。
- 寮番号は学生情報表の外部キーです
SQLステートメントの主なタイプは何ですか？
-
データ定義言語DDL（データ定義言語）
主要为CREATE，DROP，ALTER等操作 即对逻辑结构等有操作的，其中包括表结构，视图和索引。 -
データクエリ言語DQL（データクエリ言語）SELECT
这个较为好理解 即查询操作，以select关键字。各种简单查询，连接查询等 都属于DQL。 -
データ操作言語（DML）
主要为INSERT，UPDATE，DELETE等操作 即对数据进行操作的，对应上面所说的查询操作 DQL与DML共同构建了多数初级程序员常用的增删改查操作。而查询是较为特殊的一种 被划分到DQL中。 -
データ制御機能DCL（データ制御言語）
主要为GRANT，REVOKE，COMMIT，ROLLBACK等操作 即对数据库安全性完整性等有操作的，可以简单的理解为权限控制等。
SQLフィールドにはどのような制約があるのか教えてください。
- NOT NULL：フィールドの制御に使用されるコンテンツは空（NULL）であってはなりません。
- 一意：制御フィールドの内容を繰り返すことはできません。テーブルでは、複数の一意の制約を使用できます。
- 主キー：これは、制御フィールドの内容を繰り返すことができない場合にも使用されますが、テーブル内で1つしか許可されません。
- FOREIGN KEY：テーブル間の接続を破壊するアクションを防ぐために使用されます。また、それが指すテーブル内の値の1つである必要があるため、不正なデータが外部キー列に挿入されるのを防ぐこともできます。
- チェック：フィールドの値の範囲を制御するために使用されます。
SQL関連のクエリについて話しますか？
- 内部結合（INNER JOIN）
内连接分为三类: 1. 等值连接：ON A.id=B.id 2. 不等值连接：ON A.id > B.id 3. 自连接：SELECT * FROM A T1 INNER JOIN A T2 ON T1.id=T2.pid - 外部結合（LEFT JOIN / RIGHT JOIN）
左外连接：LEFT OUTER JOIN, 以左表为主，先查询出左表，按照ON后的关联条件匹配右表，没有匹配到的用NULL填充，可以简写成LEFT JOIN 右外连接：RIGHT OUTER JOIN, 以右表为主，先查询出右表，按照ON后的关联条件匹配左表，没有匹配到的用NULL填充，可以简写成RIGHT JOIN - 共同クエリ（UNIONおよびUNION ALL）
SELECT * FROM A UNION SELECT * FROM B UNION ... 1. 就是把多个结果集集中在一起，UNION前的结果为基准，需要注意的是联合查询的列数要相等，相同的记录行会合并 2. 如果使用UNION ALL，不会合并重复的记录行 3. 效率 UNION 高于 UNION ALL - 完全結合
MySQL不支持全连接可以使用LEFT JOIN 和UNION和RIGHT JOIN联合使用 SELECT * FROM A LEFT JOIN B ON A.id=B.id UNIONSELECT * FROM A RIGHT JOIN B ON A.id=B.id - クロス結合（CROSS JOIN）
SQLサブクエリについて話しますか？
条件：1つのSQLステートメントのクエリ結果が別のクエリステートメントの条件またはクエリ結果として使用されます。
ネスト：ネストでは複数のSQLステートメントが使用され、内部のSQLクエリステートメントはサブクエリと呼ばれます。
3つの状況：
子查询是单行单列的情况：结果集是一个值，父查询使用：=、 <、 > 等运算符
// 查询工资最高的员工是谁？
select * from employee where salary=(select max(salary) from employee);
子查询是多行单列的情况：结果集类似于一个数组，父查询使用：in 运算符
// 查询工资最高的员工是谁？
select * from employee where salary=(select max(salary) from employee);
子查询是多行多列的情况：结果集类似于一张虚拟表，不能用于where条件，用于select子句中做为子表
// 1) 查询出2011年以后入职的员工信息
// 2) 查询所有的部门信息，与上面的虚拟表中的信息比对，找出所有部门ID相等的员工。
select * from dept d, (select * from employee where join_date > '2011-1-1') e where e.dept_id = d.id;
// 使用表连接：
select d.*, e.* from dept d inner join employee e on d.id = e.dept_id where e.join_date > '2011-1-1'
mysqlに存在するとの違いは何ですか？
https://cloud.tencent.com/developer/article/1144244
https://www.jianshu.com/p/f212527d76ff
select * from A where id in (select id from B);
select * from A where exists (select 1 from B where A.id=B.id);
-
in（）ステートメントの内部原理
IN（）は1回だけ実行され、Bテーブル内のすべてのidフィールドを見つけて、それらをキャッシュします。その後、AテーブルのIDがBテーブルのIDと等しいかどうかを確認し、等しい場合は、AテーブルのすべてのレコードがトラバースされるまでAテーブルのレコードを結果セットに追加します。
可以看出，当B表数据较大时不适合使用in()，因为它会把B表数据全部遍历一次例：テーブルには10,000レコードがあり、Bテーブルには1,000,000レコードがあるため、最大で10,000 * 1,000,000回トラバースできますが、これは非常に非効率的です。
-
EXISTS（）ステートメントの内部動作
Existsは、ループを使用して外部テーブルを1つずつクエリするために使用されます。クエリがexistsの条件ステートメントをチェックするたびに、existsの条件ステートメントがレコード行を返すことができます（レコード行の数に関係なく、返される可能性がある）の場合、条件は真であり、現在のループが返されます。レコードに対して、逆に、存在する条件ステートメントがレコード行を返すことができない場合、現在のループに到達したレコードは破棄されます。条件の存在はbool条件のようなものです。結果セットを返すことができる場合、それはtrueであり、返すことはできません。結果セットはfalseです。
当B表比A表数据大时适合使用exists()，因为它没有那么多遍历操作，只需要再执行一次查询就行。例：テーブルに10,000レコードがあり、Bテーブルに1,000,000レコードがある場合、exists（）が10,000回実行され、AテーブルのIDがBテーブルのIDと等しいかどうかが判別されます。
varcharとcharの違いは？選び方は？
チャーの特徴：
1. char表示定长字符串，长度是固定的；
2. 如果插入数据的长度小于char的固定长度时，则用空格填充；
3. 因为长度固定，所以存取速度要比varchar快很多，甚至能快50%，但正因为其长度固定，所以会占据多余的空间，是空间换时间的做法；
4. 对于char来说，最多能存放的字符个数为255，和编码无关
varcharの特徴：
1. varchar表示可变长字符串，长度是可变的；
2. 插入的数据是多长，就按照多长来存储；
3. varchar在存取方面与char相反，它存取慢，因为长度不固定，但正因如此，不占据多 余的空间，是时间换空间的做法；
4. 对于varchar来说，最多能存放的字符个数为65532
選び方は？
1. 对于经常变更的数据来说，CHAR比VARCHAR更好，因为CHAR不容易产生碎片。
2. 对于非常短的列，CHAR比VARCHAR在存储空间上更有效率。
3. 使用时要注意只分配需要的空间，更长的列排序时会消耗更多内存。
4. 尽量避免使用TEXT/BLOB类型，查询时会使用临时表，导致严重的性能开销。
mysqlのint（10）、char（10）、varchar（10）の違いは何ですか？
- int（10）の10は、格納されているデータのサイズではなく、表示されているデータの長さを表します。
- char（10）は、固定長の10文字を格納し、10文字未満の場合はスペースで埋め、より多くのストレージスペースを占有することを意味します。
- Varchar（10）は、10個の可変長文字を格納することを意味します。文字数はその数と同じです。スペースも文字として格納されます。これは、char（10）のスペースとは異なります。char（10）のスペース）スペースが占有されていないことを示します。文字を数えます
MySQLの削除、削除、切り捨ての違いは何ですか？
3つすべてが削除を示しますが、3つの間にいくつかの違いがあります。
| 削除 | 切り捨てる | 落とす | |
|---|---|---|---|
| の種類 | DMLに属します | DDLに属します | DDLに属します |
| ロールバック | ロールバック | ロールバックしない | ロールバックしない |
| コンテンツを削除する | テーブル構造はまだあります。テーブルのデータ行の全部または一部を削除してください | テーブル構造はまだあります。テーブル内のすべてのデータを削除してください | データベースからテーブルを削除すると、すべてのデータ行、インデックス、およびアクセス許可も削除されます |
| 削除速度 | 削除速度が遅いので、1行ずつ削除する必要があります | 迅速な削除 | 最速の削除 |
したがって、テーブルが不要になった場合はdropを使用し、一部のデータ行を削除する場合はdeleteを使用し、テーブルを保持してすべてのデータを削除する場合はtruncateを使用します。
MySQL binlogにはいくつの入力フォーマットがありますか？違いは何ですか？
ステートメント、行、混合の3つの形式があります。
- ステートメントモードでは、データを変更するすべてのSQLがbinlogに記録されます。各行の変更を記録する必要がないため、binlogの量が減り、IOが節約され、パフォーマンスが向上します。sqlの実行は状況に応じて行われるため、保存時に関連情報を保存する必要があり、関数などを使用して記録・コピーできない文もあります。
- 行レベルでは、SQLステートメントのコンテキスト関連情報は記録されず、変更されたレコードのみが保存されます。記録単位は各行の変更であり、基本的にはすべて記録できますが、操作が多いため、行の変更（テーブルの変更など）が多く発生するため、このモードのファイルは節約しすぎます。情報とログボリュームが大きすぎます。
- 妥協案であるMixedは、一般的な操作にステートメントレコードを使用し、ステートメントを使用できない場合は行を使用します。
さらに、MySQLの新しいバージョンでは、行レベルにいくつかの最適化が行われました。テーブル構造が変更されると、行ごとではなくステートメントが記録されます。
MySQLにはどのような種類のログがありますか？
https://database.51cto.com/art/201806/576300.htm
バイナリログとREDOログの違いは何ですか？
トランザクションログも記録するので、先に紹介したバイナリログとの違いは何ですか？まず、バイナリログは、InnoDBなどの他のストレージエンジンのログを含む、MySQLデータベースに関連するすべてのログレコードを記録します。 MyISAM、およびヒープ。InnoDBストレージエンジンのREDOログには、ストレージエンジン自体のトランザクションログのみが記録されます。
次に、レコードの内容が異なります。ユーザーがバイナリログファイルレコードの形式をSTATEMENT、ROW、またはMIXEDのいずれに設定しても、トランザクションの特定の操作内容が記録されます。つまり、ログは論理ログです。InnoDBストレージエンジンのREDOログファイルは、各ページ（ページ）の変更の物理ステータスを記録します。
また、書き込み時間も異なります。バイナリログファイルは、トランザクションがコミットされる前にのみ送信されます。つまり、この時点でのトランザクションの大きさに関係なく、ディスクに書き込まれるのは1回だけです。トランザクションの過程で、REDOログエントリ（redoentry）がREDOログファイルに継続的に書き込まれます。