マイクロチャンネル公衆数からこの記事
水の惑星の友人が質問に答えるために続け：
シェンの先生は、私がインターネットに耳を傾け、MySQLのデータテーブルを述べ、大量のデータの場合には、主キーが長すぎるすべきではない、それはそうではないのですか？これはなぜでしょうか？
さて問題は、一般化することはできません：
（1）した場合はInnoDBストレージエンジン、主キーが長すぎてはならない ;
（2）それがある場合のMyISAMストレージエンジン、ほとんど効果があり、
プリアンブル知識を説明する簡単な栗を与えます。
データテーブルがあるとします
（フラグにPK ID、名前KEY、セックス、）Tは、
前記
（1）主キーのIDであり、
（2）共通名インデックスが構築され、
4つのレコードがテーブルに存在すると仮定すると：
1、shenjian、M。
3、zhangsan、M、
5、リージ、I、A
9、wangwu、F、B
ストレージエンジンはMyISAMテーブルであり、そのインデックスレコードの構造は、この場合には：
（1）記録（レコード）を記憶するための別個の領域を有し、
同一の（2）主キー索引通常の索引構造は、（時間のポインタとして理解される）レコードへのポインタを格納され、
VOは：
（1）記録の主キーインデックスが一緒に格納されていません、したがって、非クラスタ化インデックス（索引クラスタ化されていない）である;
（2）PKのMyISAMを有していてもよく、
使用のMyISAMインデックス検索をするときレコードポインタを見つけるためにインデックスツリーを起動し、録画ポインタによって特定の記録を標的とします。
ナレーター：主キーのインデックスかどうか、だけでなく、一般的なインデックス、同じプロセス。
InnoDBは記録構造の指標は、そのようなものであるである、異なっています。
（1）一緒に格納されたレコードを、主キーインデックスと、
（2）一般的な指標は（のポインタよりも低い）主キーを格納するステップと、
VO：
（1）レコードを主キーインデックスはそれほど凝集指数（「クラスタ化インデックス）と呼ばれ、一緒に格納されています;
（ 2）InnoDBは集合インデックスが存在するであろう。
によってInnoDBは、クエリの主キーインデックスは、それが可能である直接配置行に。
よる場合でも、クエリの通常のインデックス、クエリは、メインキーのうち、その後、主キーのインデックスから初めてとなる二次横断インデックスツリーの。
今の質問は、なぜ、InnoDBの主キーは、長すぎるすべきではありませんか？
あなたが持っていると仮定ユーザー中心を含むシナリオID番号、ID MD5、名前、生年月日、その他の事業の特性を、これらのプロパティは、オンデマンドでクエリを持っています。
最も簡単な方法は、デザインを考えることです。
主キーとしてID
他のプロパティのインデックス
ユーザー（id_code PK、
id_md5（インデックス）、
名前（インデックス）、
誕生日（インデックス））;
このとき、行インデックスツリーレコード構造は、上述しました：
- id_codeクラスタ化インデックス、行協会
- その他のインデックス、プロパティ値id_codeストレージ
ID番号id_codeが長い文字列、大量のデータ、貴重なメモリの場合に値を格納する各インデックスであり、インデックスおよびデータのMySQLの限られたバッファ記憶装置は、ディスクIOの確率を減少させるであろう増加。
ナレーター：同時に、インデックスはディスクスペースの量が増加します。
この時点で、それは新しいのないビジネス上の意味もないはずのID自動インクリメント：
- クラスタ化インデックスの自動インクリメントIDで、行協会
- 他のインデックス、格納された値Id
ユーザー（ID PKオート株式会社、
id_code（インデックス）、
id_md5（インデックス）、
名前（インデックス）、
誕生日（インデックス））;
このように、限られたバッファは、バッファが複数のインデックスとデータ行することができ、ディスクIOは頻度を減らすだろう、全体的なパフォーマンスが向上します。
概要
（1）のMyISAMインデックスと別々のデータ、インデックスのリーフ・ストア・ポインタ、主キー索引通常の索引大差;
InnoDBが統合ストレージインデックスとデータ線をクラスタ化（2）、クラスタ化インデックスストアデータ列自体、通常のインデックス格納主キー;
のInnoDBが長いフィールドPKとして推奨されない（この場合は、自己キーPKにより添加してもよい）、それは問題ではないのMyISAM（3）;
私は水の友達の質問にお答えしたいと思います。