06 | 全局锁和表锁:给表加个字段怎么有那么多阻碍?

2019-07-15 10:01:43

本文的总结源于林晓斌在极客时间里面的课程,为避免产生商业问题,我只是用于个人学习总结。 原文地址:https://time.geekbang.org/column/article/69862 小结 根据加锁范围:MySQL里面的锁可以分为:全局锁、表级锁、行级锁 全局锁 对整个数据库实例加锁 MySQL提供全局读锁的方法:flush tables with read lock(FTWRL) 这个命令可以使整个库处于只读状态,使用该命令之后,数据更新语句、数据定义语句和更新类事务的提交语句等操作都会被阻塞。 使用场景:全库逻辑备份 风险: 如果在主库备份,在备份期间不能更新,业务停摆 如果在从库备份,备份期间不能执行主库同步的binlog,导致主从延迟 官方自带的逻辑备份工具Mysqldump,当Mysqldump使用参数--single-transaction的时候,会启动一个书屋,确保拿到一致性视图。而由于MVCC的支持,这个过程中数据是可以正常更新的。 一致性读是好,但是前提是引擎要支持这个隔离级别。 如果要全库只读,为什么不使用set global

05 | 深入浅出索引(下)

2019-07-12 15:49:03

本文的总结源于林晓斌在极客时间里面的课程,为避免产生商业问题,我只是用于个人学习总结。 原文地址:https://time.geekbang.org/column/article/69636 小结 覆盖索引:覆盖索引可以减少树的搜索次数,显著提升查询性能,所以使用覆盖索引是一个常用的性能优化手段 针对某些高频查询,要根据市民的身份证号查询他的姓名,则在(身份证号、姓名)上面创建一个联合索引,就可以在这个高频请求上用到覆盖索引,不再需要回表查整行记录,减少语句的执行时间 B+树这种索引结构,可以利用索引的“最左前缀”,来定位记录 联合索引的理解:比如一个联合索引(a,b,c),其实质是按a,b,c的顺序拼接成了一个二进制字节数组,索引记录是按该字节数组逐字节比较排序的,所以其是先按a排序,再按b排序,再按c排序,至于其为什么是按最左前缀匹配的也就显而易见了。 给表创建索引时,应该创建哪些索引,每个索引应该包含哪些字段,字段的顺序怎么排列,这个问题没有标准答案,需要根据具体的业务来做权衡。不过有些思路还是可供参考的:

04 | 深入浅出索引(上)

2019-07-10 14:56:06

本文的总结源于林晓斌在极客时间里面的课程,为避免产生商业问题,我只是用于个人学习总结。 原文地址:https://time.geekbang.org/column/article/69236 小结 索引的作用:提高数据查询效率 常见索引模型:哈希表、有序数组、搜索树 哈希表:键-值(key-value) 哈希思路:把值放在数组里,用一个哈希函数把key换算成一个确定的位置,然后把value放在数组的这个位置 哈希冲突的处理办法:链表 哈希表适用场景:只有等值查询的场景 有序数组:按顺序存储。查询用二分法就可以快速查询,时间复杂度是:O(log(N)) 有序数组查询效率高,更新效率低 有序数组的适用场景:静态存储引擎(比如往年数据,不会进行变动的数据) 二叉搜索树:每个节点的左儿子小于父节点,父节点又小于右儿子 二叉搜索树:查询时间复杂度O(log(N)),更新时间复杂度O(

03 | 事务隔离:为什么你改了我还看不见?

2019-07-09 16:54:24

本文的总结源于林晓斌在极客时间里面的课程,为避免产生商业问题,我只是用于个人学习总结。 原文地址:https://time.geekbang.org/column/article/68963 思维导图 图形解说 针对上面看到的四个隔离级别,并结合这个案例来进行解说,我们来看看不同的隔离级别下,事务A会有哪些不同的返回结果,也就是图里面V1、V2、V3的返回值分别是什么 若隔离级别是“读未提交”,则V1的值就是2.这时候事务B虽然还没有提交,但是结果已经被A看到了。因此,V2、V3也都是2. 若隔离级别是“读提交”,则V1是1,V2的值是2.事务B的更新在提交后才能被A看到。所以V3的值也是2. 若隔离级别是“可重复读”,则V1、V2是1,V3是2.之所以V2还是1,遵循的就是这个要求:事务在执行期间看到的数据前后必须是一致的。 若隔离级别是“串行化”,则在事务B执行“将1改成2”的时候,会被锁住。直到事务A提交后,事务B才可以继续执行。

02 | 日志系统:一条SQL更新语句是如何执行的?

2019-07-09 16:10:49

本文的总结源于林晓斌在极客时间里面的课程,为避免产生商业问题,我只是用于个人学习总结。 原文地址:https://time.geekbang.org/column/article/68633 本篇重点 一条SQL语句的执行步骤 update T set c=c+1 where ID=2; 执行流程图 小结 redo是物理的,binlog是逻辑的;现在由于redo是属于InnoDB引擎,所以必须要有binlog,因为你可以使用别的引擎 保证数据库的一致性,必须要保证2份日志一致,使用的2阶段式提交;其实感觉像事务,不是成功就是失败,不能让中间环节出现,也就是一个成功,一个失败 如果有一天mysql只有InnoDB引擎了,有redo来实现复制,那么感觉oracle的DG就诞生了,物理的速度也将远超逻辑的,毕竟只记录了改动向量 binlog几大模式,一般采用row,因为遇到时间,从库可能会出现不一致的情况,但是row更新前后都有,会导致日志变大 最后2个参数,保证事务成功,

01 | 基础架构:一条SQL查询语句是如何执行的?

2019-07-09 15:42:31

本文的总结源于林晓斌在极客时间里面的课程,为避免产生商业问题,我只是用于个人学习总结。 原文地址:https://time.geekbang.org/column/article/68319 思维导图 问题总结 MySQL的框架有几个组件,各有什么作用? Server层和存储引擎层各有什么作用? you have an error in your SQL syntax这个是在词法分析还是在语法分析里面报的错? 对于表的操作权限验证是在哪里进行? 执行器的执行查询语句的流程是什么样的?

Data too long for column

2019-04-04 10:02:43

背景 最近在对MySQL进行一个常见的数据插入的时候,报了一个Data too long for column xxx的错误,当时就有点懵,首先我存放的这个字段里面内容可能会比较大,当初我就设置为TEXT类型,按理说用这个类型来存放已经足够,就不会报这个问题才对 解决办法 varchar 如果原本定义的字段类型为varchar类型,应该是你存放的数据超过了设置的长度,两种方式: 把varchar设置更大值 将MySQL模式设置为非严格模式(这个主要是由低版本的MySQL转高版本MySQL导致,比如数据迁移时) SET @@global.sql_mode= 'NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION'; text 而我此次出的问题就是这个,本想text类型已经够存放,但第三方存放的数据大小往往会是不可控的,需要将原有的TEXT改为MEDIUMTEXT,当然具体大小怎么更改需要看你具体业务需求,不是越大越好。我们可以看下面的定义: 类型 大小 TINYTEXT 256 bytes TEXT 65,535 bytes