P2 MySQL简介
完整的MySQL优化需要专门的DBA，开发只需要负责写出高效的SQL即可，但仍需要很深的功底，因为SQL易学难精；
高级内容：
MySQL内核（内核优化改写）
SQL优化攻城狮
MySQL服务器优化
各种参数常量设定
查询语句优化
主从复制
软硬件升级
容灾备份
SQL编程
P3 RPM安装
主流都是二进制安装
此处介绍RPM安装，下载GA版本(稳定发布版)
选择Linux-Generic分类
我们下载一个server端一个client端
检查是否安装过MySQL（或MariaDB）
rpm -qa |grep -i mysql
然后rpm -ivh 命令安装服务端
查看安装后的提示：
然后我们根据提示去给root设置密码
然后rpm -ivh 命令安装客户端
然后我们查看用户和用户组，以及查看版本，来检查是否安装成功
cat /etc/passwd |grep mysql
cat /etc/group |grep mysql
mysqladmin --version
CentOS6启动mysql，以及查看进程
service mysql start
ps -ef |grep mysql
P4 设置ROOT密码和开机自启
首次连接只需输入mysql然后回车就可以进入mysql命令行
按照之前提示需要用mysqladmin改root密码：
/usr/bin/mysqladmin -u root password 123456
然后再进入mysql就需要输入密码了
然后u我们设置开机自启
chkconfig mysql on
chkconfig --list |grep mysql
此处的1、2、3、4、5、6指的是运行级别
通过cat /etc/inittab查看
然后netsysv检查，开机自启的服务中括号里都有一个星号
P5 安装位置(RPM)
①/var/lib/mysql/
是mysql数据库文件存放路径
pid等文件也存在此目录中
②usr/share/mysql/
配置文件目录
mysql.server命令及配置文件存放于此
③/usr/bin
相关命令目录
如mysqladmin mysqldump
④/etc/init.d/mysql
启停相关脚本
P6 修改字符集
cp my-huge.cng /etc/my.cnf
然后重启mysql
进入mysql
show variables like ‘%char%’;
修改配置文件：
再重启
之后新库就可以支持utf-8了
P7 MySQL配置文件
定义一些日志的开启、路径
数据文件路径
一些优化参数
数据文件：
换InnoDB引擎的话就是.frm和.ibd文件(8.0开始只有.ibd文件)
P8 MySQL逻辑架构介绍
连接层
服务层
引擎层
存储层
P9 存储引擎简介
查看支持的存储引擎、查看默认及当前存储引擎：
show engines;
show variables like '%storage_engine%';
P10 SQL性能下降原因
P11 SQL执行加载顺序
P12 七种JOIN理论
这两种有待实验考证
P13 七种JOIN的SQL编写
MySQL语法不支持full outer join，本身使用的场景也很少，实现full outer join使用如下语句
P14 索引
是帮助MySQL高效获取数据的数据结构。
简单理解为排好序的快速查找数据结构，以索引文件的形式存储在磁盘上。
如果没有特别说明，都是指B树，MySQL中B+树，当然还有哈希索引。
P15 索引的优势劣势
优势：
提高检索效率，降低IO成本；
降低排序成本，降低CPU消耗；
劣势：
索引占磁盘空间；
会降低表写操作(插入/更新/删除)的速度；
P16 建索引命令
建议一张表索引不超过5个
P17 索引结构和检索原理
我们主要研究B树索引
P18 哪些情况适合建索引
1.主键自动建索引；
2.频繁查找的字段
3.查询中与其他表关联的字段，外键关系建立索引
4.频繁更新的、where用不到的字段不创建
5.排序字段
6.根据需要创建组合索引
7.查询中分组或统计的字段
P19 哪些情况不适合建索引
1.表记录太少
2.经常增删改的表
3.选择性过低的字段
P20 性能分析前提知识
P21 Explain简介
P22 explain之id
对应“表的读取顺序”
id相同的情况，执行顺序由上至下；
如果是子查询，id的序号会递增，id值越大的优先级越高，越先被执行；
如果是混合的，id值大的先执行，id平级的由上至下
derived是衍生的意思，就是延申出来的虚表，如下图所指的S1
P23 explain之select type和table
1.simple，简单的select，查询中不包括子查询或者union
2.primary，一段查询如果包含任何复杂的子部分，则最外层查询被标记为primary
3.subquery，在select或where列表中包含了子查询
4.derived，在from列表中包含的子查询被标记为衍生表，derived后面的标记数字，对应的是id，如derived2即id为2的子查询衍生出来的表，mysql会递归执行这些子查询，把结果放在临时表中，所以衍生表会使用临时表
5.union，若第二个select出现在union之后，则被标记为union；若union包含在from子句的子查询中，外层select将标记为derived，因为也属于union衍生出来的表
6.union result，从union表获取结果的select（区别于刚才的union在from子句中，这个不用临时表，直接输出结果）
table显示这一行是关于哪张表的，不用多说
P24 explain之type
type指的是访问类型
常见的值有如下几种：
从最好到最差依次如下：
system > const > eq_ref > ref > range > index > all
一般来说，得保证查询至少达到range级别，最好能达到ref
1.system，表里只有一行记录（等于系统表，mysql库带的表），是const类型特例，平时不会出现
2.const，意思是常量，表示通过索引一次就找到了。常见于primary key或unique索引只匹配一行数据的情况；
3.eq_ref，唯一性查找，对于每个索引键，表中只有一条记录与之匹配，常见于主键或唯一索引
4.ref，非唯一性查找，返回匹配某个值的所有行，查找和扫描的混合体
5.range，检索给定范围的行，一般是where语句中出现了between，< ， > ，in等
6.index，全索引扫描，通常比ALL快
7.all，全表扫描
P25 explain之possible_key和key
possible_keys：显示可能使用的索引，一个或多个，查询涉及到的字段上若存在索引，则该索引将被列出，但不一定被查询实际使用
key：实际使用的索引，如果显示为NULL，则是没建索引或索引失效
查询中若使用了覆盖索引，则该索引仅出现在key列表中
P26 explain之key_len
表示索引中使用的字节数，可通过该列计算查询中使用的索引的长度
在不损失精确性的情况下，长度越短越好。
key_len显示的值为索引字段的最大可能长度，并非实际使用长度，
即key_len是根据表定义计算而得，不是通过表内检索出
P27 explain之ref
显示索引的哪一列被使用了，
如果可能的话，是一个常数。
哪些列或者常量被用于查找索引列上的值
如：
可以是库.表.字段，或常量
P28 explain之rows
根据表统计信息及索引选用情况，大致估算出找到所需记录需要读取的行数，当然是越少越好
P29 exolain之extra
十分重要的额外信息
1.using filesort，使用了文件排序，说明mysql会对数据使用一个外部的索引排序，而不是按照我们表的索引顺序进行读取。mysql中无法利用索引完成的排序称为文件排序；需要我们尽量避免
2.using temporary，使用了临时表保存中间结果，常见于order by排序、分组查询group by
3.using index，表示相应select操作使用了覆盖索引，从索引中就能取得数据，而避免访问了表的数据行；
如果同时出现了using where，表明索引被用来执行索引键值的查找；
如果没有同时出现using where，表明索引用来索引全扫描，而非查找动作
4.using where，表示使用了where过滤
5.using join buffer，表示使用了连接缓存，即配置文件的join_buffer_size
6.impossible where，表示where子句的值总是false，不能用来获取任何元组
7.select tables optimized away，对MyISAM引擎优化COUNT(*)的操作
8.distinct，表示优化distinct，在找到第一匹配的元组后即停止查找相同值的操作
P30 case
答案：
1.id4的步骤，即union后面select name, id from t2
2.id3的步骤，即select id ,name from t1 where …
3.id2的步骤，即子查询select id from t3
4.id1的步骤select d1.name from d1（id3步骤的衍生表）
5.null的步骤，即id1和id4的union结果
P31 索引单表优化案例
where语句中第二个条件是大于，范围查询之后的就无法再走索引了，所以还是有filesort
P32 索引两表优化案例
左外联的话，索引建在关联条件的右表上；
右外联同理，也是“相反加”
P33 索引三表优化案例
结论：
尽可能减少join语句中nestedloop的次数，永远用小表驱动大表
优先优化nestedloop的内层循环
保证join语句中被驱动表上join条件字段已经有索引
若无法保证被驱动表join条件字段有索引，且内存资源充足时，可加大join_buffer_size
P34 索引优化1
如果是组合索引，要遵循最左前缀法则
带头大哥不能死，中间兄弟不能断
（oracle中还要避免跳扫）
P35 索引优化2
不要在索引列上进行任何计算、函数、（显示或隐式）类型转换
P36 索引优化3
范围之后全失效（无法使用组合索引范围条件字段右边的列，如< ，>，between，like）
P37 索引优化4
尽量使用覆盖索引，（查询列包含在索引列中），避免使用select *
P38 索引优化5
使用!=或<>会导致不走索引
P39 索引优化6
is null，is not null也不走索引
P40 索引优化7
like以通配符开头不走索引
P41 索引优化8
字符串类型不加单引号会导致索引失效，因为引发隐式转换
少用or，用它来连接有时也会导致索引失效
P46 小表驱动大表
永远小表驱动大表(连接成本高)
注：两表ID字段应建立索引
P47 in和exists
P48 为排序使用索引order by优化
order by子句，尽量使用using index方式排序，避免使用using filesort方式排序
重点：避免filesort！
如果order by 的字段一个是正序一个是倒序的话，就还是使用filesort，因为默认索引建的都是正序，即字段顺序相同，必须“同升同降”；
4.1版本之前是双路排序，要读两次磁盘，4.1之后改进成为单路排序：
从磁盘中读取查询所需要的所有列，在buffer中按照order by列进行排序，然后扫描排序后的列表进行输出，把随机IO变成顺序IO，但是也占用更多内存；
总体而言单路要优于双路，但是如果取的数据要高于sort_buffer_size的话，就要取好几次直至取完，这样就会产生多次IO，效果会更差；
因此需要增大sort_buffer_size和max_length_for_sort_data这两个参数的设置
P49 慢查询日志
set global slow_query_log=1是临时开启，永久开启需要改配置文件
set global long_query_time=2;
需要重新连接或者新开一个会话才能看到新设置的值；
分析工具mysqldumpslow
当然作为DBA一般我们都用pt工具
P50 批量插入数据脚本
注：以$$为结束之后还需要改回以;为结束，即DELIMITER;
P51 用show profile进行SQL分析
查看当前版本是否支持
遇到的话就必须要优化了
P52 全局查询日志
绝不可能生产环境使用，只能测试环境使用
所有sql都记录到mysql.general_log表中
P53 锁理论
P56 行锁理论
P59 索引失效导致行锁变表锁
例如，隐式转换导致的索引失效，行锁变表锁；
P60 间隙锁的危害
P61 如何锁定一行
select … for update
P62 行锁总结
一定要用show profile分析
