tablefilter

一、SQL的where条件提取规则 在ICP（Index Condition Pushdown，索引条件下推）特性之前，必须先搞明白根据何登成大神总结出一套放置于所有SQL语句而皆准的where查询条件的提取规则：所有SQL的where条件，均可归纳为3大类：Index Key (First Key & Last Key)，Index Filter，Table Filter。 接下来，简单说一下这3大类分别是如何定义，以及如何提取的，详情请看： SQL语句中where条件在数据库中提取与应用浅析 。 Index Key(Fist key & Last Key)，Index Filter，Table Filter Index First Key 只是用来定位索引的起始范围，因此只在索引第一次Search Path(沿着索引B+树的根节点一直遍历，到索引正确的叶节点位置)时使用，一次判断即可； Index Last Key 用来定位索引的终止范围，因此对于起始范围之后读到的每一条索引记录，均需要判断是否已经超过了Index Last Key的范围，若超过，则当前查询结束； Index Filter 用于过滤索引查询范围中不满足查询条件的记录，因此对于索引范围中的每一条记录，均需要与Index Filter进行对比，若不满足Index Filter则直接丢弃，继续读取索引下一条记录；

一、前言 在MySQL中进行SQL优化的时候，经常会在一些情况下，对MySQL能否利用索引有一些迷惑。 譬如: MySQL 在遇到范围查询条件的时候就停止匹配了，那么到底是哪些范围条件？ MySQL 在LIKE进行模糊匹配的时候又是如何利用索引的呢？ MySQL 到底在怎么样的情况下能够利用索引进行排序？ 今天，我将会用一个模型，把这些问题都一一解答，让你对MySQL索引的使用不再畏惧 二、知识补充 key_len EXPLAIN执行计划中有一列 key_len 用于表示本次查询中，所选择的索引长度有多少字节，通常我们可借此判断联合索引有多少列被选择了。 在这里 key_len 大小的计算规则是： 一般地，key_len 等于索引列类型字节长度，例如int类型为4 bytes，bigint为8 bytes； 如果是字符串类型，还需要同时考虑字符集因素，例如：CHAR(30) UTF8则key_len至少是90 bytes； 若该列类型定义时允许NULL，其key_len还需要再加 1 bytes； 若该列类型为变长类型，例如 VARCHAR（TEXT\BLOB不允许整列创建索引，如果创建部分索引也被视为动态列类型），其key_len还需要再加 2 bytes; 三、哪些条件能用到索引 首先非常感谢登博，给了我一个很好的启发，我通过_他的文章_，然后结合自己的理解，制作出了这幅图

感谢关注 趣学程序 ！公众号内部回复 666 获取 热门教程 写操作执行过程 　　 如果这条sql是写操作(insert、update、delete)，那么大致的过程如下，其中引擎层是属于 InnoDB 存储引擎的，因为InnoDB 是默认的存储引擎，也是主流的，所以这里只说明 InnoDB 的引擎层过程。由于写操作较查询操作更为复杂，所以先看一下写操作的执行图。方便后面解析。 0x01: 组件介绍 Server层 1、连接器 　　1）负责与客户端的通信，是半双工模式，这就意味着某一固定时刻只能由客户端向服务器请求或者服务器向客户端发送数据，而不能同时进行。 　　2）验证用户名和密码是否正确（数据库mysql的user表中进行验证），如果错误返回错误通知（deAcess nied for user 'root'@'localhost'（using password：YES）），如果正确，则会去 mysql 的权限表（mysql中的 user、db、columns_priv、Host 表，分别存储的是全局级别、数据库级别、表级别、列级别、配合 db 的数据库级别）查询当前用户的权限。 2、缓存（Cache） 　　也称为查询缓存，存储的数据是以键值对的形式进行存储，如果开启了缓存，那么在一条查询sql语句进来时会先判断缓存中是否包含当前的sql语句键值对，如果存在直接将其对应的结果返回

序 本文主要研究一下SpinalTap的MysqlEventFilter MysqlEventFilter SpinalTap/spinaltap-mysql/src/main/java/com/airbnb/spinaltap/mysql/event/filter/MysqlEventFilter.java public abstract class MysqlEventFilter implements Filter<BinlogEvent> { public static Filter<BinlogEvent> create( @NonNull final TableCache tableCache, @NonNull final Set<String> tableNames, @NonNull final AtomicReference<SourceState> state) { return ChainedFilter.<BinlogEvent>builder() .addFilter(new EventTypeFilter()) .addFilter(new TableFilter(tableCache, tableNames)) .addFilter(new DuplicateFilter(state)) .build(); } }

在上一篇文章 《MySQL常见加锁场景分析》 中，我们聊到行锁是加在索引上的，但是复杂的 SQL 往往包含多个条件，涉及多个索引，找出 SQL 执行时使用了哪些索引对分析加锁场景至关重要。 比如下面这样的 SQL： mysql> delete from t1 where id = 1 or val = 1 其中 id 和 val 都是索引，那么执行时使用到了哪些索引，加了哪些锁呢？为此，我们需要使用 explain 来获取 MySQL 执行这条 SQL 的执行计划。 什么是执行计划呢？简单来说，就是 SQL 在数据库中执行时的表现情况，通常用于 SQL 性能分析、优化和加锁分析等场景，执行过程会在 MySQL 查询过程中由解析器，预处理器和查询优化器共同生成。 MySQL 查询过程 如果能搞清楚 MySQL 是如何优化和执行查询的，不仅对优化查询一定会有帮助，还可以通过分析使用到的索引来判断最终的加锁场景。 下图是MySQL执行一个查询的过程。实际上每一步都比想象中的复杂，尤其优化器，更复杂也更难理解。本文只给予简单的介绍。 MySQL查询过程如下： 客户端发送一条查询给服务器。 服务器先检查查询缓存，如果命中了缓存，则立刻返回存储在缓存中的结果。否则进入下一阶段。 服务器端进行SQL解析、预处理，再由优化器生成对应的执行计划。 MySQL根据优化器生成的执行计划

背景 MySQL中SQL加锁的情况十分复杂，不同隔离级别、不同索引类型、索引是否命中的SQL加锁各不相同。 然而在分析死锁过程当中，熟知各种情况的SQL加锁是分析死锁的关键，因此需要将MySQL的各种SQL情况加锁进行分析总结。 基础知识 MVCC 快照读 读取历史版本，从undo log中读取行记录的快照；这样读行就不需要等待锁资源，提高了并发； 当前读 读取最新版本，并且当前读返回的记录，都会加上锁，保证其他事务不会再并发修改这条记录。 加锁读、插入、更新、删除等操作均属于当前读 将插入，更新，删除归为当前读是因为这些操作均包含读取当前记录的操作。拿update table set ? where ？来讲， 当Update SQL被发给MySQL后，MySQL Server会根据where条件，读取第一条满足条件的记录，然后InnoDB引擎会将第一条记录返回，并加锁 (current read)。 待MySQL Server收到这条加锁的记录之后，会再发起一个Update请求，更新这条记录。一条记录操作完成，再读取下一条记录，直至没有满足条件的记录为止。 因此，Update操作内部，就包含了一个当前读。同理，Delete操作也一样。Insert操作会稍微有些不同，简单来说，就是Insert操作可能会触发Unique Key的冲突检查，也会进行一个当前读。 注意：

解决Kafka-Connect History 数据过大的情况： 由于History存放是表结构变更的数据，而且过期时间为无限，所以时间久了，History的topic会变得非常大。 首先，配置 database.history.store.only.monitored.tables.ddl = true。该配置根据table filter，来减少记录到history topic的数据。(可以减少很多) 最后，如果history topic实在是过大，可以重新创建一个topic，并通过schema_only_recovery来重启connector。由于binlog offset信息存储在connector的topic里面，所以不会触发initial等问题。 来源： oschina 链接： https://my.oschina.net/dacoolbaby/blog/3191882