MySQL 戦闘の基本を始める
- MySQLの基礎知識入門 実戦(1):データベースコマンドラインへのログイン
- MySQLの基礎知識入門 実戦(2):24時間データがデフォルトで0で埋められる統計SQL文
- MySQL 基礎知識入門 (3): 過去 7 日間の総売上の解決策、PHP バックエンドの mysql ステートメント、当日が空の場合は自動的に 0 が埋められます
- MySQLの基礎知識入門 実戦(4):MySQLの高度な機能 CASE WHEN END
- MySQLの基礎知識入門 実戦(5):SMARTY二次ループ配列の出力方法
- MySQL 戦闘の基礎を始める (6): MySQL は mysqldump を使用してデータ エラーの解決策をエクスポートします
- MySQL入門基礎知識 実戦編(7):sourceコマンドを使ったデータインポートのmysqlの操作スキーム
- MySQLの基礎知識入門 実戦(8):MySQLデータベースインスタンスのデータテーブルの解釈、フィールドの命名方法とデータ型の設定
- MySQL Combat の基礎知識入門 (9): 4 つのテーブルにわたる効率的なクエリ コードのための MYSQL ソリューション
- MySQL Combat の基礎知識入門 (10): 今日、昨日、過去 7 日間、過去 30 日間のフィルター ステートメントに実装されたソリューション
- MySQL 戦闘の基礎を始める (11): echart の日次取引高縦棒グラフを解決するために、過去 7 日間の日次データ統計を簡単かつ効率的にスクリーニングする
- MySQL 基礎知識入門 (12): 今日と昨日の 24 時間データ統計の SQL ステートメント ソリューション
MySQL 戦闘の基本を始める
「積もり積もった塵、あの時自分が集めたもの」というテーマから「過去を振り返り、新しさを知る」またとない機会です。
1. Mysqlフィールドタイプの説明
MySQL には、テーブル内のフィールドの定義に使用できるさまざまなデータ型があります。一般的な MySQL フィールド タイプとその説明をいくつか示します。
-
数値型:
- INT: -2147483648 ~ 2147483647 の範囲の整数値を格納します。
- BIGINT: -9223372036854775808 から 9223372036854775807 の範囲の大きな整数値を格納します。
- FLOAT: 単精度浮動小数点数を格納します。
- DOUBLE: 倍精度浮動小数点数を格納します。
- DECIMAL: 正確な 10 進数値を保存し、精度と位取りを指定できます (たとえば、DECIMAL(10, 2) は精度が 10 で、小数点以下 2 桁が予約されていることを意味します)。
-
文字列型:
- CHAR:255文字までの固定長の文字列を格納します。
- VARCHAR: 最大長 65535 文字の可変長文字列を格納します。
- TEXT: 可変長のテキスト データを格納します。最大長は 65535 文字です。
- ENUM: 列挙型の値を格納し、事前定義された値のリストから値を選択できるようにします。
- SET: セット タイプの値を保存し、事前定義された値のリストから 1 つ以上の値を選択できるようにします。
-
日付と時刻のタイプ:
- DATE: 日付値(年、月、日)を格納します。
- TIME: 時間の値(時、分、秒)を保存します。
- DATETIME: 日付と時刻の値を保存します。
- TIMESTAMP: データの挿入時間と更新時間を記録するためのタイムスタンプを保存します。
-
ブール型:
- BOOLEAN: true または false を表すブール値を格納します。
-
バイナリ型:
- BLOB: 大量のバイナリ データを格納できるバイナリ ラージ オブジェクトを格納します。
- VARBINARY: 可変長バイナリデータを格納します。
これらは MySQL で一般的に使用されるフィールド タイプであり、それぞれに異なる特性と許容可能な値の範囲があります。テーブルを作成するときは、データの性質とニーズに応じて最適なフィールド タイプを選択することが非常に重要です。
2. mysql 自動インクリメント ID の最大値はいくらですか
MySQL 自動インクリメント ID の最大値は、使用されるデータ型によって異なります。MySQL では、一般的に使用される自動インクリメント ID データ型は INT、BIGINT などです。INT型の場合、最大値は2147483647となります。BIGINT型の場合、最大値は9223372036854775807となります。自動インクリメントIDが最大値に達した後、再度データを挿入するとエラーが報告されて自動インクリメントが停止し、自動インクリメントIDの初期値をリセットする必要があります。
3. int(10) と int(11) の違い
MySQL では、INT(10) と INT(11) の違いは、データ型そのものではなく、主に表示幅にあります。実際、INT(10) と INT(11) はストレージと範囲の点で同一であり、どちらも 4 バイトの整数型です。
INT(10) と INT(11) の数値は、ゼロ埋め込みで整数を表示するために必要な最小桁数を指定するだけです。たとえば、INT(10) は、表示幅が少なくとも 10 ビットである必要があることを示します。
ただし、これは、保存された範囲または値の有効性には影響しません。表示幅を 10 または 11 に指定しても、INT 型は -2147483648 ~ 2147483647 の範囲の整数値を格納できます。表示幅の指定は主に、出力の美しさと一貫性を制御するために使用されます。
2 つの違いは、次の例で確認できます。
CREATE TABLE 表名 (
字段名1 INT(10),
字段名2 INT(11)
);
上記の例では、フィールド fieldname1 と fieldname2 は両方とも INT 型ですが、fieldname1 は最小幅 10 桁で表示され、fieldname2 は最小幅 11 桁で表示されます。field-name1 と field-name2 はどちらも同じ範囲の整数値を格納できます。違いは、数値が不十分なパディングで表示される場合、フィールド名 2 の幅が広くなるということです。
全体として、ストレージと範囲に関して INT(10) と INT(11) に違いはありません。表示されるときの幅がわずかに異なるだけです。特定の表示幅の使用を選択するかどうかは、出力にどの程度の一貫性と見た目の美しさを求めるかに大きく依存します。
4 番目、varchar(64) と varchar(255) の違い
MySQL では、VARCHAR(64) と VARCHAR(255) の違いは主に、ストレージ領域とストレージ容量の制限にあります。
-
記憶域: VARCHAR(64) 型は最大 64 文字の可変長文字列を保存でき、VARCHAR(255) 型は最大 255 文字の可変長文字列を保存できます。つまり、VARCHAR(255) はより長い文字列を保持できます。
-
ストレージ容量: VARCHAR(64) はより小さい文字列を格納できますが、より長いテキストやコンテンツを格納する必要がある場合は、VARCHAR(255) の方がより大きなストレージ スペースを提供します。これにより、VARCHAR(255) は、記事の内容や長い説明などの長いテキスト フィールドを格納するのにより適したものになります。
VARCHAR 型は可変長文字列型であり、文字列データを保存するために、実際に格納された文字数と追加のバイト オーバーヘッドのみを使用することに注意してください。したがって、VARCHAR(64) であっても VARCHAR(255) であっても、実際の記憶域長に必要な領域のみが使用され、固定記憶域は占有されません。
VARCHAR(64) または VARCHAR(255) を選択する場合は、次の要素を考慮してください。
-
データ長: 保存する特定のデータ長に応じて、適切な VARCHAR 長を選択します。最大長が 64 文字を超えないことが確実な場合は、VARCHAR(64) を選択して記憶域スペースの無駄を減らすことができます。
-
データ型の一貫性: テーブル内の他の列の VARCHAR 長が 255 で、一貫性を維持したい場合は、VARCHAR(255) を選択できます。
-
パフォーマンスと最適化: 一般に、長さが短い VARCHAR は、使用する記憶領域が少なくなり、パフォーマンスが向上します。データ長が制限されていて安定している場合は、より短い VARCHAR 長の使用を検討できます。
要約すると、VARCHAR(64) と VARCHAR(255) の主な違いは、記憶領域と記憶容量の制限にあります。データ長、一貫性要件、パフォーマンスの考慮事項に基づいて、適切な VARCHAR 長を選択してください。
5. 整数保存時間と DATE 保存時間を使用した場合の比較
MySQL では通常、整数型 (INT や BIGINT など) または日付/時刻型 (DATE、DATETIME、TIMESTAMP など) を使用して時刻データを保存します。以下は、時間を格納するために整数型と日付/時刻型を使用する場合の比較です。
-
整数型で時刻を保存する:
整数型で時刻を保存する一般的な方法は、タイムスタンプを使用することです。タイムスタンプは、特定の時点 (通常は 1970 年 1 月 1 日 00:00:00 UTC) からの秒数を表す整数値です。利点は次のとおりです。- 高いストレージ効率: 整数型は、占有するストレージ容量が少なくなります。
- 計算は便利です。数学的な演算や比較を実行できます。
- 並べ替え可能: 時間の並べ替えは、整数値を並べ替えることによって実現できます。
ただし、整数型の保存時間に関連するいくつかの考慮事項は次のとおりです。
- 可読性が低い: 値は保存され、特定の日付と時刻として直接識別できません。
- 手動処理が必要: 整数値を人間が判読できる日付と時刻に変換するには、アプリケーションでの変換操作と書式設定操作が必要です。
-
日付/時刻型の保存時間:
MySQL は、日付と時刻の情報を保存するために、DATE、DATETIME、TIMESTAMP などのさまざまな日付/時刻型を提供します。これらのタイプには次の利点があります。- 読み取り可能: 保存された値は、人間が判読できる日付と時刻の形式で表されます。
- 自動関数: 自動更新 (CURRENT_TIMESTAMP など) および組み込み関数 (DATE_FORMAT など) をサポートします。
- よりセマンティック: 計算や比較など、日付と時刻を直接操作できます。
日付/時刻型を使用して時刻を保存する場合は、次の点に注意する必要があります。
- 大規模な記憶域: 日付/時刻型、特に DATETIME 型と TIMESTAMP 型は、大きな記憶域を占有します。
- パフォーマンスへの影響: 頻繁に更新されるテーブルの場合、TIMESTAMP タイプを使用すると、追加のオーバーヘッドが発生する可能性があります。
- タイム ゾーンの問題: 日付/時刻型によって保存される時刻値は、データベース セッションのタイム ゾーン設定の影響を受けます。
要約すると、複雑な計算、並べ替え、時刻の取得を実行する必要がある場合、または直接保存して読みやすい日付と時刻の形式で表示する必要がある場合は、日付/時刻タイプの方が適しています。目標がストレージ効率とカスタム計算である場合、または他のシステム (外部 API など) と対話する必要がある場合は、整数型の方が適している可能性があります。どの保存方法を使用するかは、アプリケーションのニーズと時間データの処理方法によって異なります。
6. フロントエンドでデータテーブルフィールドと同じ長さに制限する方法
データテーブル フィールドと同様に、フロントエンドでのユーザー入力の長さを制限するには、次の方法を使用できます。
-
HTML の maxlength 属性の使用: タグの場合、maxlength 属性を使用して、ユーザーが入力できる文字数を制限できます。たとえば、データ テーブルのフィールド長が 64 の場合、次のように maxlength を 64 に設定できます。
<input type="text" maxlength="64" />
-
JavaScript 入力長の制限: JavaScript を使用してユーザー入力の長さを制限し、制限を超えた場合にフォームの送信を防ぐことができます。入力された文字数は、入力イベント (入力やキーダウンなど) をリッスンすることでリアルタイムで計算され、フィールドの長さに応じて処理されます。以下に例を示します。
<input type="text" id="myInput" /> <span id="charCount"></span> <script> const input = document.getElementById('myInput'); const charCount = document.getElementById('charCount'); const maxLength = 64; // 设置字段长度 input.addEventListener('input', function() { const enteredText = input.value; charCount.textContent = `${ enteredText.length}/${ maxLength}`; if (enteredText.length > maxLength) { input.value = enteredText.slice(0, maxLength); // 截断超出的部分 } }); </script>
これらのメソッドは、フロントエンドのデータ テーブル フィールドの長さに関して同じ制限を達成できます。長さの検証は、ユーザー エクスペリエンスを向上させ、リアルタイムのフィードバックを提供するためにフロントエンドで行われますが、データの整合性とセキュリティを確保するためにバックエンドでも行う必要があることに注意してください。フロントエンド検証は補助的な手段としてのみ使用され、バックエンド検証が最終的な保証となります。
@時々漏れます