"https://www.jianshu.com/p/0371c9569736"

"https://segmentfault.com/a/1190000008230146\n原文： https://golang.org/ref/mem"

"https://www.jianshu.com/p/d24dfbb33781"

"https://www.jianshu.com/p/dd80f6be7969"

"unsafe包位置: src/unsafe/unsafe.go\n指针类型： ***类型：**普通指针，用于传递对象地址，不能进行指针运算。 **unsafe.Pointer：**通用指针，用于转换不同类型的指针，不能进行指针运算。 **uintptr：**用于指针运算，GC 不把 uintptr 当指针，uintptr 无法持有对象。uintptr 类型的目标会被 GC 回收。\nunsafe.Pointer 可以和 普通指针 进行相互转换。 unsafe.Pointer 可以和 uintptr 进行相互转换。 也就是说 unsafe.Pointer 是桥梁，可以让任意类型的指针实现相互转换，也可以将任意类型的指针转换为 uintptr 进行指针运算。\n一般使用流程： 第一步：将结构体 -\u0026gt; 通用指针unsafe.Pointer(struct) -\u0026gt; uintptr(通用指针)获取内存段的起始位置start_pos，并记录下来，第二步使用。 第二步：使用start_pos + unsafe.Offsetof(s.b) -\u0026gt; 将地址转为能用指 …"

"首先我们对切片有一个大概的理解，先看一下slice的内部结构，共分三部分，一个是指向底层数组的时候，一个是长度len，另一个就是slice的容量cap了。如cap不足以放在新值的时候，会产生新的内存地址申请。\n先看代码\npackage main import \u0026#34;fmt\u0026#34; func main() { // 创建一个切片，长度为9，容量为10 fmt.Println(\u0026#34;----- 1.测试切片变量append的影响（未申请新的内存空间）-----\u0026#34;) a := make([]int, 9,10) fmt.Printf( \u0026#34;%p len=%d cap=%d %vn\u0026#34; , a, len(a), cap(a), a) // 切片进行append操作，由于原来len(a)长度为9,而cap(a)容量为10，未达到扩展内存的要求，此时新创建的切片变量还指向原来的底层数组，只是数组的后面添加一个新值 // 此时一共两个切片变量，一个是a，另一个是s4。但共指向的一个内存地址 s4 := append(a,4) fmt.Printf(\u0026#34;%p …"

"一：innodb_file_format参数 在 innodb 1.0.6版本之前，innodb文件格式innodb_file_format只有 Antelope(Antelope 文件格式支持Redundant，Compact两种格式来存放行记录，Redundant是为了兼容之前版本而保留的。在mysql 5.1版本中，默认设置为Compact，用户可以通过 show table status like 'table_name'来查看表使用的行格式row_format)\n从innodb 1.0.6开始引入了新的文件格式 Barracuda 在原来的基础上(Antelope)新增了Dynamic和Compressed两种行格式。\n二：innodb_file_format如何使用 一般， innodb_file_format 在配置文件中指定；row_format则在创建数据表时指定：\nCREATE TABLE test2 (column1 INT PRIMARY KEY) ENGINE=InnoDB ROW_FORMAT=Compressed KEY_BLOCK_SIZE=4; …"

"推荐阅读： https://www.cnblogs.com/zishengY/p/6892345.html"

"**一、什么是MRR ** MMR全称是Multi-Range Read，是MYSQL5.6优化器的一个新特性，在MariaDB5.5也有这个特性。优化的功能在使用二级索引做范围扫描的过程中减少磁盘随机IO和减少主键索引的访问次数。是优化器将随机 IO 转化为顺序 IO 以降低查询过程中 IO 开销的一种手段。（参考： https://blog.csdn.net/caomiao2006/article/details/52205177）\n**二、MRR和没有MRR的区别 ** 给出一个简单的例子，在innodb表执行下面的查询：\nSELECT non_key_column FROM tbl WHERE key_column=x\n在没有MRR的情况下，它是这样得到结果的：\n1. select key_column, pk_column from tb where key_column=x order by key_column —\u0026gt; 假设这个结果集是t\n2. for each row in t ; select non_key_column from tb where …"

"注意: FOR UPDATE 只能用在事务区块(BEGIN/COMMIT)中才有效。 有时候我们会看到一些select语句后面紧跟一句for update，表示手动加锁的意思，这里我们就介绍一下对for update的理解。相对另一种手动加锁方法lock in share mode 的区别见： https://blog.csdn.net/liangzhonglin/article/details/65438777。\nfor update：IX锁(意向排它锁)，即在符合条件的rows上都加了排它锁，其他session也就无法在这些记录上添加任何的S锁或X锁。如果不存在一致性非锁定读的话，那么其他session是无法读取和修改这些记录的，但是innodb有非锁定读(快照读并不需要加锁)，for update之后并不会阻塞其他session的快照读取操作，除了select …lock in share mode和select … for update这种显示加锁的查询操作。\nlock in share mode：是IS锁(意向共享锁)，即在符合条件的rows上都加了共享锁，这样的话，其 …"