MySQL 执行计划

MySQL执行计划

id

select_type

    materialized ： 结果集被物化成临时表

type

    const : 使用主键或唯一索引
    ref : 普通索引 + 回表 或 const is null 或 联合索引最左匹配
    ref_or_null : ref or is null 
    range : 范围查找
    index : 遍历普通索引，不需要回表
    all : 嗯呢

    eq_ref : 连表查询中被驱动表使用主键

possible_key

key
key_len
ref
rows
filtered
    rows * x% = 
Extra
    Using index ： 没有回表操作，仅仅在二级索引里执行。
    Using index condition : explain select * from t1 where x1 > 'xxx' and x1 like '%xxx';  二级索引查找之后再根据条件过滤
    Using where : 
        -- 没有使用索引，并且存在 where 子句
        explain select * from t1 where x2 = 'xxx';

        -- 除了索引列，还需要其他字段进行筛选
        explain select * from t1 where x1 = 'xxx' and x2 = 'xxx';

    Using join buffer : 
        -- 关联条件并不是索引，使用 join buffer 的内存技术
        explain select * from t1 inner join t2 on t1.x2 = t2.x2;

    Using filesort : 
        -- 无索引，排序
        explain select x2 from t1 group by x2;

    Using temprory : 
        -- 无索引，分组
        explain select x2 from t1 order by x2;

show warnings;

semi join : 对users表里每一条数据，去对物化临时表全表扫描做semi join，不需要把users表里的数据真的跟物化临时表里的数据join上。只要users表里的一条数据，在物化临时表里可以找到匹配的数据，那么users表里的数据就会返回，这就叫做semi join 

set optimizer_switch=‘semijoin=off'

1. 为什么在这个案例中MySQL默认会选择对主键的聚簇索引进行扫描？
2. 为什么没有使用index_category这个二级索引进行扫描？
3. 即使用了聚簇索引，为什么这个SQL以前没有问题，现在突然就有问题了？

select * from comments where product_id = 'xx' and is_good_comment = '1' order by id desc limit 10000, 20;
select * from comments a, (select id from comments where product_id = 'xx' and is_good_comment = '1' order by id desc limit 100000, 20) b where a.id = b.id;

删除了千万级的数据
磁盘、网络、CPU
MySQL profilling

show engine innodb status;

主从复制
高可用
读写分离
分库分表

binlog
dump线程
IO线程
relay日志
SQL线程 日志重做

异步复制
半同步复制
    install plugin rpl_semi_sync_master soname 'semisync_master.so';
    set global rpl_semi_sync_master_enabled=on;

gtid
    GTID_Event

MyCat
Sharding-Sphere

percona-toolkit -> pt-heartbeat

多线程并行复制数据

MHA

1. 为什么要分库分表（设计高并发系统的时候，数据库层面该如何设计）？用过哪些分库分表中间件？不同的分库分表中间件都有说明优缺点？你们具体是如何对数据库进行垂直拆分或水平拆分的？