事务
方式1：set @@autocommit = 0 -- 将事务提交方式设置为手动
方式2：start transaction -- 开启事务
事务四大特性ACID：
A：原子性（Atomicity）事务是不可分割的最小操作单元，要么全部成功，要么全部失败
C：一致性（Consistency）事务完成时，必须使所有数据都保持一直状态
I：隔离性（Isolation）数据库提供的隔离机制，保证事务在不受外包部并发操作影响的独立环境下运行
D：持久性（Durability）事务一旦提交或回滚，它对数据库中的数据的修改就是永久的
并发事务问题
脏读：一个事务读取到另外一个事务还没有提交的数据
不可重复读：一个事务先后读取同一条记录，但两次读取的数据不同
幻读：一个事务按条件查询时没有对应数据行，但在插入时，发现数据已存在
事务隔离级
脏读 不可重复读 幻读
Read uncommitted √ √ √
Read committed × √ √
Repeatable Read × × √
Serializable × × ×
-- 查看事务隔离级别
select @@transaction_isolation
-- 设置隔离级别
set { session | global } transaction isolation level {Read uncommitted | Read committed | Repeatable Read | Serializable}
MYSQL体系结构
第一层：连接层（连接池）
第二层：服务层（SQL接口、解析器、查询优化器。。。）
第三层：引擎层（可插拔存储引擎，InnoDB、MyISAM。。。）
第四层：存储层（系统文件、文件和日志）
存储引擎的特点
一：InnoDB
介绍： InnoDB是一种兼顾高可靠性和高性能的通用存储引擎，在mySQL5.5之后成为默认引擎
特点：DML操作遵循ACID模型，支持事务；支持行级锁，提高并发访问性能；支持外键，保证数据完整性和正确性
文件：xxx.ibd xxx表示表名，innoDB引擎的每张表都会对应一个表空间文件，存储该表的表结构（frm、sdi）、数据和索引。
二：MyISAM
介绍：MYISAM是MySQL早起的默认存储引擎
特点：不支持事务，不支持外键；支持表锁，不支持行锁；访问速度快
文件：xxx.MYD （数据信息）、xxx.MYI（索引信息）、xxx.sid（表结构信息）
三、Memory
介绍：存储在内存中，由于收到硬件问题、或断电问题，会导致数据丢失，所以只用来作为临时表或缓存使用
特点：访问速度快、支持hash索引（默认）
文件：xxx.sid 存储表结构信息
索引
介绍：索引是帮助MySQL高效获取数据的数据结构（有序），在数据之外，数据库系统还维护着满足特定查找算法的数据结构，这些数据结构以某种方式引用数据，
这样就可以在这些数据结构上实现高级查找算法，这种数据结构就是索引。
优点：提高数据检索效率，降低数据库的IO成本、通过索引对数据进行排序，降低数据排序的成本，降低CPU的消耗
缺点：占用空间；虽然提高了查询效率，但是降低了增删改的效率
索引的分类：
一：聚集索引（必须有且只有一个）
如图为对id字段建立的聚集索引，其叶子节点指向的就是这一行的数据
二：二级索引（可以有多个）
如图为对name字段建立的一个二级索引，其叶子节点指向的是id字段
索引语法
创建索引：create [unique | fulltext] index index_name on table_name(index_col_name,...)
查看索引：show index from table_name
删除索引：drop index index_name from table_name
SQL性能优化
查询SQL执行频率：
查看服务器状态信息，可以查看当前数据库的增删改查的访问频次
show [global | session] status 'com____';
慢查询日志：
记录了所有执行时间超过指定参数（long_query_time, 单位：秒，默认十秒）的所有SQL语句的日志
MYSQL的慢查询日志默认不开启，需要在MYSQL的配置文件（/etc/my.cnf）中配置：
show_query_log = 1
long_query_time = 2
profiles详情:
查看sql耗时具体详情，默认是关闭的，可以通过set语句在session/global级别开启profiling
#查看每一条sql的耗时情况：
select @@hav_profiling
#开启：
set profiling = 1
#查看指定query_id的SQL语句CPU的使用情况：
show profile cpu for query query_id
explain执行计划：
explain或desc命令获取mysql如何执行select语句的信息，包括执行过程中表如何连接和连接顺序
语法：
explain select 字段列表 from 表名 where 条件
id: select查询的序列号，（id相同，从上往下；id不同，大的先执行）
select_type:select的查询类型，simple（简单表，不适用表连接或子查询）、primary（主查询，外层的查询）、union（union中的第二个或后面的查询语句）、subquery（select/where之后包含的子查询）等。
type：表示连接类型，性能好到差分别为null、system、const、eq_ref、range、index、all
possible_key：显示可能应用在查询中的那个表的索引
key：使用的索引
key_len: 索引长度
索引使用原则：
最左前缀法则：如果索引了多列（联合索引），要遵循最左前缀法则，即查询要从索引的最左列开始，并且不跳过索引中的列。如果跳跃中间某一列，索引将部分失效（后面的字段索引失效）
情景一：跳过索引的第一列，索引全部失效
情景二：查询从索引最左边开始，中间跳过某一列，这一列之后的字段索引失效
范围查询：联合索引中，出现范围查询（> , <），范围查询右侧的列索引失效
如果业务允许，尽量使用 >= , <=
索引列运算操作：不要再索引列上进行运算操作，否则索引将失效
字符串不加引号：字符串字段不加引号，之后的索引失效
模糊查询：如果仅仅是尾部模糊匹配，索引不会失效。如果是头部，则失效
or连接的条件：如果or前的列有索引，而后面的列没索引，那么涉及的索引都不会被用到
数据分布影响：如果mysql评估使用索引比全表更慢，则不使用索引
SQL提示：在sql语句中加入人为的语句来达到优化的目的
select * from tb_user [use | ignore | force] index(idx_user_name) where name = 'xx'
覆盖索引：尽量使用覆盖索引（查询使用了索引，并且需要返回的列，在该索引中已经全部能够找到），减少select *；
回表查询：在二级索引中查找索引，再去聚集索引中找数据
explain中的extra 如果是
using index condition / null：查找使用了索引，但是需要回表查询数据
using where；using index：查询使用了索引，但需要的数据在索引列都能找到，不需要回表查询
前缀索引：当字段类型为varchar、text，有时候需要索引很长的字符串，这会使索引变得很大，查询时浪费大量的磁盘IO，影响效率。此事可以只将字符串的一部分前缀建立索引。
语法：create indedx idx_xxx on table_name(column(n)) # n表示截取几个字符
前缀长度选择：可以根据不重复的索引值（基数）/数据表的记录总数的比值，越靠近1性能越好，查询效率越高
select count(distinct email) / count(*) from tb_user
select count(distinct substring(email, 1, 5)) / count(*) from tb_user
索引设计原理
1.针对数据量大，且查询比较频繁的表建立索引
2.针对常作为查询条件、排序、分组操作的字段建立索引
3.尽量选择区分度高的列作为索引，尽量建立唯一索引
4.如果是字符串类型字段，建立前缀索引
5.尽量使用联合索引，查询时，联合索引很多时候可以覆盖索引，避免回表，提高效率
6.控制索引数量，索引越多，维护索引结构的代价也越大，会影响增删改的效率
7.如果索引列不能存储null值，请在创表时使用not null。优化器知道每列是否包含null值时，可以更换的确认哪个索引更有效地用于查询
InnoDB为什么选择B+树，不选择B树
1.B树只适合做随机检索，而B+树同时支持随机索引和顺序索引
2.利用率高。因为B+树非叶子节点只存索引值，而B树的非叶子节点与叶子节点都会存放数据，由此可见，B+树可以存储更多的索引值，从而使B+树变得更矮，减少I/O次数
3.查询效率更加稳定。B+树由于只有叶子节点存放数据，所以查询效率为O(logn)；而B树的查询效率为二分查找的效率O1~O(logn),
4.范围检索性能更佳。B+树的叶子节点形成了双向且有序的链表，大大增加了区间可访问性，只要遍历叶子节点就能实现遍历整棵树。B树节点间相互独立，无法查找区间，如需遍历整棵树，得进行每一层的递归来实现，耗时。
标签：index,存储,name,事务,查询,索引,MySQL,select From： https://www.cnblogs.com/Fei-Gao/p/16875942.html