1.ちょっとしたトリックを共有します：
データ型を定義するときに、整数であると判断された場合はINTを使用し、10進数の場合は固定小数点型DECIMALを使用し、文字列の場合は主キーでない限りTEXTを使用します。 ;日付と時刻の場合は、DATETIMEを使用します
2.このステートメントを実行した後、demo.importheadと同じテーブル構造を持つ空のテーブルdemo.importheadhistが作成されます。
CREATE TABLE demo.importheadhist
LIKE demo.importhead;3.3。
CREATE TABLE
(
字段名 字段类型 PRIMARY KEY
);
CREATE TABLE
(
字段名 字段类型 NOT NULL
);
CREATE TABLE
(
字段名 字段类型 UNIQUE
);
CREATE TABLE
(
字段名 字段类型 DEFAULT 值
);
-- 这里要注意自增类型的条件，字段类型必须是整数类型。
CREATE TABLE
(
字段名 字段类型 AUTO_INCREMENT
);
-- 在一个已经存在的表基础上，创建一个新表
CREATE TABLE demo.importheadhist LIKE demo.importhead;
-- 修改表的相关语句
ALTER TABLE 表名 CHANGE 旧字段名 新字段名 数据类型;
ALTER TABLE 表名 ADD COLUMN 字段名 字段类型 FIRST|AFTER 字段名;
ALTER TABLE 表名 MODIFY 字段名 字段类型 FIRST|AFTER 字段名;4.ストレージエンジンを指定します
ALTER TABLE 表名 ENGINE=INNODB;5. SQLステートメントを記述して、テーブルdemo.goodsmasterのフィールド「salesprice」を繰り返し不可で空でないように変更してください。
ALTER TABLE demo.goodsmaster
CHANGE COLUMN salesprice salesprice DECIMAL(10,2) NOT NULL UNIQUE;6.クエリステートメントの構文構造：
SELECT *|字段列表
FROM 数据源
WHERE 条件
GROUP BY 字段
HAVING 条件
ORDER BY 字段
LIMIT 起始点，行数7。
INSERT INTO 表名 [(字段名 [,字段名] ...)] VALUES (值的列表);
INSERT INTO 表名 （字段名）
SELECT 字段名或值
FROM 表名
WHERE 条件
DELETE FROM 表名
WHERE 条件
UPDATE 表名
SET 字段名=值
WHERE 条件
SELECT *|字段列表
FROM 数据源
WHERE 条件
GROUP BY 字段
HAVING 条件
ORDER BY 字段
LIMIT 起始点，行数8.ユーザーが2つの独立したストアを持ち、それぞれに独自のシステムがあるとします。ここで、1つのシステムで2つの店舗を管理するためのチェーンオペレーションモデルを導入する必要があります。次に発生する最初の問題は、データ統合の必要性です。「ONDUPLICATE」キーワードを使用して2つの店舗の商品情報データを統合する方法を説明するために、商品情報テーブルを例として取り上げましょう。
ストアAの製品情報テーブルが「demo.goodsmaster」であると仮定すると、コードは次のようになります。
mysql> SELECT *
-> FROM demo.goodsmaster;
+------------+---------+-----------+---------------+------+------------+
| itemnumber | barcode | goodsname | specification | unit | salesprice |
+------------+---------+-----------+---------------+------+------------+
| 1 | 0001 | 书 | 16开 | 本 | 89.00 |
| 2 | 0002 | 笔 | 10支装 | 包 | 5.00 |
| 3 | 0003 | 橡皮 | NULL | 个 | 3.00 |
+------------+---------+-----------+---------------+------+------------+
3 rows in set (0.00 sec)ストアBの商品情報テーブルは「demo.goodsmaster1」です。
mysql> SELECT *
-> FROM demo.goodsmaster1;
+------------+---------+-----------+---------------+------+------------+
| itemnumber | barcode | goodsname | specification | unit | salesprice |
+------------+---------+-----------+---------------+------+------------+
| 1 | 0001 | 教科书 | NULL | NULL | 89.00 |
| 4 | 0004 | 馒头 | | | 1.50 |
+------------+---------+-----------+---------------+------+------------+
2 rows in set (0.00 sec)ストアBの製品データをストアAの製品テーブルに挿入するとします。製品番号が重複している場合は、ストアAのバーコードをストアBのバーコードに置き換え、ストアAをストアBの製品名に置き換えます。 。繰り返し番号がない場合は、店舗Bの商品データを店舗Aの商品テーブルに直接挿入します。この操作は、次のSQLステートメントを使用して実行できます。
INSERT INTO demo.goodsmaster
SELECT *
FROM demo.goodsmaster1 as a
ON DUPLICATE KEY UPDATE barcode = a.barcode,goodsname=a.goodsname;
-- 运行结果如下
mysql> SELECT *
-> FROM demo.goodsmaster;
+------------+---------+-----------+---------------+------+------------+
| itemnumber | barcode | goodsname | specification | unit | salesprice |
+------------+---------+-----------+---------------+------+------------+
| 1 | 0001 | 教科书 | 16开 | 本 | 89.00 |
| 2 | 0002 | 笔 | 10支装 | 包 | 5.00 |
| 3 | 0003 | 橡皮 | NULL | 个 | 3.00 |
| 4 | 0004 | 馒头 | | | 1.50 |
+------------+---------+-----------+---------------+------+------------+
4 rows in set (0.00 sec)9.質問について考えていただきたいと思います。商品テーブルdemo.goodsmasterでは、フィールド「itemnumber」が主キーであり、自動インクリメントの制約を満たしています。レコードを削除してデータを挿入すると、ここでも、フィールド「itemnumber」が表示されます。値は連続していません。考えてみてください、これを防ぐためにデータを挿入する方法は？
回答：商品テーブルにレコードを追加する場合、判断できます。アイテム番号が連続していない場合は、アイテム番号を省略して自動的にインクリメントするのではなく、アイテム番号の値を明示的に指定することでデータを挿入できます。
ALTER TABLE demo.goodsmasterAUTO_INCREMENT=ブレークポイント値
10.販売流量計demo.transで単位が「パッケージ」であるすべての製品の価格を元の価格の80％に変更したい場合、どうすればよいですか？
UPDATE demo.trans AS a、demo.goodsmaster AS b SET price = price * 0.8 WHERE a.itemnumber = b.itemnumber AND b.unit='包'
11.外部キー制約と関連付けクエリ
-- 定义外键约束：
CREATE TABLE 从表名
(
字段 字段类型
....
CONSTRAINT 外键约束名称
FOREIGN KEY (字段名) REFERENCES 主表名 (字段名称)
);
ALTER TABLE 从表名 ADD CONSTRAINT 约束名 FOREIGN KEY 字段名 REFERENCES 主表名 （字段名）;
-- 连接查询
SELECT 字段名
FROM 表名 AS a
JOIN 表名 AS b
ON (a.字段名称=b.字段名称);
SELECT 字段名
FROM 表名 AS a
LEFT JOIN 表名 AS b
ON (a.字段名称=b.字段名称);
SELECT 字段名
FROM 表名 AS a
RIGHT JOIN 表名 AS b
ON (a.字段名称=b.字段名称);12.同時実行性が高いなどの理由でビジネスシナリオで外部キー制約を使用できない場合、この場合、アプリケーションレベルでデータの一貫性をどのように確保しますか？
外部キー制約を使用できない場合は、データの整合性を確保するためにアプリケーション層に機能モジュールを追加できます。たとえば、メインテーブルのレコードを削除するときに、レコードがスレーブテーブルに適用されているかどうかを確認する関数を追加します。適用されている場合、削除は許可されていません。
13. HAVINGは単独では使用できないため、GROUPBYと一緒に使用する必要があります。GROUP BYは、グループ化データとして理解されます。これは、グループ内のデータに対して統計計算を実行するのに便利です。
14.持っていることとどこにあるかの違い：
最初の違いは、結合を介して関連テーブルから必要なデータを取得する必要がある場合、WHEREは最初にフィルタリングしてから結合し、HAVINGは最初に接続してからフィルタリングすることです。この点は、WHEREがリレーショナルクエリでHAVINGよりも効率的であることを決定します。WHEREは最初にフィルタリングされ、フィルタリングされた小さなデータセットと関連するテーブルに接続できるため、使用するリソースが少なくなり、実行効率が比較的高くなります。HAVINGは、最初に結果セットを準備する必要があります。つまり、フィルター処理されていないデータセットを使用して関連付け、次にこの大きなデータセットをフィルター処理する必要があります。これにより、より多くのリソースが消費され、実行効率が低下します。
2つ目の違いは、WHEREはテーブル内のフィールドをフィルター条件として直接使用できますが、フィルター条件としてグループ化する際に計算関数を使用できないことです。HAVINGは、グループ化計算関数とグループ化フィールドをフィルター条件として使用できるGROUPBYと組み合わせて使用する必要があります。調子。統計のためにデータをグループ化する必要がある場合、HAVINGはWHEREでは実行できないタスクを完了できます。
15. HAVING後の条件は、グループ化の計算関数を含む条件でなければならないということわざがありますが、それは正しいと思いますか？なんで？
HAVING後の条件は、グループ内の計算関数を含む条件である必要があります。このステートメントは、主にクエリの効率を考慮すると意味があります。グループ化の計算関数の条件でない場合、この条件はHAVINGの代わりにWHEREを使用できるはずであり、クエリの効率は高くありません。
16.トランザクションには、アトミック性、一貫性、耐久性、分離という4つの主要な特性があります。
原子性：トランザクション内の操作は、全体のようにすべて実行されるか、すべて実行されないかのいずれかであり、途中から中断できないことを意味します。
整合性：トランザクションの実行によってデータの整合性が破壊されないことを示します。
分離：複数のトランザクションが同時に実行される場合、それらが互いに干渉しないことを意味します。分離レベルが異なれば、相互の独立度も異なります。
永続性：トランザクションによるデータの変更は永続的かつ効果的であり、システム障害が原因で失敗することはありません。
ロックを使用することにより、トランザクションを相互に分離できます。ロックの使用方法は異なり、分離度も異なります。
17.MySQLは4つのトランザクション分離レベルをサポートします。
コミットされていない読み取り：トランザクションでコミットされていない変更されたデータを読み取ることができます。
READ COMMITTED：トランザクションでコミットされた変更されたデータのみを読み取ることができます。
REPEATABLE READ：トランザクションで、読み取られたデータの値が常に最初に読み取られた値と同じであり、他のトランザクションのデータ操作の影響を受けないことを示します。これは、MySQLのデフォルトオプションでもあります。
SERIALIZABLE：トランザクションを示します。特定のデータに対して何らかの操作が実行されると、MySQLはトランザクションが終了するまでデータをロックし、他のトランザクションがデータに対して操作を実行することを禁止します。
トランザクションは、トランザクション内の一連の操作がすべて中断されることなく実行されること、またはすべてが実行されずに再度実行されるのを待つことを保証できます。トランザクションの操作は、アトミック性、一貫性、永続性、および分離によって特徴付けられます。ただし、これは、トランザクションにラップされた一連のDMLデータ操作がすべて成功する、またはすべて失敗するという意味ではありません。操作が成功したかどうかを判断し、MySQLに通知して、トランザクションのすべての操作が成功または失敗することを最終的に確認するために、さまざまな状況でトランザクションのコミットまたはロールバック操作を完了する必要があります。MySQLは4つの異なるトランザクション分離レベルをサポートしています。レベルが高いほど、より多くのシステムリソースが消費されます。実際の状況に応じて設定する必要があります。MySQLでは、すべての操作をロールバックできるわけではありません。データベースの作成、データテーブルの作成、データベースの削除、データテーブルの削除など、これらの操作はロールバックできないため、特にデータベースやデータテーブルを削除する場合は、操作時に十分に注意する必要があります。誤用を防ぐために、最初にバックアップを実行することをお勧めします。
18.トランザクションとは、トランザクション内のデータ操作が正しく実行されるか、すべてが失敗することを確認することです。この文は正しいと思いますか？なんで？
このステートメントは間違っています。トランザクションは、トランザクション処理のすべての操作が実行されるか実行されないことを保証します。実行中にエラーが発生した場合、続行するかロールバックするかはプログラマーが処理する必要があります。
19.ビューは仮想テーブルです。クエリステートメントをビューとしてデータベースに格納できます。必要に応じて、ビューをテーブルとして扱い、その中のデータをクエリできます。
20。
完全なデータベース設計ドキュメントには何が含まれている必要がありますか？
著者の回答：一般的に、要件分析、モデリング（ER）、論理設計（データベース構築やテーブル構築など）、物理設計（インデックス作成など）、実装、運用、保守（災害復旧とバックアップ）などを含める必要があります。 。実際のニーズに応じて、さらに洗練することができます
21.アプリケーションを開発するとき、さまざまなユーザーに応じてデータを水平方向および垂直方向にグループ化する必要が生じることがよくあります。いわゆる水平方向のグループ化とは、どのテーブルデータを表示できるかなど、ユーザーがアクセスできるデータの範囲を指します。いわゆる垂直方向のグループ化とは、能力など、ユーザーがデータにアクセスできる範囲を指します。データを表示および変更したり、削除したりすることもできます。
22.ロールは、MySQL 8.0で導入された新機能であり、権限のコレクションに相当します。
23. MySQLデータバックアップには2つのタイプがあります。1つはデータファイルをコピーすることによってバックアップの目的を達成する物理バックアップであり、もう1つはデータベースの構造と内容を説明する情報を保存することによってバックアップを達成する論理バックアップです。目的。この論理バックアップの方法は無料で、広く使用されています。
まず、データバックアップ用のツールmysqldumpを学びましょう。データベース内のテーブルのバックアップ、データベース全体のバックアップ、データベースサーバー全体のバックアップの合計3つのモードがあります。
24.第一正規形で必須：すべてのフィールドは基本データフィールドであり、さらに分割することはできません。
第2正規形では、第1正規形を満たすことに基づいて、データテーブル内の各データレコードが一意に識別可能である必要があります。また、すべてのフィールドは、主キーの一部だけでなく、主キーに完全に依存している必要があります。
2番目の正規形の要件に従って、元のデータテーブルを3つのデータテーブルに分割します。
第3正規形では、データテーブルに、第2正規形を満たすことに基づいて非主キーフィールドから派生できるフィールドが含まれていてはなりません。つまり、非主キーに依存するフィールドが存在してはなりません。田畑。
25.では、エンティティと属性をどのように区別するのでしょうか。私はあなたに原則を提供します：私たちはそれをシステム全体の観点から見なければなりません。独立して存在できるものは実体であり、不可分であるものは属性です。つまり、属性はそれ以上の説明を必要とせず、他の属性を含めることはできません。
26. ERモデル図をデータテーブルに変換するにはどうすればよいですか？ERモデルを描画することで、ビジネスロジックを明確にしました。次に、描画したERモデルを特定のデータテーブルに変換するという非常に重要なステップを実行します。変換の原理を紹介します。エンティティは通常、データテーブルに変換されます。多対多の関係は通常、データテーブルに変換されます。1対1、または1対多の関係は、多くの場合、テーブルの外部キーを介して表現されます。新しいデータテーブルを設計するのではなく、属性はテーブルフィールドに変換されます。さて、抽象化されたデータモデルを特定のデータベース設計に実装するために、これらの変換原理を前の表と組み合わせて使用してERモデルを特定のデータテーブルに変換する方法を説明しましょう。
27.設計の観点からクエリのパフォーマンスを向上させるいくつかの方法を紹介しました。データ型を変更してストレージスペースを節約する、長所が短所を上回る場合は冗長フィールドを追加する、大きなテーブルで頻繁にクエリされるフィールドとクエリ頻度を変更するSplit低いフィールドを別々のテーブルに入れます。null以外の制約を使用してみてください。これらはすべて、システムのクエリ効率をさらに向上させ、開発するアプリケーションをより簡潔で効率的にするのに役立ちます。
28. MySQLは、アナライザーを介して実行したいこととオプティマイザーを介して実行する方法を認識しているため、エグゼキューターフェーズに入り、
ステートメントの実行を開始します。