- 一条sql的执行过程
- 首先执行器根据Mysql的执行计划来查询数据,先会到缓存池中去查询(buffer pool),如果没有则再到数据库中查询, 将查询到的数据放入缓存池(buffer pool)
- 在数据放入缓存池的同时,将数据写入undo log
- 更新的动作在buffer pool中完成,同时将更新后的数据写入redo log buffer中
- 完成后就可以提交事务,提交的同时会发生以下:
- 将redo log buffer中数据刷入redo log file
- 将本次操作写入bin log中
- 将bin log名以及数据在bin log中的位置记录到redo log中,同时在redo log中置commit
int(10)中10的意思是?
10的意思是显示的长度,不是存放数据的大小限制.语句分类
- DDL(结构改动)
- DML(数据改动)
- DCL(权限改动)
- DQL(查询)
Innodb引擎是如何支持DDL的
先对origin_table生成一个不可见的临时表
对origin_table write lock 数据改动锁住,只可以读
将表数据添加到临时表 insert into tmp_table select * from origin_table
重命名临时表,删除原表 rename tmp_table, drop origin_table
释放write lockmysql建索引的原则
- 对于查询频率高,查询速度要求高的字段建立索引
- 建立联合索引需要遵循最左前缀原则
- 唯一性索引要建立在唯一性字段上
- 索引尽量建在数据量少的字段上(比如说:建立在char(4)上的效果比char(900)好 )
- 索引不是越多越好,底层维护索引也会消耗相应的资源
- 对排序,分组的字段建立索引
- 更新比较少
- 区分度高
- 联合索引的应用场景
- 当查询经常同时以多个列做条件时,可以考虑建立联合索引
- 覆盖索引,当多个列经常作为查询的目标时,可以考虑建立联合索引形成覆盖索引
- 按照多个列进行排序和分组操作
什么是最左匹配原则
查询语句使用的索引必须从联合索引的最左侧开始连续匹配,才能利用联合索引加快查询速度可能观察到mysql的自增主键出现了不连续的情况,什么原因?
mysql的自增主键是逐个按步长生成的,可能有部分操作插入数据正常获取了主键却没有插入成功,但是主键已经生成了不会再恢复了
没有插入成功的原因就有很多了: 唯一索引冲突,事务回滚..
批量插入也可能造成逐渐不连续对于insert into tablename values (xxx)操作,在申请自增id时直接会申请对应数量的一批id,但是如果是
insert into tablename select…..操作,mysql并不能只能得申请多少主键,这里采用了一种翻倍申请的策略:即第一次申请1个,然后申请2个,然后申请4个… 这样的话,其实最后一批id就可能申请了但是没有全部用上,自然就浪费了.为什么自增id不做回退
为了轻,为了生成id的性能.mysql索引失效的原因
- 对索引字段使用函数
- 违反了最左前缀原则
- 使用like并且以%开头
- 使用or.(当or连接的字段是同一个时索引生效的)
- 使用!=, not in
- 数据类型不同,sql中的数据类型和表中定义的数据类型不同
- select * from table where a=1 for update，会加什么锁
a字段是唯一索引，a=1记录存在，加行级排他锁
a字段是非唯一索引，a=1记录存在，对所有a=1的行加行级排他锁.对主键加锁,对最近的不符合条件的区间加间隙锁防止幻读
a字段没有索引，a=1记录存在，加表级排他锁
a=1不存在，不加锁