1、なぜ主キーを設定する必要がありますか？
：あなたは主キーを設定しない場合ので、InnoDBはあなたが主キー増分として非表示の列を生成するのに役立ちます。だから、とにかく、主キーを生成する必要が、その後、あなたにも自分の主キーを指定されたかもしれない、いくつかのケースでは、クエリの効率を改善するために、明示的な主キーのインデックスを過ごすことができます！
2、あなたは主キーがインクリメントまたはUUIDているでしょうか？
A：確かインクリメントああ。クラスタ化インデックスのInnoDBの主キー。主キーが増分である場合、新しいレコードを毎回挿入し、記録を順次充填したときに、その後のインデックスノードの現在の位置に追加され、その後、それは自動的に新しいページを開くであろう。主キーをインクリメントしていない場合は、途中で挿入かもしれませんが、それはテーブルの断片化の多くを生成し、ページを分割するためにつながります！。
上記の文章は右読み取ることができない、大きな方言がある：良好なパフォーマンス増分挿入！
さらに、あなたに付属のテスト用テーブルは、テーブル名は、主キーとしてUUID UUIDで使用されます。あなたが知っているし、パフォーマンスのギャップを見て：
図より長く、そしてより多くのスペースとして挿入するとき、ときにUUIDは主キーです！
量、我々はあなたがインクリメント主キーを答える際に、行う方法を実行して自動インクリメントの主キー」を考えることを忘れてはなりませんか？"
3、主キー、なぜビジネス上の意味はお勧めしていますか？
A： 2つの理由があります。
（1）任意のリストされているビジネス上の意味の可能性が変更されたのは、プライマリキーを1回ビジネス上の意味を持っているので、主キーが起こる変更することも可能です。主キーの変更が発生すると、ディスク上の変更データの保存場所が発生し、それがページ分割、スペースデブリの創出につながる可能性があります。
2）ビジネス上の意味を持つ主キー、必ずしも増加のためです。それはメインのフロントは、特定のキーデータよりも大きくなっているの後ろに挿入されたデータを保証するものではありませんが、データの挿入順序になります。それは、データが前の小さなよりメインキーの後ろに挿入されない場合は、ページ分割、スペースデブリの創出につながる可能性があります。
フィールド列挙enumの理由を4、を示すものではありませんか？
A：通常で、職場でのフィールドの列挙を表し tinyint型のタイプ。なぜ列挙型は、それを入力しませんか？次の2つの理由
運用効率によって低い（1）ENUM型ORDER、追加の操作を必要とする
列挙値の値は、トラップがある場合（2）
例えば、以下の表構造が
CREATE TABLEのテスト（foobarにするENUM（' 0 '、' 1 '、' 2 '））;
この時点で、あなたはステートメントを実行します
MySQLの> INSERT INTO試験VALUES（1）。
結果をチェック
結果は、ピットの父を生成しました。
声明はそう書かれたようになっているはず挿入し、挿入されている1
MySQLの> INSERT INTO試験VALUES（ ' 1 '）。
5.金銭現場での使用のどのタイプ？
A：通貨単位が分割されている場合は、使用することができるのIntタイプを。あなたが、元を使う、という場合は小数。決してフロート及びダブル floatとdoubleはバイナリで保存され、そのため、多少の誤差があります。
比喩は、次の列を構築します
CREATE TABLE 'T'（ `price` フロート（10、2）DEFAULTの NULLを、 ）ENGINE =のInnoDB DEFAULT CHARSET = UTF8
価格データ1,234,567.23に列を挿入すると、あなたは、データの表示されています精密不正確、1,234,567.25になります！
6.フィールド時間のどのようなタイプの？
A：この問題は固定されていない答えが、答えるために、独自のプロジェクトの背景と組み合わせる必要があります！ライン上でそれが明確な理由！
（1）VARCHAR、varchar型定期預金であれば、視覚表示利点。しかし、また、地元のピットがたくさん。たとえば、データにパリティを挿入しない、あなただけのデータの一部を見つけるかもしれない一日は、2013111のデータでは、その代表者2013年1月11日、または2013年11月1日？
第二に、比較演算を実行する時間は、あなたが時間のタイプに変換するSTR_TO_DATE他の機能を使用する必要がある、あなたはとてもインデックスにヒットされていないという書き込みがあります。大量のデータは、ピットです！
（2）タイムスタンプは、種類が4バイト、それは1970年1月1日8時00分01秒2038-01-1911に表現される時間の整数である：14：07 2038後で、タイムスタンプ型に格納することはできません。
しかし、それは利点があり、タイムスタンプの種類は、タイムゾーン情報です。お使いのシステムのタイムゾーンの変更後は、たとえば、あなたはタイムゾーンを変更します
SETの TIME_ZONE = "アメリカ/ New_Yorkの";
あなたは、自分のフィールドの変更で、プロジェクトの値が発生することがわかります。この機能は、特別な注意を払って、大規模な国際プロジェクトの数、タイムゾーン間でアプリケーションを作るために使用することができます！
（3）日時、日時店8バイト、それは1000年1月1日23時59分59秒までの時間範囲〜9999-12-31午前0時00分00秒に格納されています。
明らかに、より大きな貯蔵時間。しかし、それは彼の記憶が無い時間帯情報と、時間の絶対値であるピットです。あなたはタイムゾーンデータベースを変更した場合、値が自分を変えていません！
（4）BIGINT、タイムスタンプを維持するも8バイトを、タイムスタンプはほとんどが、自分自身を維持することであるよりも、範囲を示し、容易ではありません。
7、なぜ大容量ストレージの写真、オーディオ、ビデオ、およびその他のコンテンツを指示していませんか？
：私たちは、実用的なアプリケーションでは、HDFSのファイルを格納するために使用されています。次にmysqlの、唯一のファイルの保存パスを保持します。MySQLは大容量のファイル、すなわちテキストおよび格納するために2つのタイプのフィールドを設計するために使用されている
ブロブタイプを。しかし、我々の生産では、これら2つのタイプの基本的な必要性！
2つの主な理由があります次のとおりです。
（1）MySQLのメモリの一時テーブルはこのような大規模なようTEXT、BLOBデータ型をサポートしていないクエリは、このようなデータが含まれている場合、並べ替えやその他の操作時に、あなたは、あなたが一時ディスクテーブルを使用する必要があり、メモリの一時テーブルを使用することはできません。スロークエリの効率が得られ
（2）ビンログあまりにも多くのコンテンツ。あなたのデータの内容が比較的大きいので、バイナリログより多くのコンテンツを引き起こします。我々はすべて知っているように、マスター・スレーブの同期が同期され、あまりにもバイナリログによりBINLOG、それはマスター・スレーブの同期の問題の効率化につながります！
したがって、我々は、テキストおよびBLOBタイプの使用はお勧めしません！
8、なぜフィールドがNOT NULLとして定義されている必要がありますか？
：（1）パフォーマンスの低下指数
クエリー列の参照を最適化することは困難でMySQLが空になることがあり、それは、インデックス、インデックス値の統計情報や、より複雑になります。空の列には、より多くのストレージスペースを必要とするだけでなく、内部のmysql特別な処理が必要となることがあります。空の列が索引付けされてもよいした後、各レコードは、追加のバイトを必要とするだけでなく、インデックスのMyISAMインデックスが可変サイズの固定サイズとなる引き起こします。- 「高性能のMySQL第2版」から
（2）クエリは、いくつかの予期しない結果になります
一例を与えるために、誰もが理解するであろう。、以下のテーブル構造を仮定
作成 、テーブルtable_2を（ `id`のINT（11）NOT NULL 、 名前のVARCHAR（20）NOT NULL ）
このようなテーブルデータがあります
あなたは文を実行します
選択 数（名）から table_2。
あなたは結果が2であることがわかりますが、実際には4件のデータがあります！同様のお問い合わせは、実際には少数を示すために、多くのがあります。
NULL列があるので、バグをトラブルシューティングするために、開発時間を無駄に、予期しない結果がたくさんあるでしょう、覚えておいてください。
また、この理解を参照してください。https://www.cnblogs.com/myseries/p/11264178.html
情報ソースします。https：//www.itcodemonkey.com/article/15662.html