myIddddd的博客

优化 2：索引上的等值查询，向右遍历时且最后一个值不满足等值条件的时候，next-key lock 退化为间隙锁。优化 1：索引上的等值查询，给唯一索引加锁的时候，next-key lock 退化为行锁。原则 1：加锁的基本单位是 next-key lock。是一个前开后闭区间。一个 bug：唯一索引上的范围查询会访问到不满足条件的第一个值为止。原则 2：查找过程中访问到的对象才会加锁。

(1)、没有用上索引：例如该字段没有索引；由于对字段进行运算、函数操作导致无法用索引。(1)、数据库在刷新脏页，例如 redo log 写满了需要同步到磁盘。2、这条 SQL 语句一直执行的很慢，则有如下原因。1、大多数情况下很正常，偶尔很慢，则有如下原因。(2)、执行的时候，遇到锁，如表锁、行锁。(2)、数据库选错了索引。

表尽可能都要设置主键，主键尽量使用bigint类型，21亿的上限还是有可能达到的，比如魔兽，虽然说row_id上限高达281万亿，但是覆盖数据显然是不可接受的。如果没有设置主键，数据库则会帮我们自动生成一个全局的row_id，新数据会覆盖老数据。如果设置了主键，那么将会报错主键冲突。

通过从InnoDB存储空间分布，delete对性能的影响可以看到，delete物理删除既不能释放磁盘空间，而且会产生大量的碎片，导致索引频繁分裂，影响SQL执行计划的稳定性；为了实现数据归档需求，可以用采用MySQL分区表特性来实现，都是DDL操作，没有碎片产生。另外一个比较好的方案采用Clickhouse，对有生命周期的数据表可以使用Clickhouse存储，利用其TTL特性实现无效数据自动清理。同时在碎片回收时，会耗用大量的CPU，磁盘空间，影响表上正常的DML操作。

如果字符串是索引列，而条件语句中的输入参数是数字的话，那么索引列会发生隐式类型转换，由于隐式类型转换是通过 CAST 函数实现的，等同于对索引列使用了函数，所以就会导致索引失效。在 WHERE 子句中，如果在 OR 前的条件列是索引列，而在 OR 后的条件列不是索引列，那么索引会失效。联合索引要能正确使用需要遵循最左匹配原则，也就是按照最左优先的方式进行索引的匹配，否则就会导致索引失效。当我们在查询条件中对索引列进行表达式计算，也是无法走索引的。当我们在查询条件中对索引列使用函数，就会导致索引失效。

binlog刷盘分为两步，先把binlog从binlog cache写到内存的binlog文件，调用fsync持久化至磁盘。在备库上，若是同时处于prepare状态的事务，则可以并行执行。主库是多线程执行，备库是单线程执行解析relay log。log传送开销小，消费relay log 超时。其中，分发可以为按表复制 或者 按行复制。3，同个线程先后执行的两个事务不能并行。binlog传送至大数据系统，供分析。增加从库数量，应对分析SQL。2，没有修改同行的事务并行。备库承担更多SQL分析。

两种格式混合使用，有数据风险的语句用ROW，无风险的使用statement。由于主备库对于SQL的配置可能不一致导致执行可能不一致，有数据安全风险。不是物理日志，是逻辑日志，占空间较大。记录的是SQL语句原文。

对网络延迟有要求，可以保证日志送到备库，不易丢失数据。可以调整超时时间，若超过超时时间则切换为异步复制。：对网络延迟要求小，不能保证日志被送到备库，可能丢失数据。： 需要共识依赖算法。

2，主动死锁检测：innodb_deadlock_detect，发现死锁时回滚代价较小的事务进行回滚。1，调整innodb_lock_wait_timeout参数，对获取。3，MDL（元数据锁）锁hold住大量事务，导致mysql奔溃。1，行级锁长时间无法释放，导致其他事务等待。的等待时间，若等待50秒还没获取锁则报错。主要危害：锁无法释放。

我们在使用mysql的时，有时候会突然卡一下，仿佛是我们在用GO语言时的垃圾回收。实际上，mysql是用C写的，没有垃圾回收机制。那为什么无故卡一下？刷脏页就是将内存中的数据页保存至磁盘，同时，删除此页相关的redo log，推进check point。2，redo log 文件写满，想要推进check point。你会发现此时磁盘IO很高，说明mysql正在”刷脏页“。3，系统空闲，提前刷脏，预防上诉情况。1，内存中脏页太多，内存不足。4，mysql关闭前，保存数据。

解决方案：时间函数转区间，数字强转字符串，高级编码转低级。mysql中，对索引字段做函数操作，优化器会放弃索引。这种情况可能包括：时间函数，字符串转数字，字符编码转换。

order by 步骤原理：根据where等条件查询将查询结果放入sort_buffer将中间结果集按照order字段排序回表生产完整结果集（若需要）

mysql专门优化count（*）直接返回索引树中数据的个数，跳过server层。可以索引覆盖，依然需要判断字段是否为NULL。注意：这里使用主键或者非空索引，依然需要server判断是否为空，因为判空这个动作是在server上。1.server层需要判断每个数据是否为NULL。2，走聚簇索引，解析出每一行数据。无法使用覆盖索引，理论上最慢。count（1）只扫描索引树，没有解析数据行的过程，理论更快。但server依然需要判断“1是否为NULL”。逐个结果判断是否为NULL，不为NULL则加1。

索引组织表（index organized table） InnoDB中，表都是根据主键顺序存放的，索引组织表是由索引组织起来的表。索引是数据库中对某一列或者多个列的值进行预排序的数据结构，索引可以称为数据的目录，InnoDB中，主键是一个特殊的索引字段。InnoDB的索引分为聚簇索引（主索引）和辅助索引，在同层B+树节点之间为双向列表，在节点之内数据条目之间为单向链表。根据表的主键构造一个B+树，叶子结点直接存放行数据，而不是指针，索引组织表中，数据也是B+树的一部分。

页是 lnnoDB中磁盘和内存交互的基本单位，也是 lnnoDB管理存储空间的基本单位在COMPACT行格式下，变长字段长度列表只是用来存放一条记录 中各个变长字段 的值占用的字节长度的。设计 COMPACT 行格式的大叔还规定，采用变长编码字符集的 CHAR问类型的列要求至少占用M个字节， 而VARCHAR例却没有这个要求