大暴露！ MySQLデータベースインデックス
- silencement転載
- 2020-01-23 22:40:352216ブラウズ
1. 概要
インデックスは、ストレージ エンジンがレコードを迅速に検索するために使用するデータ構造です。データベース インデックスを合理的に使用すると、データベースへのアクセス パフォーマンスが大幅に向上します。次に、
MySql データベースのインデックスの種類と、より合理的で効率的なインデックス手法を作成する方法を主に紹介します。
注: ここでの主な焦点は、InnoDB ストレージ エンジンの B ツリー インデックス データ構造です。
2. インデックスの利点
が大幅に削減されます。 サーバーがスキャンする必要があるデータの量が減り、それによってデータの取得速度が向上します。
#サーバーがソートや一時テーブルを回避できるようにします。 /O をシーケンシャル I/O に変換します##3. インデックスの作成
3.1. 主キー インデックスALTER TABLE 'table_name' ADD PRIMARY KEY 'index_name' ('column');
3.2. 一意のインデックス
ALTER TABLE 'table_name' ADD UNIQUE 'index_name' ('column');
3.3、通常のインデックス
ALTER TABLE 'table_name' ADD INDEX 'index_name' ('column');
3.4、全文インデックス
ALTER TABLE 'table_name' ADD FULLTEXT 'index_name' ('column');
3.5、結合インデックス
ALTER TABLE 'table_name' ADD INDEX 'index_name' ('column1', 'column2', ...);
4.B ツリー インデックス ルール
テスト ユーザー テーブルの作成DROP TABLE IF EXISTS user_test;CREATE TABLE user_test( id int AUTO_INCREMENT PRIMARY KEY,
user_name varchar(30) NOT NULL,
sex bit(1) NOT NULL DEFAULT b'1',
city varchar(50) NOT NULL,
age int NOT NULL) ENGINE=InnoDB DEFAULT CHARSET=utf8; 結合インデックスの作成: ALTER TABLE user_test ADD INDEX idx_user(user_name, city, age);
4.1. 有効なインデックスを使用したクエリ
4.1 .1. 完全な値の一致
完全な値の一致とは、インデックス内のすべての列との一致を指します。例: 上記で作成したインデックスを例として、where 条件の後に次のことができます。 条件付きデータと同時にクエリ (user_name、city、age) を実行します。
SELECT * FROM user_test WHERE user_name = 'feinik' AND age = 26 AND city = '广州';
4.1.2. 左端のプレフィックスとのマッチング
左端のプレフィックスとのマッチングは、最初に左端のインデックス列とのマッチングを意味します 例: 上記で作成したインデックスはクエリ条件に使用できます: (user_name), (user_name, city), (user_name, city, age)
注: 左端のプレフィックス クエリ条件を満たす順序は、(city, user_name) などのインデックス列の順序とは関係ありません。 , (age, city, user_name)
4.1.3. 一致する列の接頭辞
##
SELECT * FROM user_test WHERE user_name LIKE 'feinik%';
4.1.4 で始まるすべてのユーザーを照会します。一致範囲の値
例: ユーザー名が feinik で始まるすべてのユーザーをクエリすると、インデックスの最初の列がここで使用されます
SELECT * FROM user_test WHERE user_name LIKE 'feinik%';
4.2. インデックスの制限
SELECT * FROM user_test WHERE city = '广州';または
SELECT * FROM user_test WHERE age= 26;または
SELECT * FROM user_test WHERE city = '广州' AND age = '26';などのインデックス クエリは使用できません。
2. where のクエリ条件が左端のインデックス列であっても、ユーザー名が feinik
SELECT * FROM user_test WHERE user_name like '%feinik';3 で終わるユーザーに対してインデックスを使用してクエリを実行することはできません。 where クエリ条件の特定の列については、
SELECT * FROM user_test WHERE user_name = 'feinik' AND city LIKE '广州%' AND age = 26;
5 のようなインデックス最適化を使用して右側のすべての列をクエリすることはできません。
SELECT * FROM user_test WHERE user_name = concat(user_name, 'fei');
5.2. 接頭辞インデックス
非常に長い文字列のインデックスを作成する必要がある場合があり、これによりインデックスの記憶領域が増加し、インデックスを減らす 効率を高めるために、1 つの戦略はハッシュ インデックスを使用することであり、もう 1 つはプレフィックス インデックスを使用することです。プレフィックス インデックスは、文字列の最初の n 文字をインデックスとして選択します。これにより、インデックス スペースが大幅に節約され、インデックス作成が向上します。効率。
5.2.1. プレフィックス インデックスの選択性
プレフィックス インデックスは、高い選択性を確保するのに十分な長さのプレフィックスを選択する必要がありますが、同時に長すぎてもいけません。 、次の方法で適切なプレフィックス インデックスの選択長の値を計算できます:
SELECT COUNT(DISTINCT index_column)/COUNT(*) FROM table_name; -- index_column代表要添加前缀索引的列注: 上記の方法で計算されます。プレフィックス インデックスの選択率。比率が高いほど、インデックスの効率が高くなります。
(2)
SELECTCOUNT(DISTINCT LEFT(index_column,1))/COUNT(*),COUNT(DISTINCT LEFT(index_column,2))/COUNT(*),COUNT(DISTINCT LEFT(index_column,3))/COUNT(*) ...FROM table_name;
注: ステップバイステップで見つけてください。上記の文を通じて、(1) のプレフィックス インデックスに最も近い選択率を取得し、対応する文字インターセプト長を使用してプレフィックス インデックスを作成できます
#5.2.2. プレフィックスの作成index
ALTER TABLE table_name ADD INDEX index_name (index_column(length));5.2.3. プレフィックス インデックスの使用に関する注意事項
プレフィックス インデックスは、インデックスを小さくして高速にする効果的な方法ですが、 MySql は、ORDER BY および GROUP BY にプレフィックス インデックスを使用したり、カバレッジ
スキャンにプレフィックス インデックスを使用したりすることはできません。5.3、选择合适的索引列顺序
在组合索引的创建中索引列的顺序非常重要，正确的索引顺序依赖于使用该索引的查询方式，对于组合索引的索引顺序可以通过经验
法则来帮助我们完成：将选择性最高的列放到索引最前列，该法则与前缀索引的选择性方法一致，但并不是说所有的组合索引的顺序
都使用该法则就能确定，还需要根据具体的查询场景来确定具体的索引顺序。
5.4 聚集索引与非聚集索引
1、聚集索引
聚集索引决定数据在物理磁盘上的物理排序，一个表只能有一个聚集索引，如果定义了主键，那么InnoDB会通过主键来聚集数据，如
果没有定义主键，InnoDB会选择一个唯一的非空索引代替，如果没有唯一的非空索引，InnoDB会隐式定义一个主键来作为聚集索
引。
聚集索引可以很大程度的提高访问速度，因为聚集索引将索引和行数据保存在了同一个B-Tree中，所以找到了索引也就相应的找到了
对应的行数据，但在使用聚集索引的时候需注意避免随机的聚集索引（一般指主键值不连续，且分布范围不均匀），如使用UUID来作
为聚集索引性能会很差，因为UUID值的不连续会导致增加很多的索引碎片和随机I/O，最终导致查询的性能急剧下降。
2、非聚集索引
与聚集索引不同的是非聚集索引并不决定数据在磁盘上的物理排序，且在B-Tree中包含索引但不包含行数据，行数据只是通过保存在
B-Tree中的索引对应的指针来指向行数据，如：上面在（user_name，city, age）上建立的索引就是非聚集索引。
5.5、覆盖索引
如果一个索引（如：组合索引）中包含所有要查询的字段的值，那么就称之为覆盖索引，如：
SELECT user_name, city, age FROM user_test WHERE user_name = 'feinik' AND age > 25;
因为要查询的字段（user_name, city, age）都包含在组合索引的索引列中，所以就使用了覆盖索引查询，查看是否使用了覆盖索引可
以通过执行计划中的Extra中的值为Using index则证明使用了覆盖索引，覆盖索引可以极大的提高访问性能。
5.6、如何使用索引来排序
在排序操作中如果能使用到索引来排序，那么可以极大的提高排序的速度，要使用索引来排序需要满足以下两点即可。
1、ORDER BY子句后的列顺序要与组合索引的列顺序一致，且所有排序列的排序方向（正序/倒序）需一致
2、所查询的字段值需要包含在索引列中，及满足覆盖索引
通过例子来具体分析
在user_test表上创建一个组合索引
ALTER TABLE user_test ADD INDEX index_user(user_name , city , age);
可以使用到索引排序的案例
1、SELECT user_name, city, age FROM user_test ORDER BY user_name;
2、SELECT user_name, city, age FROM user_test ORDER BY user_name, city;
3、SELECT user_name, city, age FROM user_test ORDER BY user_name DESC, city DESC;
4、SELECT user_name, city, age FROM user_test WHERE user_name = 'feinik' ORDER BY city;
注：第4点比较特殊一点，如果where查询条件为索引列的第一列，且为常量条件，那么也可以使用到索引
无法使用索引排序的案例
1、sex不在索引列中
SELECT user_name, city, age FROM user_test ORDER BY user_name, sex;
2、排序列的方向不一致
SELECT user_name, city, age FROM user_test ORDER BY user_name ASC, city DESC;
3、所要查询的字段列sex没有包含在索引列中
SELECT user_name, city, age, sex FROM user_test ORDER BY user_name;
4、where查询条件后的user_name为范围查询，所以无法使用到索引的其他列
SELECT user_name, city, age FROM user_test WHERE user_name LIKE 'feinik%' ORDER BY city;
5、多表连接查询时，只有当ORDER BY后的排序字段都是第一个表中的索引列（需要满足以上索引排序的两个规则）时，方可使用索
引排序。如：再创建一个用户的扩展表user_test_ext，并建立uid的索引。
DROP TABLE IF EXISTS user_test_ext;CREATE TABLE user_test_ext( id int AUTO_INCREMENT PRIMARY KEY,
uid int NOT NULL, u_password VARCHAR(64) NOT NULL) ENGINE=InnoDB DEFAULT CHARSET=utf8;ALTER TABLE user_test_ext ADD INDEX index_user_ext(uid);
走索引排序
SELECT user_name, city, age FROM user_test u LEFT JOIN user_test_ext ue ON u.id = ue.uid ORDER BY u.user_name;
不走索引排序
SELECT user_name, city, age FROM user_test u LEFT JOIN user_test_ext ue ON u.id = ue.uid ORDER BY ue.uid;
6、总结
本文主要讲了B+Tree树结构的索引规则，不同索引的创建，以及如何正确的创建出高效的索引技巧来尽可能的提高查询速度，当然了
关于索引的使用技巧不单单只有这些，关于索引的更多技巧还需平时不断的积累相关经验。
以上が大暴露！ MySQLデータベースインデックスの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。