MySQLのデータベース構造マップ
テキストリンク：https://blog.csdn.net/Mirror_w/article/details/91354788
著者：小2つのデータ
A、MySQLのデータベースエンジンが導入します
1、ISAM（索引順次アクセス方式）。
ISAMは、設計時に考慮にデータベースクエリの数が更新よりもはるかに大きい回数を取るために、明確に定義されたと定番データ管理テーブル、です。したがって、ISAM速度読み出し動作が迅速に実行され、メモリおよびストレージリソースの多くを取ることはありません。ISAM二つの主な欠点は、それがトランザクションをサポートしていないということですトレラント故障することはできません。ハードドライブがクラッシュした場合、データファイルを復元することはできません。あなたは、リアルタイムでそれをしなければならない、常にバック、すべてのデータをバックアップし、ミッションクリティカルなアプリケーションで使用されるISAMている場合は、そのレプリケーション機能を通じて、MySQLは、このようなバックアップアプリケーションをサポートすることができます。
注：ISAMの注意事項を使用するには：常にリアルタイムですべてのデータをバックアップする必要があります。
2、MyISAMテーブル：
MySQLのISAM MyISAMがデフォルトの拡張フォーマットおよびデータベースエンジンです。多数の機能のインデックスとフィールドの管理にはないISAMを提供することに加えて、MyISAMテーブルは、複数同時読み取りおよび書き込み操作を最適化するためのロック機構を使用し、コストは、あなたが頻繁に更新を復元するためにOPTIMIZE TABLEコマンドを実行する必要があるということです無駄なスペースのメカニズム。myisamchkのツールのMyISAM、このようなスペースの無駄を復元するために、データベース・ファイルとmyisampackはツールを修復するなど、いくつかの便利な拡張、。大量のデータでWEB開発で使用すると、読み出し動作を実行されるアクションは、次のとおりです。MYISAMは、MySQLのWeb開発は、このような好意の主な理由となっている理由はおそらくである、高速な読み出し動作を強調しました。そのため、ほとんどのWebホスティングプロバイダとプラットフォームのプロバイダーインターネットは専用MyISAM形式を可能にします。彼らは、テーブルの破損後にデータを回復できない重要な欠陥のMyISAM形式。
注：のMyISAMエンジンの用途は注意：あなたは、常にクリアな空間に最適化Tableコマンドを使用する必要があります。必要があり、常にバックリアルタイムですべてのデータをバックアップします。ツールのmyisamchkツールは、データベースファイルmyisampackはツールを修復するために使用し、スペースの無駄を復元するために使用します。
あなたは、データベースエンジンを使用している場合、それは3つのファイルが生成されます。
.FRM：表構造情報
.MYD：データファイル
.MYI：インデックス情報テーブル
3、InnoDBは：
InnoDBのデータベースエンジンは、この技術はMYSQL ++ APIで、MySQLは技術の柔軟性の直接の製品を作成することです。MYSQLを使用する場合は、すべての課題は、あなたは、ISAMと外部キーをサポートしていないトランザクション処理（トランザクション処理）をサポートしていないのMyISAMデータベースエンジンからほとんど直面しています。ISAMおよびMyISAMのエンジンの多くのより遅いが、InnoDBはトランザクション処理と外部キーのサポートが含まれ、これら二つは最初の2つのエンジンですがすることはありません。あなたのデザインは、1つまたはこれらの機能の両方を必要とする場合、前述したように、あなたは背面にある2つのエンジンのいずれかを使用するように強制されます。
MySQL 官方对InnoDB是这样解释的：InnoDB给MySQL提供了具有提交、回滚和崩溃恢复能力的事务安全（ACID兼容）存储引擎。InnoDB锁定在行级并且也在SELECT语句提供一个Oracle风格一致的非锁定读，这些特色增加了多用户部署和性能。没有在InnoDB中扩大锁定的需要，因为在InnoDB中行级锁定适合非常小的空间。InnoDB也支持FOREIGN KEY强制。在SQL查询中，你可以自由地将InnoDB类型的表与其它MySQL的表的类型混合起来，甚至在同一个查询中也可以混合。
InnoDB是为处理巨大数据量时的最大性能设计，它的CPU效率可能是任何其它基于磁盘的关系数据库引擎所不能匹敌的。
InnoDBストレージエンジンは完全にメインメモリにキャッシュデータとインデックスにMySQLサーバ、InnoDBストレージエンジンと統合され、独自のバッファプールを維持しています。InnoDBはテーブルスペース内のテーブル＆インデックスを格納し、表スペースは、いくつかのファイル（またはrawディスクパーティション）を含めることができます。これはMyISAMテーブルとは異なる、例えばMyISAMテーブルの各テーブルは、別々のファイルに存在しています。InnoDBテーブルは、ファイルサイズは、オペレーティング・システム2ギガバイトに制限されている場合でも、任意のサイズにすることができます。
InnoDBは特徴：
1）、トランザクションのインストール
2）マルチバージョンは、データを読み出します
改善3）、ロック機構
4）、外部キーを達成するために
InnoDBテーブルとMyISAMの差
-
InnoDBは、トランザクションのデフォルトにパッケージ化されているのMyISAMは、各SQL言語のためのInnoDBをサポートしていない、トランザクションをサポートする自動コミット、これは速度に影響を与えるだろう、それは始まり、コミット、単一のトランザクションを構成する間に複数のSQL言語を配置するのが最適です。
-
サポートInnoDBの外部キー、およびMyISAMテーブルはサポートしていません。MYISAM失敗にInnoDBの外部キーを含むテーブルの場合、
-
InnoDBは、データとインデックスファイルが主キーを持っている必要があり、一緒に接続されているクラスタ化インデックスで、主キーインデックスは非常に効率的です。しかし、それは二つの補助インデックスクエリ、主キーの最初のクエリを必要とし、主キーによってデータを照会します。そのため、主キーは、主キーが大きすぎるので、他のインデックスも素晴らしいものだが大きすぎてはなりません。非凝集のMyISAMインデックス、別のデータファイルに対し、インデックスポインタは、データファイルに格納されています。プライマリキーインデックスとセカンダリインデックスは独立しています。
-
テーブル内の行のInnoDB特定の番号がSELECT COUNT（*）を実行し、保存されたテーブルからフルテーブルスキャンを必要とされていません。速い、変数にREAD文を実行するだけで、テーブル全体を保存する行の数が可変とし、MyISAMテーブル、。
-
InnoDBは、フルテキストインデックスをサポートしていない、とのMyISAMはMyISAMの高効率化にフルテキストインデックス、クエリをサポートしています。
どのように選択するには：
-
あなたはInnoDBのを選択したい場合は、MyISAMテーブルを考慮していない場合は、サービスをサポートしますか
-
あなただけのクエリの大半でテーブルを読めばかなり頻繁に、読み取りと書き込みの両方が、InnoDBのを使用している場合、あなたは、MyISAMテーブルを考慮することができます。
-
システムベンの崩壊後、MyISAMのがより困難に回復し、彼らは受け入れることができます。
-
MySQL5.5は、InnoDBのバージョンは、デフォルトのエンジン（MyISAMテーブルの前）のMysqlとなっています開始、少なくとも悪いことではないし、InnoDBのを使用し、使用するかわからない場合は、その利点は、明らかにされている説明。
4、NDBCLUSTERストレージエンジン
また、主にMySQLCluster分散クラスタ環境のために、NDBCLUSTERストレージエンジンとして知られているNDBストレージエンジンは、クラスタは、5.0バージョンが提供し始めたのMySQLからの新機能です。
5、MERGEストレージエンジン
MySQLのユーザーマニュアルでMERGEストレージエンジンはまた、我々はまた、MRG_MyISAMエンジンとして知っている、言及されています。なぜ？MERGEストレージエンジンは、単にその機能を理解することができるので、アプリケーションの複雑さを低減する目的を達成するために、外国特別パッケージの入り口を通って単一のアクセスを提供するために、構造の同一MyISAMテーブルを達成することです。MERGEテーブルを作成するために、ベース・テーブルの構造だけでなく、シーケンシャル含め、正確に同じであることが、インデックス付きベーステーブルは、正確に同じフィールドでなければなりません。
図6に示すように、メモリストレージエンジン
メモリストレージエンジンは、人々が名前で、彼は、メモリ・ストレージ・エンジンでデータを格納した知っているように簡単です。メモリストレージエンジンは、.frmファイルを上記ディスクにおける表構造情報を格納する、ディスク上のデータを格納しません。だから、一回またはホストMySQLCrashクラッシュ、メモリ構造の左側のテーブル。メモリサポートテーブルインデックス、およびサポート二つのフォーマットとハッシュインデックスBツリー。固定長でデータを保存するために従っメモリ空間にあるように、メモリに格納され、TEXTとBLOBフィールドの種類をサポートしていないため。ページレベルロックを達成するために、メモリ・ストレージ・エンジン。
図7に示すように、BDBストレージエンジン
BDBストレージエンジンは、BerkeleyDBのストレージエンジンと呼ばれ、InnoDBは同じ、またそれが自分の発展を達成するためにMySQLのストレージエンジンですが、SleepycatSoftwareによって提供され、もちろん、オープンソースのストレージエンジンは、トランザクションセーフをサポートしています。
8、FEDERATEDストレージエンジン
FEDERATEDストレージエンジンの機能が実装され、同様のオラクルDBLINKは、主にデータ上のMySQLサーバへのリモートアクセスインタフェースを提供するために使用されます。我々はMySQLのインストールをコンパイルするソースコードを使用する場合は、手動でFEDERATEDストレージエンジンを指定しなければなりませんMySQLはデフォルトのストレージエンジンを使用する余裕がないため、ジョブを可能にしました。
9、ARCHIVEストレージエンジン
アーカイブストレージエンジンは、主めったに少ない記憶空間によって期限切れストアにアクセスしていない履歴データのために使用されます。ARCHIVEテーブルは.frmファイルの構造によって定義されたインデックスをサポートしていない、データが圧縮されたファイルだけでなく、.ARMメタ情報ファイルを.ARZ。それらに格納されたデータの特殊な性質のために、ARCHIVEテーブルは、削除、変更操作をサポートしていません。
以下のために、唯一の挿入や、クエリ操作をサポートしています。行レベルのロックのためのロック機構。
10、BLACKHOLEストレージエンジン
BLACKHOLEストレージエンジンは、その名前が示すように、非常に興味深いストレージエンジンの機能である「ブラックホール」。「を/ dev / null」デバイス以下の我々のUNIXシステムのように、我々はすべての情報を書き込むかどうか、彼らはリターンになることはありません。
11、CSVストレージエンジン
CSVストレージエンジンは、実際に標準のCSVファイルを操作している、彼はインデックスをサポートしていません。主な目的は、私たちは時々、データベース内のデータによってレポートにファイルをエクスポートする必要があるかもしれないことであり、我々は最初のデータベースCVSにテーブルを作成できるようにCSVファイルには、より多くの標準フォーマットをサポートするためのソフトウェアがたくさんあるので、その後、テーブルに生成されたレポートの情報を送信し、あなたはCSVレポートファイルを取得することができます。
第二に、データベースエンジンの運転
図1に示すように、データベースエンジンのサポートを表示
エンジンを示し;
2、現在のデフォルトのデータベースエンジンを表示
「％storage_engine％」のような変数を表示。
図3は、データテーブル使用されるエンジンを視聴します
テーブルtable_nameを作成して表示し
4、テーブルストレージエンジンを変更します
ALTERテーブルtable_nameエンジン= ENGINE_NAME
S分離レベル
コミット読み（mysqlのデフォルトの分離レベル）
READ UNCOMMITTED
反復可能読み取り（Oracleのデフォルトの分離レベル）
Serializableを
第三に、データベースのインデックスを導入
インデックスの設立の長所と短所：
なぜそれのインデックスを作成しますか？
这是因为，创建索引可以大大提高系统的查询性能。
第一、通过创建唯一性索引，可以保证数据库表中每一行数据的唯一性。
第二、可以大大加快 数据的检索速度，这也是创建索引的最主要的原因。
第三、可以加速表和表之间的连接，特别是在实现数据的参考完整性方面特别有意义。
第四、在使用分组和排序子句进行数据检索时，同样可以显著减少查询中分组和排序的时间。
第五、通过使用索引，可以在查询的过程中，使用优化隐藏器，提高系统的性能。
也许会有人要问：增加索引有如此多的优点，为什么不对表中的每一个列创建一个索引呢？这种想法固然有其合理性，然而也有其片面性。虽然，索引有许多优点， 但是，为表中的每一个列都增加索引，是非常不明智的。 这是因为，增加索引也有许多不利的一个方面:
第一、创建索引和维护索引要耗费时间，这种时间随着数据量的增加而增加。
第二、索引需要占物理空间，除了数据表占数据空间之外，每一个索引还要占一定的物理空间。如果要建立聚簇索引，那么需要的空间就会更大。
第三、当对表中的数据进行增加、删除和修改的时候，索引也要动态的维护，这样就降低了数据的维护速度。
インデックスを作成するためのフィールドのどのような種類：
インデックスは、いくつかの列上のデータベーステーブルに基づくものです。インデックスを作成するときにそのため、あなたは慎重に列に索引を作成することができ考慮すべきである、あなたは、列に索引を作成することはできません。
一般来说，应该在这些列上创建索引，例如：
第一、在经常需要搜索的列上，可以加快搜索的速度；
第二、在作为主键的列上，强制该列的唯一性和组织表中数据的排列结构；
第三、在经常用在连接的列上，这些列主要是一些外键，可以加快连接的速度；
第四、在经常需要根据范围进行搜索的列上创建索引，因为索引已经排序，其指定的范围是连续的；
第五、在经常需要排序的列上创建索引，因为索引已经排序，这样查询可以利用索引的排序，加快排序查询时间；
第六、在经常使用在WHERE子句中的列上面创建索引，加快条件的判断速度。
建立索引，一般按照select的where条件来建立，比如： select的条件是where f1 and f2，那么如果我们在字段f1或字段f2上建立索引是没有用的，只有在字段f1和f2上同时建立索引才有用等。
フィールドはどのようなインデックスを作成するために適していません。
同様に、いくつかの列のインデックスを作成しないでください。一般的に、あなたは、これらの列のインデックスを作成しないでください次の特性があります。
まず、めったにクエリで使用されていないか、参照されているこれらの列のインデックスを作成しないでください。、これらの列はほとんど使用されないので、そう何の索引または索引が存在しないためであり、
クエリ速度を向上させるものではありません。インデックスの増加により逆に、が、上のメンテナンスを削減し、システムのスペース要件の速度が向上します。
第二に、列インデックスでそれらのいくつかのデータ値のために増加するべきではありません。これらの列の値は、性別列要員テーブルとして、小さいためです。
クエリの結果、テーブルのデータ行の大部分は、表の行に検索されるデータの大部分のデータ行の結果セット内。インデックスの増加、大幅に検索速度をスピードアップしませんでした。
第三に、インデックスを増加させるべきではない列のテキスト、画像およびビットデータタイプとして定義されたもののために。これは、これらの列のいずれか大きいまたは小さい値のデータ量。
パフォーマンスを変更すると、検索性能よりもはるかに大きい第四には、インデックスを作成しないでください。検索性能および性能改変が矛盾しているからです。場合、インデックスの増加は、検索性能を向上させるが、パフォーマンスの変更を減少させるであろう。指数の低下は、性能を改善し、検索性能を低下させるために修飾される場合。したがって、パフォーマンスを変更する場合は、インデックスを作成してはならない、検索性能よりもはるかに大きいです。
1、B-Treeインデックス
B-Treeインデックスは、定義により、すべてのインデックスは、ストアbalancetreeへのデータ構造によれば、全てのノードのインデックスデータがリーフノードであるノード。
2、フルテキストインデックス
フルテキストインデックスは、我々は長い間、フルテキストインデックス、ストレージ構造も彼のBツリー言うことです。主に私たちは、クエリのような非効率的な使用に必要な問題を解決するために。
第四に、インデックスを作成します
一般的な指標
で最も基本的な指標である、それはほとんどの場合に使用される任意のMyIASMデフォルトの制限のBTREEインデックスの種類だけでなく、Googleのインデックスを持っていません。
1接创建
CREATE INDEX [INDEX_NAME] ON [TABLE_NAME]（カラム（長さ））
インデックスの変更テーブル構造を追加します
ALTERテーブルtable_name ADD索引INDEX_NAME（カラム（長さ））
あなたは、テーブルを作成するときに2インデックスを指定
TABLEテスト（ID int型ではないnullをCREATE AUTO_INCREMENT、タイトルはvarchar（30）、PRIMARY KEY（ID）、INDEXのtitle_index（タイトル））
3ビューインデックス
[TABLE_NAME]でSHOW INDEX
[TABLE_NAME]でSHOW KEYS
インデックス削除する4
[talbe_name ON DROP INDEX [INDEX_NAMEを] ]
ALTER TABLE [table_nameの] DROP INDEX [index_nameの]
ALTER TABLE [table_nameの] DROP PRIMARY KEY
5一意のインデックス
と同様の通常の指標は、異なる：インデックス列の値は一意であるが、ヌル（ノート異なり、プライマリキー）を可能にしなければなりません。それは、複合インデックスがある場合は、列の値の組み合わせは一意であり、通常のインデックスと同様の方法を作成する必要があります。
6直接创建
CREATE UNIQUE INDEX [INDEX_NAME] ON [TABLE_NAME]（カラム（長さ））
インデックステーブルを変更する1.7を追加する唯一の方法
ALTER TABLE [テーブル名] ADD UNIQUE [INDEX_NAME]（カラム（長さ））
あなたがテーブルを作成するときに一意のインデックスを指定する8
TABLEテスト（ID int型ではないnullをCREATE AUTO_INCREMENT、タイトルはvarchar（30）、PRIMARY KEY（ID）、UNIQUEのtitle_index（タイトル（長さ）））
フルテキストインデックス（FULLTEXT）
のMySQLはバージョン3.23.23のみMyISAMテーブルのフルテキストインデックスおよびフルテキスト検索、FULLTEXTインデックスからサポートされています。彼らはCHAR、VARCHARまたはTEXT列から、CREATE TABLE文として使用することができ、作成の一部、またはその後の使用されていますALTER TABLEまたはCREATE INDEXを追加しました。
より大きなデータセットの場合は、FULLTEXTインデックステーブルずにデータを入力し、[インデックスを作成し、その速度はより速く、既存のFULLTEXTインデックス・データ入力の速度よりもです。しかし、大容量のデータテーブルのために覚えて、フルテキストインデックスは、ディスクスペースを消費するのに非常に時間のかかるやり方です。
3.1構築
TABLE_NAME ON FULLTEXT INDEXのINDEX_NAME（カラム（長さ））を作成
3.2、フルテキストインデックスの変更テーブル構造を追加
ALTER TABLE [table_nameの] ADDのFULLTEXTのINDEX_NAME
あなたがテーブルを作成するときに一意のインデックスを指定するには、3.3、
TABLEテスト（ID int型ではないヌルAUTO_INCREMENT、表題VARCHAR（30）、PRIMARY KEY（ID）、FULLTEXT title_index（タイトル））を作成
組み合わせ指数（左端接頭）
INDEXをCREATE [INDEX_NAME]の[テーブル名]（column_listを）
SQLクエリは通常、より多くの制限があり、一般的に使用それほどのMySQLの抽出の効率をさらにするために、我々は複合インデックスの設立を検討すべきです。例えば、タイトルおよびインデックス時間の組み合わせの確立のためのテーブル：ALTER TABLE物品ADD索引index_titme_time（タイトル（50）、時間（10））。インデックスのこのような組み合わせの確立は、実際には、二つのグループの等価は複合指数以下に設定しています。
-title、時間
-題名
なぜ、この時点複合インデックスもしませんでしたか？これは、インデックスMySQLの「最も左接頭辞」結果の組み合わせの結果であるためです。単純な理解は左から組み合わせの始まりに過ぎません。以下、いくつかのSQLのように限り、これらの二つの列がクエリに含まれていないとして、複合インデックスに使用されます。
図1に示すように、上記インデックスの使用
記事のWHREEタイトルSELECT * FROM = '测试' AND時間= 1234567890;
記事のWHREEタイトルSELECT * FROM = '测试';
図2に示すように、上記インデックスを使用せず
記事WHREE時間= 1234567890 SELECT * FROM。
五、MySQLのインデックスの最適化
上記のインデックスを使用することの利点について話しているが、インデックスのあまり使用は乱用につながります。そのため、インデックスもその欠点があります。それは、そのようなテーブルのINSERT、UPDATE、およびクエリの数よりもDELETE大きいと、テーブルの更新速度を下げるインデックスを放棄する一方、インデックスが大幅に、クエリの速度を増加したものの。あなたがテーブルを更新する場合、MySQLはデータを保存するだけでなく、インデックスファイルについて保存することだけではありませんので。インデックスファイルのインデックスは、ディスクスペースを占めています。通常、この問題はあまりにも深刻ではありませんが、インデックスを作成するためのさまざまな組み合わせに大きなテーブルにいる場合は、インデックスファイルはすぐに展開されます。インデックスは、あなたのMySQLテーブルが大量のデータを持っている場合、我々は最高のインデックスの設立を検討するために時間がかかる、またはクエリを最適化する必要があり、要因の効率を向上させます。
インデックスは、列にNULL値が含まれていない
列がNULL値がある限り、複合インデックスはNULL値が含まれている場合、この組成物のため、この列インデックスが有効ではありませんがあるので、インデックスに含まれません含まれている限り。私たちは、データベースの設計値のデフォルトフィールドをさせないようにNULLです。
短いインデックスを使用し
、プレフィックス長を指定する必要があり、可能な場合、シリアルインデックスのを。例えば、CHAR（255）列、前方の10または20文字の場合、唯一の多値、次いでないインデックス列全体が存在する場合。ショートインデックスは、検索を高速化し、ディスク容量とI / O操作保存することができないだけ。
インデックス列の並べ替え
インデックスが使用されている場合句はそう、その列によって順序がインデックスを使用しません唯一のインデックスを使用するMySQLのクエリ。だから、ケースをソートするために、デフォルトのデータベースのソート操作を使用していない要件を満たすことがあり、必要に応じて複数の列は、これらの列に最高の複合インデックスを作成するには、含まれて並べ替えしないようにしてください。
以下のようなステートメントの操作は
不使用でない場合は一般的にも問題がどのように使用する、オペレーションなどを使用することを奨励していません。「AAA％」のようなインデックスを使用するためにインデックスを使用することができません「のaaa％は％」のように。
カラム内の操作を実行しないでください
たとえば、：選択* YEAR（ユーザーから adddate）<2007は、 我々が変更できるように、全表スキャンのインデックス中に障害につながる各ライン、上の操作になります。select *ユーザーからどこadddate < '2007-01-01'
第六に、インデックスの概要
要約すると、MySQLは、次の演算子インデックスにのみ使用：<、<=、=、>、> =、で、間、時にはなど（場合_ワイルドカード文字％以上で開始しません）。理論的には、それぞれそれが本当にたくさんある場合を除き16インデックスが、データの量まで作成することができ、テーブル、またはインデックスの過度の使用はとても楽しいではありません
七、SQLの最適化
1.クエリの最適化は、最初の場所と順番に関与列でインデックス作成を検討すべきで、全表スキャンを回避しようとしてください。
2.フィールドは、where句で決定されたヌル値に避けるべきである、などのインデックスと全表スキャンを使用して、あきらめてエンジンが発生します。
numがnullであるここで、tからIDを選択します
あなたは何のNULL値は、このクエリが存在しないことを保証するために、テーブル内のNUM、num個の列にデフォルト値の0を設定することができます。
ここでNUM T = 0からIDを選択
図3は、そうでない場合は、エンジンがインデックスと全表スキャンを使用してあきらめます。、句！=または<>オペレータでは避けるべきです
4.接続条件を回避またはwhere句で使用されなければならない、それは以下のような指数と全表スキャンを使用して、あきらめてエンジンが発生します。
NUM = 10またはNUM = 20トンからIDを選択
クエリが実行できます。
TからIDを選択してここでNUM = 10
労働組合のすべて
TからIDを選択してここでNUM = 20
：5.inのような、そうでない場合は、全表スキャンにつながる、慎重にしていないで使用する必要があります
Tここで、NUMに（1,2,3）からIDを選択
連続値については、あなたが間に使用することはできません。
ここでNUM 1と3の間にTからIDを選択
6.次のクエリは、全表スキャンになります。
名前のように「％ABC％」トンからIDを選択します
7.エンジンがインデックスとフルテーブルスキャンを使用してあきらめてしまうwhere句、内のフィールドオペレーションの表現を避けるべきです。以下のような：
ここでNUM / 2 = 100トンからIDを選択
お読みください：
* 2 NUM = 100トンからIDを選択
8句エンジンがインデックスとフルテーブルスキャンを使用してあきらめてしまいますフィールドに機能動作に避けるべきです。以下のような：
TからIDを選択IDのABCで始まる（名前、1,3）=「abc'名をサブストリングここ
お読みください：
どこ名「ABC％」のようなトンからIDを選択します
9.左「=」where句内の関数、算術演算、またはその他の式を行わない、またはシステムが適切にインデックス付け動作しない場合があります。
10.インデックスは複合インデックスがある場合、あなたはシステムを確保するために、最初のフィールドにインデックスを使用する必要があり、インデックスフィールドを使用しての条件を条件として、インデックスを使用するので、
そうでなければ、インデックスは使用されません、とすべきである限り、フィールドの順序は順序インデックスと一致していることを可能ように。
11. Doが、そのような空のテーブル構造を作成する必要として、クエリは意味がありません書きません。
1 = 0 Tから#tをにCOL2、COL1を選択
このコードは、任意の結果セットを返しますが、システムリソースを消費し、これによって置き換える必要がありません。
テーブルに#tを作成し（...）
12.良い選択によって、多くの場合に存在置き換え：
（Bから選択NUM）で場合NUMからNUM選択
次の文で置き換えます。
（ここで、NUM = a.num Bから1を選択）が存在するところからNUMを選択
テーブルなど13インデックス列は、データの重複をたくさん持っているときに、すべてのインデックスが有効なクエリ、SQLクエリの最適化は、テーブル内のデータに基づいて行われているわけではありません、SQLクエリはインデックスを使用して行っていないことが、フィールドのセックスを持っている、男性、ほぼ半分のインデックスもセックスにクエリ効率には影響を建てていない場合でも、それぞれの女性の。
14.インデックスが挿入または更新が時々インデックスを再構築するように、対応するインデックスは確かに、選択の効率を改善するだけでなく、挿入および更新の効率を低下させることができ、可能ではない、インデックスは慎重に構築する方法を検討する必要に応じて場合であってもよいです。あまりにも多くのあなたは、必要に応じてインデックス列を構築するために使用頻度の低いのいくつかを検討する必要がある場合は、インデックス番号テーブルは、最高の半年以上ではありません。
数値フィールドの15メイク使用、数値情報を含むフィールドのみが接続とクエリのパフォーマンスが低下キャラクターデザイン、可能ではなく、ストレージコストを増加させた場合。一度だけ文字列内の各文字を比較することにより、クエリとの接続1を処理し、数値の比較のために、エンジンが十分にあるためです。
CHARではなくVARCHARとして16を使用する、小さな収納スペースのすべての可変長フィールドの最初のため、あなたは検索効率の比較的小さなフィールドで、クエリに続いて、ストレージスペースを節約することができますが明らかに高いです。
17. Doがより少ないとフィールドのいずれかを返さない、代わりに「*」のフィールドの特定のリストで、Tから選択*どこにも使用しません。
----------------
免責事項：この記事は、オリジナルの記事、CC 4.0 BY-SAの著作権契約書に従って、再現CSDNブロガー「小さな2は、データ」で、オリジナルのソースとのリンクを添付してくださいこの文。
オリジナルリンクします。https：//blog.csdn.net/Mirror_w/article/details/91354788
