MySQL实战45讲（16--20）-笔记

目录

• 16 | “order by”是怎么工作的？
  • 全字段排序
  • rowid 排序
• 17 | 如何正确地显示随机消息？
  • 内存临时表
  • 磁盘临时表
  • 随机排序方法
• 18 | 为什么这些SQL语句逻辑相同，性能却差异巨大？
  • 小结
• 19 | 为什么我只查一行的语句，也执行这么慢？
  • 第一类：查询长时间不返回
  • 第二类：查询慢
• 20 | 幻读是什么，幻读有什么问题？

笔记做的不好，因为还是又不少地方没有能够理解。见谅，后面理解了在更新…………

16 | “order by”是怎么工作的？

场景：

CREATE TABLE `t` (
	`id` int(11) NOT NULL,
	`city` int(11) NOT NULL,
	`name` varchar(16) NOT NULL,
	`age` int(11) NOT NULL,
	`addr` varchar(128) DEFAULT NULL,
	PRIMARY KEY (`id`),
	KEY `city` (`city`)
) ENGINE=InnoDB;

select city,name,age from t where city='杭州' order by name limit 1000 ;

全字段排序

Extra 这个字段中的“Using filesort”表示的就是需要排序，MySQL 会给每个线程分配一块内存用于排序，称为 sort_buffer。

图中“按 name 排序”这个动作，可能在内存中完成，也可能需要使用外部排序，这取决于排序所需的内存和参数 sort_buffer_size。

可以用这个语句来确定一个排序语句是否使用了临时文件：

/* 打开 optimizer_trace，只对本线程有效 */
SET optimizer_trace='enabled=on';

/* @a 保存 Innodb_rows_read 的初始值 */
select VARIABLE_VALUE into @a from performance_schema.session_status where variable_name = 'Inndb'

/* 执行语句 */
select city, name,age from t where city='杭州' order by name limit 1000;

/* 查看 OPTIMIZER_TRACE 输出 */
SELECT * FROM `information_schema`.`OPTIMIZER_TRACE`\G

/* @b 保存 Innodb_rows_read 的当前值 */
select VARIABLE_VALUE into @b from performance_schema.session_status where variable_name = 'Innodb'

/* 计算 Innodb_rows_read 差值 */
select @b-@a

number_of_tmp_files 表示的是，排序过程中使用的临时文件数。

MySQL会将需要排序的文件分割成多份，小份单独排序后合一。（sort_buffer_size 越小，需要分成的份数越多，

number_of_tmp_files 的值就越大。）

rowid 排序

MySQL 认为排序的单行长度太大 会使用 这个参数 max_length_for_sort_data 来提示MySQL要换一个算法。

过程：因为多了一次索引，排序使用的字段少了，所以数据量就下来了，相应的所需要的临时文件也变少了。

17 | 如何正确地显示随机消息？

场景：

英语学习App  每天  根据用户的级别推荐  随机的单词

随着单词表的变大，这个操作越来越慢

mysql> CREATE TABLE `words` (
	`id` int(11) NOT NULL AUTO_INCREMENT,
	`word` varchar(64) DEFAULT NULL,
	PRIMARY KEY (`id`)
) ENGINE=InnoDB;

内存临时表

order by rand() 来实现这个逻辑。

mysql> select word from words order by rand() limit 3;

一个结论：对于 InnoDB 表来说，执行全字段排序会减少磁盘访问，因此会被优先选择。

如果你创建的表没有主键，或者把一个表的主键删掉了，那么 InnoDB 会自己生成一个长度为 6 字节的 rowid 来作为主键。

这也就是排序模式里面，rowid 名字的来历。

实际上它表示的是：每个引擎用来唯一标识数据行的信息。

• 对于有主键的 InnoDB 表来说，这个 rowid 就是主键 ID；
• 对于没有主键的 InnoDB 表来说，这个 rowid 就是由系统生成的；
• MEMORY 引擎不是索引组织表。

在这个例子里面，你可以认为它就是一个数组。因此，这个 rowid 其实就是数组的下标。

order by rand() 使用了内存临时表，内存临时表排序的时候使用了 rowid 排序方法。

磁盘临时表

不是所有的临时表都是内存表。

tmp_table_size 这个配置限制了内存临时表的大小，默认值是 16M。如果临时表大小超过了 tmp_table_size，那么内存临时表就会转成磁盘临时表。

磁盘临时表使用的引擎默认是 InnoDB，是由参数 internal_tmp_disk_storage_engine 控制的。

当使用磁盘临时表的时候，对应的就是一个没有显式索引的 InnoDB 表的排序过程。

MySQL 5.6 版本引入的一个新的排序算法，即：优先队列排序算法

但是如果超过了我设置的 sort_buffer_size 大小，所以只能使用归并排序算法，因为要维护的堆太大了。

随机排序方法

mysql> select count(*) into @C from t;
set @Y1 = floor(@C * rand());
set @Y2 = floor(@C * rand());
set @Y3 = floor(@C * rand());
select * from t limit @Y1，1； // 在应用代码里面取 Y1、Y2、Y3 值，拼出 SQL 后执行
select * from t limit @Y2，1；
select * from t limit @Y3，1；

18 | 为什么这些SQL语句逻辑相同，性能却差异巨大？

在 MySQL 中，有很多看上去逻辑相同，但性能却差异巨大的 SQL 语句。对这些语句使用不当的话，就会不经意间导致整个数据库的压力变大。

案例一：条件字段函数操作

更新中…………

小结

对索引字段做函数操作，可能会破坏索引值的有序性，因此优化器就决定放弃走树搜索功能。

MySQL 的优化器确实有“偷懒”的嫌疑，即使简单地把 where id+1=1000 改写成 whereid=1000-1 就能够用上索引快速查找，也不会主动做这个语句重写。

因此，每次你的业务代码升级时，把可能出现的、新的 SQL 语句 explain 一下，是一个很好的习惯。

19 | 为什么我只查一行的语句，也执行这么慢？

场景：

mysql> CREATE TABLE `t` (
	`id` int(11) NOT NULL,
	`c` int(11) DEFAULT NULL,
	PRIMARY KEY (`id`)
) ENGINE=InnoDB;

在里面插入了 10 万行记录

第一类：查询长时间不返回

mysql> select * from t where id=1;

一般碰到这种情况的话，大概率是表 t 被锁住了。

接下来分析原因的时候，一般都是首先执行一下 show processlist 命令，看看当前语句处于什么状态。

然后我们再针对每种状态，去分析它们产生的原因、如何复现，以及如何处理。

• 等 MDL 锁

• 等 flush

• 等行锁

第二类：查询慢

20 | 幻读是什么，幻读有什么问题？

https://www.cnblogs.com/zwtblog/p/15134977.html

https://www.cnblogs.com/zwtblog/p/15132201.html#基本语法

幻读

在同一个事务内,读取到了别人插入的数据,导致前后读出来结果不一致

如何解决幻读？

现在你知道了，产生幻读的原因是，行锁只能锁住行，

但是新插入记录这个动作，要更新的是记录之间的“间隙”。因此，为了解决幻读问题，InnoDB 只好引入新的锁，也就是间隙锁 (GapLock)。

顾名思义，间隙锁，锁的就是两个值之间的空隙。

间隙锁的引入，可能会导致同样的语句锁住更大的范围，这其实是影响了并发度的。