怎么给字符串字段加索引？日志系统一条更新语句是怎么执行的

前言

前言
- 一、怎么给字符串字段加索引？
- - 字符串字段加索引的基础
- [二、日志系统一条更新语句是怎么执行的？](#二、日志系统一条更新语句是怎么执行的？)
- - - [redo log](#redo log)
    - binlog

在 MySQL 中，可以对任何 字符型字段 （例如 CHAR, VARCHAR, TEXT）添加索引，目的是加速这些字段的查询。对于 VARCHAR 类型的字段，如果它是 高频查询字段，则加索引能够大幅度提升查询性能。
但是，直接给 全文长字符串 字段（如 TEXT 类型字段）加索引会消耗大量存储，并且性能效果有限。为了避免不必要的开销，可以通过 前缀索引 或 全文索引 来提高效率。

ANALYZE TABLE table_name;

这个命令会更新表的索引统计信息，从而帮助 MySQL 优化器更准确地选择索引。

日志系统有两个重要模块redo log 和binlog

redo log是innodb开发的作为插件的形式存在mysql中。因为mysql开发的引擎是myIsam 并且binlog不存在 crash-safe（异常中断crash）保护。

redo log提供了这个功能，

比如一个更新sql：update table set age = age+1 where id =1

比如一个门店有一个粉笔板和记账的本子，当客户多的时候，如果有人来还账，那么每次都去翻看本子就会很慢，可以直接写到粉笔板上（redo log就在mysql中就是充当了这个粉笔板的角色），等到老板不忙的时候再满满腾挪到记账本上。

同时redo log的内存空间类似于一个闭环的甜甜圈🍩，从一个地方不停的写入满满就会写回开头的位置，如果这个时候前面位置的信息还没有腾挪到记账本当中，这个时候老板就要停下手中的工作，专门把部分数据腾挪到记事本当中，然后继续手中的工作。

binlog是mysql提供的一个数据恢复能力，记录了所有的修改sql，使得重启之后数据能够恢复。

下面看一下一条更新语句update的执行流程

同样客户端通过连接器链接上mysql ，连接器校验用户权限

连接器访问缓存，有值直接返回结果

连接器访问检查器，检查器检查sql语法合法性

检查器访问分析器，分析器指定执行方案

分析器访问执行器，执行器执行技术方案

开始操作存储层，

然后开始通过树结构找到这条id =1的数据将age+1，然后写回。

innodb将sql写入到redo log中处于prepare状态

然后将数据写入到binlog中

然后redo log改为commit事务完成状态。

为什么redo log 两阶段提交。主要是为了两份日志中的数据一致。

先写redo log后写binlog 。假设在redo log写完，binlog还没有写完的时候，MySQL进程异常重启。由于我们前面说过的，redo log写完之后，系统即使崩溃，仍然能够把数据恢复回来，所以恢复后这一行c的值是1。
但是由于binlog没写完就crash了，这时候binlog里面就没有记录这个语句。因此，之后备份日志的时候，存起来的binlog里面就没有这条语句。
然后你会发现，如果需要用这个binlog来恢复临时库的话，由于这个语句的binlog丢失，这个临时库就会少了这一次更新，恢复出来的这一行c的值就是0，与原库的值不同。
先写binlog后写redo log。如果在binlog写完之后crash，由于redo log还没写，崩溃恢复以后这个事务无效，所以这一行c的值是0。但是binlog里面已经记录了"把c从0改成1"这个日志。所以，在之后用binlog来恢复的时候就多了一个事务出来，恢复出来的这一行c的值就是1，与原库的值不同。

问题：如果写入binlog之后，服务出现故障了，那么还能恢复这条数据吗，

答：可以，因为虽然这个事务redo log中并没有提交，但是在binlog中也已经有了，就认为有这条数据，所以这条数据也可以恢复。