00：51：使用该语句查找mysql的配置文件的顺序。

网络方面的配置，需要修改/etc/sysctl.conf文件

修改/etc/security/limits.conf文件，可修改打开文件数量的限制

* soft nofile 65535

*hard nofile 65535

最好关闭防火墙软件，使用硬件防火墙代替（？）。

1. 水平拆分：解决数据量的问题。

行数代表了具体的数据量大小。

2. 水平拆分后，表结构相同，即表列字段相同。

方法：

1. 对custom_id用到hash操作, 若拆成个水平表，mod(custom_id,5)取出0-4个值；

2. 针对不同hashID把数据存到不同的表中。

前台使用拆分后的表，方便使用，后台使用汇总表，方便统计以及后天报表操作。

垂直拆分三原则(分别三种情况)：

1. 不常用

2. 大字段

3. 经常用

例子中，拆分后两个表都有一个film_id,这就是垂直拆分后两个表的关联所在。

为提高io读的效率，牺牲一些存储空间的代价。但是提高了读取数据的效率。

如用户常常会大量查询订单的信息，那么吧用户名，电话，地址和订单价格放入一个订单表中，虽然违反了第三范式，因为订单id，用户名，电话，地址等，存在传递函数依赖，但是由于数据都是在一张表中，方便了sql语句实现，订单信息的读取，从而优化了io性能；

一般来说 是对符合第三范式的表结构进行设计，在设计之前，就要考察表是否符合第三范式要求；有无存在非关键字段对某一关键字段的传递函数依赖。

合适的数据类型选择：

1.最小数据存储原则；

2.简单数据类型原则；

3.NOT NULL字段尽可能用，因为如果不加，由于innodb的存储特性，对于非not null 的（没听清楚）表会有额外字段来存储；

4尽量少text类型；

由于用户变更等可能性，有些索引不再使用，因此需要删除不用索引。

1.维护和删除冗余索引：

 2：30：

联合索引中包含了主键：innodb的特性，它会自动在每个索引后附加一个主键，

因此人为添加主键信息key（name，id）就是一个冗余索引；

2.    2：57 ：查找重复及冗余索引的sql语句

要在information_schema数据库运行该语句

3. 使用pt-duplicate-key-checker工具查找重复及冗余索引

1.索引的建立：

在条件从句中建立索引：

如：where ， order by， group by， on 从句

2. 索引字段越小越好。 

使得一页存储的数据量增大，使得io效率更好。

3.离散度大的列放到联合索引前面,离散度高，可选择性更好,放在前面效果越好；

判断列离散度的语句

select count(distinct custom_id), count(distinct staff_id) from payment;

所以选择联合索引 index(custom_id,staff_id)

limit查询本身大量伴随order by处理，因此常常会是用filesort，因此造成大量io问题。

使用limit语句时，要考虑io问题可否进一步优化。

1：44显示，order by 操作中使用了表扫描的操作（type：all），产生大量io问题。（尽量用少的读写实现问题的解决）

优化方法步骤：

1.使用有索引的列或者逐渐进行order by 操作；（优化前是order by title非主键，优化后是order by film_id,是主键）；

2.偏移量(翻页的扫描数据量会随着偏移量增加而增加)优化：记录上次返回的主键，在下次查询时使用主键过滤（where 主键从句）；如：

偏移量是55，一页是5行数据， where film_id>55 and film_id<=60，则限定了从第56行查起，查到60行为止，从而大大降低了数据的扫描io操作；

这样直接可以避免扫描过多的记录。

其实也是在了解了limit执行方式之后，在不违反limit语句后台执行方式的逻辑下，对limit的操作进行了sql语句的限制，从而优化limit的io性能。

优化前（1：02）;并未时候用where语句，因此后台会出现页表扫描的情况，降低sql执行效率。后台仍然使用了临时表和文件排序的操作。

优化后：利用关联子查询，查到了每一个演员id对应影片数量，再跟演员表关联，查询到了演员姓名，以及对应的影片数量。（当然二者from的表都不一样，优化前是from film_actor,优化后是from actor，可能二者不同表之间数据量也存在差异）

优化前（1：02）;并未时候用where语句，因此后台会出现页表扫描的情况，降低sql执行效率。后台仍然使用了临时表和文件排序的操作。

优化后：利用关联子查询，查到了每一个演员id对应影片数量，再跟演员表关联，查询到了演员姓名。

在子查询的优化中：

通常做法是把需要的子查询优化为join查询，但在优化时要注意是否有数据的重复，因为在关联语句中的可能存在一对多的关系，从而造成数据冗余。

join语句是相当于将多个表进行关联，在关联条件上一一进行条件匹配查询，因此返回值不仅取决于原始表中的数据个数，还取决于其他表中与之匹配的数据的个数。

所以要加上distinct

具体:3:08: select distinct t.id from t join t1 on t.id=t1.tid;

逻辑上的sql优化具体案例（需要大量经验和自我总结得到）：

max()语句优化：

1：44：看到rows 非常高，说明sql语句效率不高；

这时候优化思路是：可以在'payment_date'上建立索引

create index idx_paydate on payment(payment_date);

这时候 在执行max（payment_date）后rows为null，说明执行效率很高，

因为索引是顺序排列的，通过索引统计信息就可以知道，最后一个payment_date的数值是怎么样的，所以不需要经过表数据查询即可知道max()结果。

完全可以通过索引信息查到我们需要的结果，称为“覆盖”索引；

count()优化：

3：37：sql语句逻辑上不符合我们的具体要求了；

4：52 优化后的语句逻辑上符合要求：

用到了count(null)返回值为0的特点，（这也是需要经验的），count（*）中，若遇到null返回值为1；