分类 mysql 下的文章
innoDB MVCC 实现原理
innoDB通过mvcc(多版本并发控制)来提高并发能力，通过版本快照，保证大部分读操作都不用加锁，性能很好。缺点是缺点是没行记录都需要额外的存储空间，需要做更多的行检查工作，以及一些额外的维护工作。
mysql 系统时间戳
unix_timestamp(now())mysql redolog、undolog、binlog
https://www.cnblogs.com/whgk/p/11066798.html
redolog记录内容
redolog记录的是页修改后的结果，write-ahead-log，替代脏页落盘（顺序IO替代随机IO）。实际是事务T改变了元素X，而X原来的值是v，这样一个T、X、v的三元组。
- type：redolog的类型，8.0有65种。
- spaceID： 表空间
- page number： 页号
- data：把页中哪个位置修改了哪些值。
对于一个更新操作，
- 如果这行数据的字符数发生了变化，就不能就地更新，而应该删除旧记录，插入修改后的纪录。
- 数据页中的记录会按照索引顺序连成一个单向链表，在1产生的变化后，还要对上一条记录的next_record属性进行修改
恢复过程
- 从checkpoint_lsn位置开始读取redolog，来回复脏页和undo log,
mysql是怎么保证数据不丢失的？
redolog和binlog保证持久化到磁盘，就能确保mysql异常重启后数据可以恢复。
binlog写入机制
事务执行过程中，先把日志写到binlog cache中，事务提交的时候再把binlog cache写入binlog文件中。
一个binlog的事务是不能拆开的，不管多大也要确保一次性写入。这就涉及binlog cache的保存。
binlog cache写入有两个过程：
1.write：多线程将binlog cache写入文件系统的page cache，但是并没有写入到磁盘，因此速度较快。
2.fsync：才是数据持久化过程。
write和fsync的时机是由参数sync_binlog控制
1.sync_binlog=0的时候，表示每次提交事务都只write，不fsync
2.sync_binlog=1时，表示每次提交都会fsync
3.sync_binlog=N(N>1)，表示每次提交都write，但是积累n个后才fsync
一般都设置为100-1000，提升性能。对应的风险是，如果主机发生异常重启，会丢失这N个事务的binlog日志。
redolog写入机制
事务执行过程中，先把redolog写入redolog buffer，再将buffer写入到文件系统的page cache，还有没有持久化，最后一步是持久化到磁盘。
为了控制redolog的写入策略，innoDB提供了innoDb_flash_log_at_trx_commit参数来控制，三种可能：
1.=0，每次提交只是把redolog留在buffer
2.=1，每次都持久化到磁盘，
3.=2，每次都写到page cache
innoDB后台线程，每隔1秒会把redolog buffer中的日志，调用write写到page cache，再调用fsync写入磁盘。
注意，事务在执行过程中，redolog也是直接写到redolog buffer中的，这些redo log会被线程写入到page cache。也就是说，一个没有提交的事务的redo log也是可能被持久化到磁盘的。
除了这种情况，还有两个场景会造成没提交的事务持久化到磁盘：
1.redo log buffer占用的空间即将达到innodb_log_buffer_size的一半时，后台线程会主动写盘。但是只写到page cache。
2.并行事务提交的时候，顺带将这个事务的redo log buffer 持久化到磁盘。
问题1：为什么bin log cache是每个线程自己维护，而redo log buffer是全局共享的？
这么设计的原因是：binlog 是不能被打断的，一个事务的binlog必须连续写。因此要整个事务完成后，再一起写到文件。
而redo log没有这个要求，有日志可以写到redo log buffer，还可以搭便车，由其他事务提交时一起写到文件。
SQL 模糊查找%
模糊查找可以用通配符%、_，%表示全部，_表示单个字符。
但是如果要匹配一个百分比字符串该怎么做呢？ 比如字符串"100%"
like中转义字符''失效了
解决方法是 escape '/'
select * from table where rate like '%%%' escape '/';
SQL注入
注入形式
mysql 锁机制
B+树
平衡二叉树
二叉树的查找的时间复杂度是O(log2N)，其查找效率与深度有关，而普通的二叉树可能由于内部节点排列问题退化成链表，这样查找效率就会很低。因此平衡二叉树是更好的选择，因为它保持平衡，即通过旋转调整结构保持最小的深度。其查找的时间复杂度也是O(log2N)。
但实际上，数据库中索引的结构也并非AVL树或更优秀的红黑树，尽管它的查询的时间复杂度很低。
innodb 和 myisam 区别
ISAM是Indexed Sequential Access Method (有索引的顺序访问方法) 的缩写，不支持事务和外键，表级锁，空间压缩，全文索引，select，insert多场景适用。好处是减少磁盘空间，减少磁盘I/O,提升查询性能。
Innodb：支持事务、行级锁、外键，表基于聚簇索引建立，主键查询性能高，InnoDB内部优化，磁盘读取数据的可预测读取，在内存自动创建hash索引来加速读操作的自适应hash索引，加速插入操作的插入缓冲区。 热备份，是其他引擎不具备的。(innodb 5.6版本起支持英文的全文索引，5.7.6支持中日韩的全文索引。)
行级锁
InnoDB的行级锁分为两种类型，共享锁和排他锁。
共享锁(S Lock)：允许事务读一条数据
排它锁(X Lock)：允许事务删除或跟新一条数据
锁兼容：只有两个共享锁
innodb默认情况下对select操作使用一致性非锁定读。
但是某些情况下，需要对select显示加锁
共享锁（S）：SELECT * FROM table_name WHERE ... LOCK IN SHARE MODE
排他锁（X)：SELECT * FROM table_name WHERE ... FOR UPDATE
全文索引
简介
1).MySQL中的全文索引是FultLeXT类型的索引。
2).全文索引只能用于InnoDB或MyISAM表，只能为CHAR、VARCHAR、TEXT列创建。
3).在MySQL 5.7.6中，MySQL提供了支持中文、日文和韩文（CJK）的内置全文ngram解析器，以及用于日文的可安装MeCab全文解析器插件
4).当创建表时，可以在CREATE TABLE语句中给出FULLTEXT索引定义，或者稍后使用ALTER TABLE或CREATE INDEX添加该定义。
5).对于大型数据集，将数据加载到没有FULLTEXT索引的表中然后创建索引要比将数据加载到具有现有FULLTEXT索引的表中快得多。
全文索引的三种类型
- 自然语言搜索将搜索字符串解释为自然语言中短语。
- 布尔全文搜索
- 查询扩展搜索
数据结构： 倒排索引