m0_57408211的博客

表中只有单列字段情况下，varchar一般最多能存放(65535 - 3)个字节，varchar的最大有效长度通过最大行数据长度和使用的字符集来确定，通常的最大长度是65532个字符（当字符串中的字符都只占1个字节时，能达到65532个字符）；而这也有个情况，不是每次都是开辟80字节的空间来存储的。从这个实验来看，是这样:要是插入的大小不足设置的数值20(这里char(N)的N是20）,就只开辟20字节的空间存储，超过20字节了，就开辟实际大小的空间来存储（1e就是十进制30）。

这是操作数据库和表的定义的。

数据库中的事务是指对数据库执行一批操作，而这些操作最终要么全部执行成功，要么全部失败，不会存在部分成功的情况。这个时候就需要用到事务。最经典的例子就是转账，你要给朋友小白转 1000 块钱，而此时你的银行卡只有 1000 块钱。转账过程具体到程序里会有一系列的操作，比如查询余额、做加减法、更新余额等，这些操作必须保证是一体的，不然等程序查完之后，还没做减法之前，你这 1000 块钱，完全可以借着这个时间差再查一次，然后再给另外一个朋友转账，如果银行这么整，不就乱了么？这时就要用到“事务”这个概念了。

因为索引保存的是索引字段的原始值，而不是 id + 1 表达式计算后的值，所以无法走索引，只能通过把索引字段的取值都取出来，然后依次进行表达式的计算来进行条件判断，因此采用的就是全表扫描的方式。创建联合索引时，我们需要注意创建时的顺序问题，因为联合索引 (a, b, c) 和 (c, b, a) 在使用的时候会存在差别。而条件的左侧使用了占位符，导致无法按照正常的目录进行匹配，导致索引失效就很正常了。这里却是使用了索引。因为索引保存的是索引字段的原始值，而不是经过函数计算后的值，自然就没办法走索引了。

一句话简单来说，索引的出现其实就是为了提高数据查询的效率，就像书的目录一样。一本 500 页的书，如果你想快速找到其中的某一个知识点，在不借助目录的情况下，那你可能得找一会儿。同样，对于数据库的表而言，索引其实就是它的“目录”。所以，索引就是提高查询速度的数据结构(有序的)。而能提高查询速度的，说明这些数据是按照一定规则排序好的。索引的优缺点提高数据检索效率，降低数据库的IO成本通过索引列对数据进行排序，降低数据排序的成本，降低CPU的消耗索引列也是要占用空间的。

1大多数人使用mysqly一般都是使用 InnoDB 引擎，这也是默认的表引擎。我们这里讨论的也是默认引擎InnoDB。InnoDB引擎表是数据是存储在磁盘的。那可能会好奇表的每一行是如何存储在磁盘中的呢？行结构是如何的呢？行格式（row_format），就是一条记录的存储结构。InnoDB 提供了 4 种行格式，分别是 Redundant、Compact、Dynamic和 Compressed 行格式。MySQL5.7 版本之后，默认使用 Dynamic 行格式。

前面的修改表结构就是DDL语句。备注：若不了解DDL,可以查看该文章MySQL的SQL语句所有的 DDL 语句都会导致事务隐式提交。即是当你在执行 DDL 语句前，事务就已经提交了。这就意味着带有 DDL 语句的事务将来没有办法 rollback。看例子：在第5步查看结果的时候，发现表和插入的数据都有了，说明回滚没有生效。原因是在第3步，执行DDL语句之前事务就被隐式提交。DDL语句会进行隐式提交，是不能rollback的，所以大家在日常开发中一定要注意。

加锁的规则：一个原则：加锁的基本单位是 next-key lock。加锁是对索引加锁的。一个bug:非唯一索引范围查询，该索引的临键锁不会有退化为间隙锁或记录锁。其他就通过常理来分析推理即可。唯一索引等值查询唯一索引范围查询非唯一索引等值查询非唯一索引范围查询非索引查询。

锁是计算机协调多个进程或线程并发访问某一资源的机制。在 MySQL 里，根据加锁的范围，可以分为三类。

事务是在 MySQL 引擎层实现的，默认的 InnoDB 引擎支持事务。MySQL InnoDB 引擎的默认隔离级别是可重复读(RR)，但不建议将隔离级别升级为串行化，因为这会导致数据库并发时性能很差。针对快照读（普通 select 语句），是通过 MVCC 方式解决了幻读，因为可重复读隔离级别下，事务执行过程中看到的数据，一直跟这个事务启动时看到的数据是一致的，即使中途有其他事务插入了一条数据，是查询不出来这条数据的，所以就很好了避免幻读问题。针对当前读。

这时并不会回滚事务，虽然redo log是处于prepare阶段，但是能通过redolog的数据找到对应的binlog日志，这就是对应q情况2(a），MySQL认为对应的事务binlog是完整的，就会提交事务恢复数据。这个其实是不一定的。写了redolog后，会更新内存中的数据，要是这时进行查询，而数据还在内存中，就直接访问内存即可，不需要去读取磁盘，也不需要把redo log里的数据更新到数据磁盘中。在奔溃恢复时候，会对比磁盘数据页的LSN和checkpoint的LSN，要是其是相等的，就会跳过该页。

的时候，数据库会自动产生一个新的自增序列作为这条记录的ID。这就是我们插入0值ID记录时与期望不符原因。id是自增的，插入id=0的行数据，查看却显示id=10，这说明。因为在数据库表中ID采用了自增ID策略。这里就是记录下这种情况，该文章参考来自。这个情况有官方解释以及解决方案。