事务:
每一条的存储记录都会在结尾添加两个记录,一个是svn，另一个是是否删除记录号,数据库的四个隔离级别就是使用了这个来实现，
可重复读可以使用间隙锁来预防幻读。(被老板diss的我瑟瑟发抖)
优化:
1.字段:
1).假如一个字段i必须有null，才可以不用设置为not null，null对索引不是很友好.
2).关于类型,字符串的类型总是要比整形和浮点型慢很多,在存储空间上也会占用比较大一部分位置.
优化exapmle：
关于id地址整形和字符串之间相互转换的案例
select inet_ntoa(3232235890) as ip;
select inet_aton('192.168.1.114') as ip;3).char和varchar,varchar存储会在结尾占用一到两个字节来说明当前字符串的长度,然而char就不会，在固定长度或者极短的字符串存储从上可以使用char类型.varchar在存储上会引起页分裂,因为他会存储到不同的位置，但是char会制定存储长度,所以不会分散存储到不同的位置(tell me why),所以按照建议可以使用char来进行存储。
4).表的关联之间字段类型要相同,隐式类型转换可能会出问题.
2.索引
整个索引基本上是讨论的B+树，插入元素索引乱序会引起页分裂，如何使用索引也很关键
1).聚簇索引
假如有主键索引就使用主键索引,没有的话就使用唯一索引,二者都没有的话就...我也忘了
2).唯一索引
有机会成为一级索引
3).前缀索引
挑选某一列的前几个字符成为索引,挑选几列也要讲究原理,可以参考其他人内容，失效原因是使用like时使用%开头。
4).复合索引
挑选某几列成为复合索引,关键怎么搭配,谁在前谁在后需要了解innodb关于符合索引的存储原理，失效原因是where的列被没有满足复合索引顺序的索引要求。
一条语句是否走索引可以用explain进行查看,观看type所显示的内容，查询的时候可以将查询的列选为索引,这样不会有回表操作
回表过程为where字段为索引列，select字段为非索引列，此时会先查询到一级索引，在查询到当前行数据。当select字段和where字段结尾索引字段时 不会产生回表。
二级索引节点页指向叶子页，节点页面存储索引内容,叶子页面存储一级索引,并携带当前行数据。
索引失效原因众多，其中包换在where中对索引列使用函数，因为我们要的是这个列，而不是其列对应的表达式。
3.语句优化
关于mysql整个架构。fork子进程->(缓存器->解析器)/(解析器)->优化器->API->数据库引擎
在每一个部分都会进行不同的优化,在优化器部分,任何外链接查询都是基于一张表做驱动表，是一个深度优先的查询树(先序遍历)。
所以可以使用小表作为驱动表减少嵌套和回表操作，同时降低笛卡尔积。关联优化器可以将小表自动放到前面(是在使用内连接的情况下)。
关联时的排序，假如order by字段或者group 字段都是来自于第一张关联表，那么会使用文件排序，否则会讲数据先放到临时表中在进行排序。
关联时的索引使用，order by 或者group by字段都是来自同一张表才会有可能使用索引，否则的话不会使用索引。
limit分页查询的优化重点在于索引覆盖扫描，这里涉及到回表的知识点，使用延时关联即可，子查询中不产生回表操作，返回索引字段，再用索引字段进行关联查询所需数据。
暂时先到这里吧
