小识的博客

开启慢查询日志在项目中我们会经常遇到慢查询，当我们遇到慢查询的时候一般都要开启慢查询日志，并且分析慢查询日志，找到慢sql，然后用explain来分析系统变量MySQL和慢查询相关的系统变量如下参数含义slow_query_log是否启用慢查询日志， ON为启用，OFF为没有启用，默认为OFFlog_output日志输出位置，默认为FILE，即保存为文件，若设置为TABLE，则将日志记录到mysql.show_log表中，支持设置多种格式slow_query_l.

报警阈值：threads_connected / max_connections > 0.8。Innodb_buffer_pool_read_requests：从缓存池中读取的次数。Innodb_buffer_pool_reads：从物理磁盘读取的次数。qps = (queries2- queries1) / 时间间隔。周期性的连接数据库并执行select @@version。使用pt-deadlock-logger工具。查看最近一次死锁信息。

MySQL在选取索引时，会参考索引的基数，基数是MySQL估算的，反映这个字段有多少种取值，估算的策略为选取几个页算出取值的平均值，再乘以页数，即为基数。count(索引字段)：可以使用覆盖索引但依然要取出数据判空。count(1)：不需要取出数据，但需要判断1是否为null。count(*)：经过专门优化，不需要判空，理论最快。count(非索引字段)：无法使用覆盖索引，最慢。使用force index可以强制使用索引。重新统计索引信息，会重新计算索引的基数。

CREATE TABLE `demo_table` ( `id` int(11) NOT NULL AUTO_INCREMENT, `val` int(11) NOT NULL, `name` varchar(20) NOT NULL, PRIMARY KEY (`id`) USING BTREE, KEY `idx_val` (`val`)) ENGINE=InnoDB DEFAULT CHARSET=utf8;insert into demo_table (val, name.

MySQL数据存储和查询流程这些数据最终会持久化到文件中，那么这些数据在文件中是如何组织的？难道是一行一行追加到文件中的？其实并不是，数据其实是存到页中的，一页的大小为16k，一个表由很多页组成，这些页组成了B+树页：页是innodb磁盘管理的基本单位，innodb每个页的大小为16k区：由64个连续的页组成，每个页的大小为16kb，即每个区大约为1MB段：常见的段有数据段（B+树页节点），索引段（B+树非页节点），回滚段等参考博客...

介绍参考博客[1]

并发场景最近做了一些分布式事务的项目，对事务的隔离性有了更深的认识，后续写文章聊分布式事务。今天就复盘一下单机事务的隔离性是如何实现的？隔离的本质就是控制并发，如果SQL语句就是串行执行的。那么数据库的四大特性中就不会有隔离性这个概念了，也就不会有脏读，不可重复读，幻读等各种问题了对数据库的各种并发操作，只有如下四种，写写，读读，读写和写读写-写事务A更新一条记录的时候，事务B能同时更新同一条记录吗？答案肯定是不能的，不然就会造成脏写问题，那如何避免脏写呢？答案就是加锁读-读MySQL读操.

MVCC有啥作用？对于使用InnoDB存储引擎的表来说，聚集索引记录中都包含下面2个必要的隐藏列trx_id：一个事务每次对某条聚集索引记录进行改动时，都会把该事务的事务id赋值给trx_id隐藏列roll_pointer：每次对某条聚集索引记录进行改动时，都会把旧的版本写入undo日志中。这个隐藏列就相当于一个指针，通过他找到该记录修改前的信息如果一个记录的name从貂蝉被依次改为王昭君，西施，会有如下的记录，多个记录构成了一个版本链先回顾一下隔离级别的概念，这样看后面的内容不至于发懵√ .

CREATE TABLE `demo_table` ( `id` int(11) NOT NULL AUTO_INCREMENT, `val` int(11) NOT NULL, `name` varchar(20) NOT NULL, PRIMARY KEY (`id`) USING BTREE, KEY `idx_val` (`val`)) ENGINE=InnoDB DEFAULT CHARSET=utf8;insert into demo_table (val, name.

Buffer pool的构成如下如何知道哪个缓存页没有使用？单纯的lru链表有很多问题mysql> SHOW VARIABLES LIKE 'innodb_old_blocks_pct';+-----------------------+-------+| Variable_name | Value |+-----------------------+-------+| innodb_old_blocks_pct | 37 |+-------------..

MySQL数据存储和查询流程加入说现在我们建了如下一张表CREATE TABLE `student` ( `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '学号', `name` varchar(10) NOT NULL COMMENT '学生姓名', `age` int(11) NOT NULL COMMENT '学生年龄', PRIMARY KEY (`id`), KEY `idx_name` (`name`)) ENGINE=Inn.

参考博客[1]https://mp.weixin.qq.com/s/EybebcYX4i13r5nDRG14fg[2]https://juejin.cn/post/7053966777088213005

介绍参考博客[1]https://mp.weixin.qq.com/s/yUrq3UfCKP91jRp9VEFT6w

explain的使用possilbe_keys针对一个表进行查询时，有哪些潜在可以使用的索引。比如你有2个索引key(x1,x2,x3)和key(x1,x2,x4)，此时在where语句中要根据x1和x2进行查询，很明显2个索引都能使用，那么使用哪个索引呢？通过我们之前分享的成本优化方法，去估算使用2个索引进行查询的成本，看使用哪个索引的成本更低，就使用哪个索引，最终选择的索引就是key这个字段的值key实际使用到的索引key_len索引的长度，用于判断联合索引是否被完全使用建立如下的表.

使用存储过程造测试数据CREATE TABLE single_table ( id INT NOT NULL AUTO_INCREMENT, key1 VARCHAR(100), key2 INT, key3 VARCHAR(100), key_part1 VARCHAR(100), key_part2 VARCHAR(100), key_part3 VARCHAR(100), common_field VARCHAR(100), P

三种join的方式Simple Nested-Loop JoinBlock Nested-Loop JoinIndex Nested-Loop Join参考博客[1]

索引的种类众所周知，索引类似于字典的目录，可以提高查询的效率。索引从物理上可以分为：聚集索引，非聚集索引从逻辑上可以分为：普通索引，唯一索引，主键索引，联合索引，全文索引索引优化策略不要在索引列上进行运算或使用函数在列上进行运算或使用函数会使索引失效，从而进行全表扫描。如下面例子在publish_time，id列上分别加上索引，publish_time为datetime类型，id为int类型-- 全表扫描select * from article where year(publish_ti.

如何分析慢sql？在工作中，我们用于捕捉性能问题最常用的就是打开慢查询日志，定位执行效率差的SQL，那么当我们定位到一个SQL以后还不算完事，我们还需要知道该SQL的执行计划，比如是全表扫描，还是索引扫描，这些都需要通过EXPLAIN去完成。EXPLAIN命令是查看优化器如何决定执行查询的主要方法。需要注意的是，生成的QEP并不确定，它可能会根据很多因素发生改变。MySQL不会将一个QEP和某个给定查询绑定，QEP将由SQL语句每次执行时的实际情况确定，即便使用存储过程也是如此。尽管在存储过程中SQL.