MySQL 索引及查询优化

Jun 07, 2016 pm 04:07 PM
mysqlクエリの最適化 mysqlインデックス

索引的类型 : Oslash; 普通索引 这是最基本的索引类型,没唯一性之类的限制。 Oslash; 唯一性索引 和普通索引基本相同,但

索引的类型 :

Ø 普通索引  这是最基本的索引类型,没唯一性之类的限制。

Ø 唯一性索引 和普通索引基本相同,但所有的索引列值保持唯一性。

Ø 主键索引  主键是一种唯一索引,但必须指定为”PRIMARY KEY”。

Ø 全文索引  MYSQL从3.23.23开始支持全文索引和全文检索。在MYSQL中,全文索引的索引类型为FULLTEXT。全文索引可以在VARCHAR或者TEXT类型的列上创建。

大多数MySQL索引(PRIMARY KEY、UNIQUE、INDEX和FULLTEXT)使用B树中存储。

空间列类型的索引使用R-树,MEMORY表支持hash索引。

单列索引和多列索引(复合索引):

索引可以是单列索引,也可以是多列索引。对相关的列使用索引是提高SELECT操作性能的最佳途径之一。

MySQL可以为多个列创建索引。一个索引可以包括15个列。对于某些列类型,可以索引列的左前缀,列的顺序非常重要。

多列索引可以视为包含通过连接索引列的值而创建的值的排序的数组。一般来说,即使是限制最严格的单列索引,它的限制能力也远远低于多列索引。

多列索引有一个特点,即最左前缀(Leftmost Prefixing)。假如有一个多列索引为key(firstname lastname age),当搜索条件是以下各种列的组合和顺序时,MySQL将使用该多列索引:

firstname,lastname,age

firstname,lastname

firstname

也就是说,相当于还建立了key(firstname lastname)和key(firstname)。

索引主要用于下面的操作:

Ø 快速找出匹配一个WHERE子句的行。

Ø 删除行。当执行联接时,从其它表检索行。

Ø 对具体有索引的列key_col找出MAX()或MIN()值。由预处理器进行优化,,检查是否对索引中在key_col之前发生所有关键字元素使用了WHERE key_part_# = constant。在这种情况下,MySQL为每个MIN()或MAX()表达式执行一次关键字查找,并用常数替换它。如果所有表达式替换为常量,查询立即返回。例如:

SELECT MIN(key2), MAX (key2)  FROM tb WHERE key1=10;

Ø 如果对一个可用关键字的最左面的前缀进行了排序或分组(例如,ORDER BY key_part_1,key_part_2),排序或分组一个表。如果所有关键字元素后面有DESC,关键字以倒序被读取。

Ø 在一些情况中,可以对一个查询进行优化以便不用查询数据行即可以检索值。如果查询只使用来自某个表的数字型并且构成某些关键字的最左面前缀的列,为了更快,可以从索引树检索出值。

SELECT key_part3 FROM tb WHERE key_part1=1;

有时MySQL不使用索引,即使有可用的索引。一种情形是当优化器估计到使用索引将需要MySQL访问表中的大部分行时。(在这种情况下,表扫描可能会更快些)。然而,如果此类查询使用LIMIT只搜索部分行,MySQL则使用索引,因为它可以更快地找到几行并在结果中返回。例如:

MySQL 索引及查询优化

合理的建立索引的建议:

(1)  越小的数据类型通常更好:越小的数据类型通常在磁盘、内存和CPU缓存中都需要更少的空间,处理起来更快。

(2)  简单的数据类型更好:整型数据比起字符,处理开销更小,因为字符串的比较更复杂。在MySQL中,应该用内置的日期和时间数据类型,而不是用字符串来存储时间;以及用整型数据类型存储IP地址。

(3)  尽量避免NULL:应该指定列为NOT NULL,除非你想存储NULL。在MySQL中,含有空值的列很难进行查询优化,因为它们使得索引、索引的统计信息以及比较运算更加复杂。你应该用0、一个特殊的值或者一个空串代替空值

这部分是关于索引和写SQL语句时应当注意的一些琐碎建议和注意点 :

1. 当结果集只有一行数据时使用LIMIT 1

2. 避免SELECT *,始终指定你需要的列

 从表中读取越多的数据,查询会变得更慢。他增加了磁盘需要操作的时间,还是在数据库服务器与WEB服务器是独立分开的情况下。你将会经历非常漫长的网络延迟,仅仅是因为数据不必要的在服务器之间传输。

3. 使用连接(JOIN)来代替子查询(Sub-Queries)

    连接(JOIN).. 之所以更有效率一些,是因为MySQL不需要在内存中创建临时表来完成这个逻辑上的需要两个步骤的查询工作。

4. 使用ENUM、CHAR 而不是VARCHAR,使用合理的字段属性长度

5. 尽可能的使用NOT NULL

6. 固定长度的表会更快

7. 拆分大的DELETE 或INSERT 语句

8. 查询的列越小越快

Where条件 :

在查询中,WHERE条件也是一个比较重要的因素,尽量少并且是合理的where条件是很重要的,尽量在多个条件的时候,把会提取尽量少数据量的条件放在前面,减少后一个where条件的查询时间。

有些where条件会导致索引无效:

Ø where子句的查询条件里有!=,MySQL将无法使用索引。

Ø where子句使用了Mysql函数的时候,索引将无效,比如:select * from tb where left(name, 4) = ‘xxx’

Ø 使用LIKE进行搜索匹配的时候,这样索引是有效的:select * from tbl1 where name like ‘xxx%’,而like ‘%xxx%’ 时索引无效

# The ideal of life is for ideal life! #

本文永久更新链接地址

このウェブサイトの声明
この記事の内容はネチズンが自主的に寄稿したものであり、著作権は原著者に帰属します。このサイトは、それに相当する法的責任を負いません。盗作または侵害の疑いのあるコンテンツを見つけた場合は、admin@php.cn までご連絡ください。

ホットAIツール

Undresser.AI Undress

Undresser.AI Undress

リアルなヌード写真を作成する AI 搭載アプリ

AI Clothes Remover

AI Clothes Remover

写真から衣服を削除するオンライン AI ツール。

Undress AI Tool

Undress AI Tool

脱衣画像を無料で

Clothoff.io

Clothoff.io

AI衣類リムーバー

AI Hentai Generator

AI Hentai Generator

AIヘンタイを無料で生成します。

ホットツール

メモ帳++7.3.1

メモ帳++7.3.1

使いやすく無料のコードエディター

SublimeText3 中国語版

SublimeText3 中国語版

中国語版、とても使いやすい

ゼンドスタジオ 13.0.1

ゼンドスタジオ 13.0.1

強力な PHP 統合開発環境

ドリームウィーバー CS6

ドリームウィーバー CS6

ビジュアル Web 開発ツール

SublimeText3 Mac版

SublimeText3 Mac版

神レベルのコード編集ソフト(SublimeText3)

mysql インデックス障害のいくつかの状況 mysql インデックス障害のいくつかの状況 Feb 21, 2024 pm 04:23 PM

一般的な状況: 1. 関数または演算を使用する; 2. 暗黙的な型変換; 3. 等しくない (!= または <>) を使用する; 4. LIKE 演算子を使用し、ワイルドカードで始める; 5. OR 条件; 6. NULL値、7. 低いインデックス選択性、8. 複合インデックスの左端の接頭辞の原則、9. オプティマイザーの決定、10. FORCE INDEX および IGNORE INDEX。

どのような状況で mysql インデックスが失敗しますか? どのような状況で mysql インデックスが失敗しますか? Aug 09, 2023 pm 03:38 PM

MySQL インデックスは、インデックス カラムを使用せずにクエリを実行した場合、データ型が一致していない場合、プレフィックス インデックスが不適切に使用された場合、クエリに関数や式を使用した場合、インデックス カラムの順序が正しくない場合、データ更新が頻繁に行われる場合、インデックスが多すぎるか少なすぎる場合に失敗します。 1. クエリにはインデックス列を使用しないでください。この状況を回避するには、クエリで適切なインデックス列を使用する必要があります。2. データ型が一致しません。テーブル構造を設計するときは、インデックス列がクエリの構造と一致していることを確認する必要があります。クエリのデータ型; 3. 、プレフィックス インデックスの不適切な使用、プレフィックス インデックスを使用できます。

MySQL インデックスの左プレフィックス マッチング ルール MySQL インデックスの左プレフィックス マッチング ルール Feb 24, 2024 am 10:42 AM

MySQL インデックスの左端の原則とコード例 MySQL では、インデックス作成はクエリ効率を向上させる重要な手段の 1 つです。その中でも、インデックスの左端の原則は、インデックスを使用してクエリを最適化するときに従う必要がある重要な原則です。この記事では、MySQL インデックスの左端の原則を紹介し、具体的なコード例をいくつか示します。 1. インデクス左端原則の原則 インデクス左端原則とは、インデクスにおいて問合せ条件が複数の列で構成される場合、問合せ条件を完全に満たすにはインデクスの左端の列のみを問合せできることを意味します。

mysqlインデックスの分類は何ですか? mysqlインデックスの分類は何ですか? Apr 22, 2024 pm 07:12 PM

MySQL インデックスは次のタイプに分類されます: 1. 通常のインデックス: 値、範囲、またはプレフィックスに一致します。 2. 固有のインデックス: 値が一意であることを確認します。 3. 主キー インデックス: 主キー列の一意のインデックス。キー インデックス: 別のテーブルの主キーを指します。 5. フルテキスト インデックス: 全文検索。 7. 空間インデックス: 地理空間検索。列。

さまざまなタイプのMySQLインデックス(Bツリー、ハッシュ、フルテキスト、空間)を説明します。 さまざまなタイプのMySQLインデックス(Bツリー、ハッシュ、フルテキスト、空間)を説明します。 Apr 02, 2025 pm 07:05 PM

MySQLは、Bツリー、ハッシュ、フルテキスト、および空間の4つのインデックスタイプをサポートしています。 1.B-Treeインデックスは、等しい値検索、範囲クエリ、ソートに適しています。 2。ハッシュインデックスは、等しい値検索に適していますが、範囲のクエリとソートをサポートしていません。 3.フルテキストインデックスは、フルテキスト検索に使用され、大量のテキストデータの処理に適しています。 4.空間インデックスは、地理空間データクエリに使用され、GISアプリケーションに適しています。

PHP および MySQL インデックスのデータ更新とインデックス保守のためのパフォーマンス最適化戦略と、それらがパフォーマンスに及ぼす影響 PHP および MySQL インデックスのデータ更新とインデックス保守のためのパフォーマンス最適化戦略と、それらがパフォーマンスに及ぼす影響 Oct 15, 2023 pm 12:15 PM

PHP および MySQL インデックスのデータ更新とインデックス保守のためのパフォーマンス最適化戦略と、それらがパフォーマンスに与える影響 概要: PHP および MySQL の開発において、インデックスはデータベース クエリのパフォーマンスを最適化するための重要なツールです。この記事では、インデックスの基本原則と使用法を紹介し、データの更新とメンテナンスに対するインデックスのパフォーマンスへの影響を検討します。同時に、この記事では、開発者がインデックスをよりよく理解して適用できるように、いくつかのパフォーマンス最適化戦略と具体的なコード例も提供します。インデックスの基本原則と使用法 MySQL では、インデックスは特別な番号です。

MySQL インデックスを合理的に使用し、データベースのパフォーマンスを最適化するにはどうすればよいでしょうか?技術系の学生が知っておくべき設計プロトコル! MySQL インデックスを合理的に使用し、データベースのパフォーマンスを最適化するにはどうすればよいでしょうか?技術系の学生が知っておくべき設計プロトコル! Sep 10, 2023 pm 03:16 PM

MySQL インデックスを合理的に使用し、データベースのパフォーマンスを最適化するにはどうすればよいでしょうか?技術系の学生が知っておくべき設計プロトコル!はじめに: 今日のインターネット時代では、データ量は増加し続けており、データベースのパフォーマンスの最適化が非常に重要なテーマになっています。最も人気のあるリレーショナル データベースの 1 つである MySQL では、データベースのパフォーマンスを向上させるためにインデックスを合理的に使用することが重要です。この記事では、MySQL インデックスを合理的に使用し、データベースのパフォーマンスを最適化し、技術系の学生向けにいくつかの設計ルールを提供する方法を紹介します。 1. なぜインデックスを使用するのでしょうか?インデックスは、以下を使用するデータ構造です。

MySQLでインデックスを使用するよりも、フルテーブルスキャンがいつ速くなるのでしょうか? MySQLでインデックスを使用するよりも、フルテーブルスキャンがいつ速くなるのでしょうか? Apr 09, 2025 am 12:05 AM

完全なテーブルスキャンは、MySQLでインデックスを使用するよりも速い場合があります。特定のケースには以下が含まれます。1)データボリュームは小さい。 2)クエリが大量のデータを返すとき。 3)インデックス列が高度に選択的でない場合。 4)複雑なクエリの場合。クエリプランを分析し、インデックスを最適化し、オーバーインデックスを回避し、テーブルを定期的にメンテナンスすることにより、実際のアプリケーションで最良の選択をすることができます。

See all articles