• 极客时间-MySQL实战45讲(实践篇)-1


    09 | 普通索引和唯一索引,应该怎么选择?

    查询过程
    InnoDB 的数据是按数据页为单位来读写的。也就是说,当需要读一条记录的时候,并不是将这个记录本身从磁盘读出来,而是以页为单位,将其整体读入内存。在 InnoDB 中,每个数据页的大小默认是 16KB。
    更新过程
    什么是change buffer?
    从MySQL5.5版本开始,Insert buffer更名为change buffer,除了缓冲对二级索引的insert操作,还包括update/delete/后台purge操作,由参数innodb_change_buffering来控制。因此这里统一称为change buffer
    change Buffer和数据页一样,也是物理页的一个组成部分,数据结构也是一颗B+树
    当需要更新一个数据页时,如果数据页在内存中就直接更新,而如果这个数据页还没有在内存中的话,在不影响数据一致性的前提下,InooDB 会将这些更新操作缓存在 change buffer 中,这样就不需要从磁盘中读入这个数据页了。在下次查询需要访问这个数据页的时候,将数据页读入内存,然后执行 change buffer 中与这个页有关的操作。通过这种方式就能保证这个数据逻辑的正确性。
    什么是merge?
    将 change buffer 中的操作应用到原数据页,得到最新结果的过程称为 merge。除了访问这个数据页会触发 merge 外,系统有后台线程会定期 merge。在数据库正常关闭(shutdown)的过程中,也会执行 merge 操作。
    merge 的执行流程是这样的:
    1.从磁盘读入数据页到内存(老版本的数据页);
    2.从 change buffer 里找出这个数据页的 change buffer 记录 (可能有多个),依次应用,得到新版数据页;
    3.写 redo log。这个 redo log 包含了数据的变更和 change buffer 的变更。

    什么条件下可以使用 change buffer 呢?
    对于唯一索引来说,所有的更新操作都要先判断这个操作是否违反唯一性约束。比如,要插入 (4,400) 这个记录,就要先判断现在表中是否已经存在 k=4 的记录,而这必须要将数据页读入内存才能判断。如果都已经读入到内存了,那直接更新内存会更快,就没必要使用 change buffer 了。
    因此,唯一索引的更新就不能使用 change buffer,实际上也只有普通索引可以使用。

    普通索引和唯一索引应该怎么选择。其实,这两类索引在查询能力上是没差别的,主要考虑的是对更新性能的影响。所以,我建议你尽量选择普通索引。
    change buffer 和 redo log?
    如果要简单地对比这两个机制在提升更新性能上的收益的话,redo log 主要节省的是随机写磁盘的 IO 消耗(转成顺序写),而 change buffer 主要节省的则是随机读磁盘的 IO 消耗。

    10 | MySQL为什么有时候会选错索引?

    优化器选择索引的目的,是找到一个最优的执行方案,并用最小的代价去执行语句。在数据库里面,扫描行数是影响执行代价的因素之一。扫描的行数越少,意味着访问磁盘数据的次数越少,消耗的 CPU 资源越少。
    一个索引上不同的值的个数,我们称之为“基数”(cardinality)
    也就是说,这个基数越大,索引的区分度越好。
    MySQL 是怎样得到索引的基数的呢?---采样统计
    优化器没有选择正确的索引,force index 起到了“矫正”的作用

    11 | 怎么给字符串字段加索引?

    mysql> alter table SUser add index index2(email(6));
    使用前缀索引,定义好长度,就可以做到既节省空间,又不用额外增加太多的查询成本。
    其他方式
    第一种方式是使用倒序存储。如果你存储身份证号的时候把它倒过来存,每次查询的时候,你可以这么写:
    mysql> select field_list from t where id_card = reverse('input_id_card_string');
    由于身份证号的最后 6 位没有地址码这样的重复逻辑,所以最后这 6 位很可能就提供了足够的区分度。当然了,实践中你不要忘记使用 count(distinct) 方法去做个验证。
    第二种方式是使用 hash 字段。你可以在表上再创建一个整数字段,来保存身份证的校验码,同时在这个字段上创建索引。
    mysql> alter table t add id_card_crc int unsigned, add index(id_card_crc);
    然后每次插入新记录的时候,都同时用 crc32() 这个函数得到校验码填到这个新字段。由于校验码可能存在冲突,也就是说两个不同的身份证号通过 crc32() 函数得到的结果可能是相同的,所以你的查询语句 where 部分要判断 id_card 的值是否精确相同。

    12 | 为什么我的MySQL会“抖”一下?

    当内存数据页跟磁盘数据页内容不一致的时候,我们称这个内存页为“脏页”。内存数据写入到磁盘后,内存和磁盘上的数据页的内容就一致了,称为“干净页”。
    什么情况会引发数据库的 flush 过程?
    *1.InnoDB 的 redo log 写满了
    *2.系统内存不足。当需要新的内存页,而内存不够用的时候,就要淘汰一些数据页,空出内存给别的数据页使用
    *3.MySQL 认为系统“空闲”的时候。
    InnoDB 刷脏页的控制策略
    一个是脏页比例,你就要合理地设置 innodb_io_capacity 的值,并且平时要多关注脏页比例,不要让它经常接近 75%。
    一个是 redo log 写盘速度。

    13 | 为什么表数据删掉一半,表文件大小不变?

    一个 InnoDB 表包含两部分,即:表结构定义和数据。
    表数据既可以存在共享表空间里,也可以是单独的文件。这个行为是由参数 innodb_file_per_table 控制的。
    从 MySQL 5.6.6 版本开始,它的默认值就是 ON 了。
    表中的数据被删除了,但是表空间却没有被回收。?
    delete 命令其实只是把记录的位置,或者数据页标记为了“可复用”,但磁盘文件的大小是不会变的。也就是说,通过 delete 命令是不能回收表空间的。这些可以复用,而没有被使用的空间,看起来就像是“空洞”
    经过大量增删改的表,都是可能是存在空洞的。所以,如果能够把这些空洞去掉,就能达到收缩表空间的目的。
    而重建表 ---可以释放表空间。
    小结
    如果要收缩一个表,只是 delete 掉表里面不用的数据的话,表文件的大小是不会变的,你还要通过 alter table 命令重建表,才能达到表文件变小的目的。我跟你介绍了重建表的两种实现方式,
    Online DDL 的方式是可以考虑在业务低峰期使用的,而 MySQL 5.5 及之前的版本,这个命令是会阻塞 DML 的,这个你需要特别小心。


    14 | count(*)这么慢,我该怎么办?

    count(*) 的实现方式

    • MyISAM 引擎把一个表的总行数存在了磁盘上,因此执行 count(*) 的时候会直接返回这个数,效率很高;
    • 而 InnoDB 引擎就麻烦了,它执行 count(*) 的时候,需要把数据一行一行地从引擎里面读出来,然后累积计数。
      到这里我们小结一下:
    • MyISAM 表虽然 count(*) 很快,但是不支持事务;
    • show table status 命令虽然返回很快,但是不准确;
    • InnoDB 表直接 count(*) 会遍历全表,虽然结果准确,但会导致性能问题。

    不同的 count 用法?

    对于 count(主键 id) 来说,InnoDB 引擎会遍历整张表,把每一行的 id 值都取出来,返回给 server 层。server 层拿到 id 后,判断是不可能为空的,就按行累加。
    对于 count(1) 来说,InnoDB 引擎遍历整张表,但不取值。server 层对于返回的每一行,放一个数字“1”进去,判断是不可能为空的,按行累加。
    单看这两个用法的差别的话,你能对比出来,count(1) 执行得要比 count(主键 id) 快。因为从引擎返回 id 会涉及到解析数据行,以及拷贝字段值的操作。
    对于 count(字段) 来说:
    如果这个“字段”是定义为 not null 的话,一行行地从记录里面读出这个字段,判断不能为 null,按行累加;
    如果这个“字段”定义允许为 null,那么执行的时候,判断到有可能是 null,还要把值取出来再判断一下,不是 null 才累加。
    也就是前面的第一条原则,server 层要什么字段,InnoDB 就返回什么字段。
    但是 count() 是例外,并不会把全部字段取出来,而是专门做了优化,不取值。count() 肯定不是 null,按行累加。
    看到这里,你一定会说,优化器就不能自己判断一下吗,主键 id 肯定非空啊,为什么不能按照 count() 来处理,多么简单的优化啊。
    当然,MySQL 专门针对这个语句进行优化,也不是不可以。但是这种需要专门优化的情况太多了,而且 MySQL 已经优化过 count(
    ) 了,你直接使用这种用法就可以了。
    所以结论是:* 按照效率排序的话,count(字段)<count(主键 id)<count(1)≈count(),所以我建议你,尽量使用 count()。*


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

    全字段排序
    MySQL 会给每个线程分配一块内存用于排序,称为 sort_buffer。
    MySQL 将需要排序的数据分成 12 份,每一份单独排序后存在这些临时文件中。然后把这 12 个有序文件再合并成一个有序的大文件
    rowid 排序
    覆盖索引是指,索引上的信息足够满足查询请求,不需要再回到主键索引上去取数据。

  • 相关阅读:
    验证码处理函数
    Apache2.2下载及安装
    centos6.4、6.5、7.0环境下载及安装
    数据库实务 实务隔离级别
    InnoDB 锁
    索引常见问题处理
    数据库索引 B-Tree索引 hash索引
    JVM学习-(2)
    jvm学习-(1)
    linux杂记
  • 原文地址:https://www.cnblogs.com/chenbensheng/p/11617960.html
Copyright © 2020-2023  润新知