mysql体系结构
mysql存储引擎
查询引擎语句
show engines;
各种存储引擎对比：
INNODB
外键约束：
存储方式：
MyISAM
不支持事物，不存储外键
文件存储方式
存储引擎选择
常用：
了解：
sql优化
sql优化步骤(原则首先要快速定位到问题sql)
1）查看sql执行频率
命令：显示当前session的统计参数的值
show status like 'Com________';
上面占位7个字符
全局的在status前面加个global
那么我们只查innodb相关的表的CRUD影响的行数的命令：
show status like 'innodb_rows_%';
那么怎么验证呢：
可以再执行一个sql语句再执行一下命令观察一下就能得出结论
以上作用：主要是用来这个判断当前数据库CURD操偶作中的哪个为主
2）定位低效率执行sql
两种方法：
每列参数：
3）分析执行计划
查询sql语句的执行计划：
列如：
select *from tb_itm where id = 1;
explain中每列具体代表的含义：
首先我们假设设计了这样一张表
中间那个是关联表，用户和角色是多对多的关系，这点明白了继续下一步
创建角色表：
创建用户表：
创建用户角色表中间表：
插入数据按照自己需要插入
环境准备好后继续
-
explain之id
首先明白这个查询出来的id跟主键还有自增是没关系的
id解释看上面表
当然要是单表查询这id用处也不大主要是看查多表的情况，细节注意最好查的时候表换成别名
id的情况有三种：
1）id相同表示加载表的顺序从上到下的
比如说多表等值连接查询情况
2）id不同id值越大优先级越高越先被执行
比如说嵌套子查询情况
按照这逻辑推导出来即像剥洋葱那样从内往外执行3）有点麻烦，id有相同的也有不同的，id相同的可以认为是一组，从上往下执行，所有组中id越大越先被执行
假设是这个sql语句：
单表查询又连接了一个子查询
那么推导出顺序先查子查询在和外表进行等值连接查询不用强记逻辑可以理解的和我们思维方式一样
-
explain之select_type
常见取值：
自顶向下效率越来越慢
标白的子查询是subquery，外层没标白的是primary
对应上面那表解释理解
然后要注意那个table里面表示的就是下面一行的id和select_type
这里两个单表查询求并集
需要注意了解一下<union1,2>
-
explain之table
表示这行数据是哪张表的 -
explain之type
要求一条数据的话来个子查询就好
通常这个是通过主键查询
当然还有特殊情况，原因username是唯一索引
- expain之key
解释在上面的表也有
前面索引的时候要用短索引 - explain之extra
显示还没显示的信息
如果出现了前两个就需要考虑性能的优化了
比如说这样就要考虑加索引了，或者向有索引的查询方式靠
show profile分析sql
这个默认是关闭的需要开启使用set语句
这里的开启级别是session
set profiling = 1;
那么后面查到了这个query_id，再根据最开始那个体系结构图你会发现这个线程每个阶段消耗时间的情况
trace分析优化器执行计划
查询系统盘
解析select后的*号
