（InnoDBのハッシュインデックスを使用しない、唯一Bツリーインデックス）：使用のハッシュインデックスの理由にInnoDBストレージエンジン
-- 创建资源表 CREATE TABLE `my_resource` ( `id` int(32) NOT NULL AUTO_INCREMENT COMMENT '主键', `resource_name` varchar(255) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL COMMENT '资源名称', `type` int(2) NOT NULL DEFAULT 0 COMMENT '资源类型 0其他 1视频 2文件', `url` varchar(255) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL COMMENT '资源地址', PRIMARY KEY (`id`) USING BTREE ) ENGINE = InnoDB AUTO_INCREMENT = 1 CHARACTER SET = utf8 COLLATE = utf8_general_ci ROW_FORMAT = Dynamic; -- 在url字段上创建索引，用于检索 create index idx_url on my_resource (url asc); -- 新增数据 insert into my_resource (resource_name,type,url) values('庆余年_1',1,'https://v.qq.com/x/cover/rjae621myqca41h/Cz4BRyhUY3.html'); insert into my_resource (resource_name,type,url) values('庆余年_2',1,'https://v.qq.com/x/cover/rjae621myqca41h/tlTt4CiBc1.html'); insert into my_resource (resource_name,type,url) values('庆余年_3',1,'https://v.qq.com/x/cover/rjae621myqca41h/QdTUsz40Cb.html'); insert into my_resource (resource_name,type,url) values('庆余年_4',1,'https://v.qq.com/x/cover/rjae621myqca41h/dFdlXmOd9n.html'); insert into my_resource (resource_name,type,url) values('庆余年_5',1,'https://v.qq.com/x/cover/rjae621myqca41h/TsvFR6b8wg.html'); insert into my_resource (resource_name,type,url) values('庆余年_6',1,'https://v.qq.com/x/cover/rjae621myqca41h/YgWeaPrYpc.html'); -- 查询执行计划 explain select url from my_resource order by url ;
実行プラン、インデックスidx_urlに使用されるキーから見ることができるが、インデックスを最適化しながら、インデックスの長さは、767で、インデックスの長さは、できるだけ短いです
理由：インデックスの長さは直接欠失は変化の速度に影響を与える、インデックスファイルのサイズに影響を及ぼし、そして間接的にクエリ速度（複数のためのメモリ）に影響を与える。
列の値は、インデックスを作成するセクションうち右切断左から
1：短い切断型を、繰り返しの度より高い、分化の程度も小さく、悪い効果指標
2：カットが長くなり、低い繰り返し、分化度の度合いが高いほど、より良い効果が、より大きな衝撃-変化欠失遅く、およびインタークエリ速度の影響。
したがって、+長識別の両方に、バランスを達成します。
解決策：異なる長さを傍受し、差別のためのテスト
-- 截取url字段长度，从1开始截取，计算字符前缀没有重复的字符占全部数据的比例 select count(distinct right(url,15))/count(*) from my_resource;
1の割合が最も区別が最適です
カスタム擬似ハッシュインデックス:(コア）
前提
考慮すべきデータの種類には、当然それは比較数値に、比較文字列からレコードのフィールドを比較することではない、と思いますか？
これは、最適化の方向です。その基礎となるデータが01010であることを、単に比較してどうすることができます0101のデジタル同等に変換されますが、文字になるために必要なコンピュータでは、文字は数字ここで0101、という点では、文字コード表に対応がどこへ行くという番号を見つける必要がありますマルチステップの操作をご覧ください。一方の文字が数よりもはるかに大きなスペースを占めている上、ページがデータ・ページを読み込むよりになります。この未満にアイテム番号のエントリに対応します。この方向によると、カスタムインデックスのハッシュを使用しようと、HASH共通の機能は、MD5、あるCRC32、SHA1とCRC32ハッシュ後のように、数値のみ。
擬似ハッシュインデックスの作成：
1、ハッシュ後の表リガフィールドの値、およびフィールドインデックスプラス（InnoDBのBツリーインデックス）に記録されます。
-- 添加 url的伪hash索引值存储字段 bigint类型 ALTER TABLE my_resource ADD COLUMN `url_crc32` bigint(10) NOT NULL COMMENT 'url的伪hash索引值存储字段' AFTER `url`; -- 创建该字段索引 create index idx_url_crc32 on my_resource (url_crc32 asc); --删除 url的索引 drop index idx_url on my_resource;2、トリガーを作成
delimiter $$ CREATE TRIGGER my_resource_url_crc32_trigger BEFORE INSERT ON my_resource FOR EACH ROW BEGIN SET NEW.url_crc32 = crc32(NEW.url);-- url通过crc32计算后将结果赋值给url_crc END; $$ delimiter ;3、新しいデータ、ビュー結果
4、実行計画を表示
explain select url_crc32 from my_resource order by url_crc32;key_lenに長さはそうノックの後、8です
図4に示すように、ハッシュインデックス欠点
1）ハッシュの比較処理範囲のみならず、等価比較プロセス。
2）ハッシュ、ソート、結果がランダムに分布しているうちハッシュを行うことはできません。（この場合、単に効果を確認するために、ソートいたしません）
3）ハッシュインデックス部は、指標A（10）のように、サポートされていないがサポートされていません。
4）ハッシュインデックスはカバーできません
5）ハッシュ衝突、衝突は、衝突を処理するコストが比較的高い、より強力でした。
