Mysqlはインデックスに頼れるけど、バイトに頼るしかない…。
- coldplay.xixi転載
- 2020-10-26 17:43:202103ブラウズ
#mysql 教程 リストの関連インデックス。
一、インデックスデータウェア構造
面试の時候肯定会问これ一问题、mysql は何ですか?インデックス呢? b'?hash などの他のインデックスは選択しないでください。 #ハッシュ インデックスの话、ハッシュは应一值的であるため、范围蟥询をサポートしていません、没法范围蟥询二分木の場合、左のサブツリーがルートノードよりも小さく、右のサブツリーよりも小さいことが特徴です。ルート ノードの値に問題がある場合、リンク リストに縮退する可能性があります。つまり、ツリーは分岐せず、ツリーは常に左または右に移動するため、半分で検索することはできません。 IO の数を減らすために使用します。範囲クエリはサポートされていません。範囲クエリを使用する場合は、毎回ルートからたどる必要があります。また、ツリーが高すぎます。ツリーが高くなるほど、IO 操作の頻度が高くなり、無駄が生じます。 resource.
バイナリ ツリー のバランスをとった場合、バイナリ ツリーは存在しません。これには、リンク リストに退化するという欠点があります。 、その左右の子ノードの差は最大 1 レベルですが、範囲検索はサポートされていないため、バイナリ ツリーの問題と同じです。
B ツリー, バイナリ ツリーと比較すると、ツリーは非常に短く太く、IO 操作が削減されます。マルチフォーク ツリーです。各ノードには対応するデータ行が格納されます。ただし、この行のデータが増加すると、列が増加し続けるため、このページに格納されるノードの数は減少します。これは、占有スペースが増加し続け、ツリーがますます高くなり、IO 操作の数が増加するためです。同時に、範囲検索はサポートされていません。同じサイズのスペースに多くのノード データを保存できる方が良いため、次の b-tree
b-tree があります。 非リーフ ノードはデータの行全体ではなくインデックス データのみを格納しますが、リーフ ノードは冗長な冗長な非リーフ ノードであり、リーフ ノードは二重リンク リストにもリンクされているため、順次検索が容易になります。 b B ツリーと比較して、ツリーはより分厚く、ディスク IO 時間が少なくなります
2. mysql のインデックス タイプ
クラスター化インデックスと非クラスター化インデックス ##単純にできます。として理解される クラスター化インデックスは主キー インデックスであり、非クラスター化インデックスは通常のインデックスです。本質的な違いは次のとおりです。
クラスター化インデックスリーフ ノードにはデータの行全体が格納されます
innodb は主キーを介してクラスター化インデックスを実装します。主キーがない場合は、実装する空でない一意のインデックスが選択されます。主キーがない場合は、暗黙的に生成されます。クラスター化インデックスを実装するための主キー
##非クラスター化インデックスには、インデックス値と主キー値が格納されます
##3. インデックスについて sql
##通常のインデックス テーブルには複数の通常のインデックスが存在し、任意のフィールドにインデックスを確立できます。通常作成するインデックスのほとんどは通常のインデックスです
- #結合インデックス
複数のフィールドを組み合わせて作成されるインデックス - 一意のインデックス
##主キー インデックスビジネスで一意のインデックスを確立するのに適しているのはこのフィールドだけです。テーブルには複数の一意のインデックスが存在する可能性があります - と一意 インデックスと同じように、主キー インデックスも一意です。違いは、テーブルには主キー インデックスが 1 つしか持てないことです。
主キー インデックスの作成
ALTER TABLE test add PRIMARY KEY (id)复制代码一意のインデックスの作成ALTER TABLE test add UNIQUE idx_id_card(id_card)复制代码通常のインデックスを作成します
ALTER TABLE test add INDEX idx_name(name)复制代码結合インデックスを作成します
ALTER TABLE test add INDEX idx_age_name(age,name)复制代码インデックス名を変更します: 最初に削除してから追加します
インデックスを削除します (2 つの方法)
ALTER TABLE test DROP INDEX idx_id_cardDROP INDEX idx_id_card on test --删除主键索引DROP PRIMARY key on test ALTER TABLE test DROP PRIMARY key复制代码テーブル内のインデックスを表示
SHOW INDEX FROM test复制代码分析インデックス
EXPLAIN SELECT * from test WHERE name = "xhJaver"复制代码我们先给name字段添加一个索引,索引名字叫做idx_name
ALTER TABLE test add INDEX idx_name(name)复制代码查看test表中的索引
SHOW INDEX FROM test复制代码其中的属性
table: 表名
Non_unique: 能重复的话为1，不能重复的话为0，我们主键的那里是0，而name那里是1，因为name可以重复，而主键不能重复
Key_name: 索引名称
Seq_in_index:索引中列的顺序
Column_name:列名称
Collation:列以什么方式存储的，A升序，null无序
Cardinality:数目越大，则使用该索引的可能性越大
Sub_part:如果列只是部分的编入索引，则被编入索引的字符数目，如果整列被编入索引，则为null
Packed：关键字是否被压缩，null表示没有被压缩
Null:如果该列含有null,则为yes,如果没有null,则为no
Index_type:索引数据结构
Comment:多种评注
四、回表查询
select * from test where name = "xhJaver"复制代码假如说我们name字段建立了索引，然后当我们运行这一句sql语句的时候，因为建立的是普通索引，所以我们的b+树的叶子节点存储的数据是id，我们会找到name是xhJaver的这条记录的id，再根据这个id,去主键索引的那棵b+树去查询，查询到叶子节点时即查询出这条记录，可见这个过程中，我们从一棵树跑到了另一棵树继续查，这样就叫做“回表查询”，那有没有办法只查一棵树就可以查询出结果呢？
五、覆盖索引
办法当然是有的啦，那就是覆盖索引，我们注意到，刚才这个sql语句时查询出来了所有元素，假如说我们这样写的话
select address from test where name = "xhJaver"复制代码假如说我们建立的索引是（name,address）那么这个时候（name,address）这棵b+树的叶子节点存储的数据就包括address了，此时就不需要再根据name = "xhJaver"的id去第二棵树查了，这样就避免了回表查询
六、最左匹配原则
假如说现在我们写一个这样的sql语句
select * from test where name = "xhJaver" and age =23 and address="京东"复制代码并且我们建立的索引是（name,address,age）这样是会用到（name,address,age）索引的，可是如果要这样写的话
select * from test where name = "xhJaver" and age >23 and address="京东"复制代码这样只会用到（name，age）这两个索引，从左边开始匹配，如果要是遇到范围查询的话，则不继续往右匹配索引
七、explain分析索引语句
我们用explain语句解析一下下面这条sql语句
EXPLAIN SELECT * from test WHERE name = "xhJaver"复制代码它的属性有
id: 执行的顺序
id相同时，顺序从上到下执行 id不同时，id大的先执行 select_type: 查询的类型
primary: 最外层的查询被标记为primary simple: 简单查询，没有关联其他表，就一张表 subquery: 在where或者select中的子查询 derived: 衍生虚拟表 例如from(子查询) t,这个子查询的结果就被放在虚拟表t中 table: 关于哪张表的
partitions: 分区相关（还没搞懂呜呜呜）
type:访问类型
性能由好至坏依次是 system > const > eq_ref > ref > fulltext > ref_or_null > index_merge > unique_subquery > index_subquery > range > index > ALL一般来说，好的sql查询至少达到range级别，最好能达到ref
system: テーブルにはデータが 1 行だけあります。
const: 定数クエリは次のとおりです。通常、主キーと等しいものを比較するために使用されます。 インデックスを使用して 1 つのクエリで見つけられる定数です。
eq_ref: 一意のインデックス。各インデックスはデータの一部に対応します。主キーインデックスなど、
ref: 一意ではないインデックス。各インデックスは、通常のインデックス
# など、複数のデータ行に対応する場合があります。##range : >、646cf51fa4256060e0bd2a3ddae5f70d,3730409ab0102a19484a1261b4c3727d, like "%xxx" 索引会失效 但是用覆盖索引就可以解决 like左模糊查询走不到索引的情况 如果只select索引字段，或者select索引字段和主键，也会走索引的。
更多相关免费学习推荐：mysql教程(视频)
以上がMysqlはインデックスに頼れるけど、バイトに頼るしかない…。の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。