maybe的博客

最近有个需求，一张主表4张子表，主表添加数据后，4张子表分表要批量新增多条记录。比如：Person insert一条记录；childOne,childTwo,childThree,childFour4张表分别添加10条记录。由此引发的批量操作的几种方式的性能测试。搭建一个测试spring boot2.4.4项目mybatis依赖<dependency> <groupId>com.baomidou</groupId>

遇到一个线上问题，应用执行sql报错，排查mysql:select * from information_schema.innodb_trx;select * from information_schema.INNODB_LOCKS;select * from information_schema.INNODB_LOCK_WAITS;select * from processlist;发现在trx表中存在一个事务trx_strated已经很长时间了，占用了很多表。怀疑是事务开启未commit

请求−−>缓存−−>解析器−−>预处理器−−>查询优化器−−>将解析树生成执行计划−−>执行计划调用存储引擎API执行 −−>索引或查询数据表−−>响应数据缓存一个对英文大小写敏感的hash表。对sql做hash运算，精确匹配。 缓存命中，则不执行后续解析、预处理、优化。但在返回数据前会校验权限。sql解析器将sql解析按关键字解析成解析树，然后校验：是否存在错误的关键字 关键字顺序是否正确 引号是否匹配...

sleep，等待客户端发送新请求 query，正在执行查询或者正在发送结果到客户端 locked ，正在等待表锁，mysql服务器级别锁。Innodb的行锁属于存储引擎级别锁，不在此范围内 sorting result，正在对结果排序 还有其他状态不常见...

索引三星系统如果索引能够将数据相关的行放到一起，则获得一星。即索引将数据排序、区域集中、可以减少IO复杂度。 索引的数据顺序和查询的排列顺序一致。根据最左前缀原则，如果索引建立1，2，3；查询使用3，2，1；则不会使用到索引。所以索引建立要和查询排序一致。 索引中的列包含了查询中全部需要的列（即select 后面要查询的列），如Innodb根据一个普通索引查询主键值（select id from table where name = ‘wm’）。普通索引中保存了聚簇索引的值。而只查询聚簇索引值.

前缀索引针对blob、text、很长的varchar字段，mysql不支持索引他们的全部长度。需建立前缀索引 前缀索引应该足够长，使前缀索引的选择性趋紧于索引整个列的选择性。 前缀索引又不能太长，降低索引的大小，减少空间占用。 Alter table tableName add key/index (column(X)). 缺点：无法应用于order by 和 group by，也无法做覆盖扫描。计算合适前缀长度方法：先计算比对整列统计数和前缀列统计数select coun..

创建数据库即在数据目录下创建一个子目录创建表即在子目录中创建一个.frm文件保存该表定义查看表定义show table status like ‘order’ 查询information_schema表优化表索引optimize table清除可变列varchar这类的列因为修改而占用的多余空间清除因为删除数据导致的页的碎片化...

范式化--schema设计趋向于符合三范式优点更少或者没有数据冗余 因为第1点，所以数据更新只更新一个字端。意味着更快的更新速度。 表体积更小 查询多数无需distinct去重缺点表数量更多 因为第1点，需要建立更多的索引 多数查询都需要多表关联！！！ 因为第3点，关联查询极有可能导致索引无效反范式化优点数据在一个表，避免关联查询的性能消耗 减少多表建立索引开销 最差情况：查询时全表扫描，也大概率是顺序IO；比关联查询的随机IO快...

在B-tree基础上改造为B+tree 节点页保存叶子页引用 叶子页上保存整行数据 叶子页上也有节点页上的索引及索引的行数据 叶子页之间互有引用 Innodb默认主键位聚簇索引；如果没有主键、有唯一性索引，则使用唯一索引做聚簇索引；如果也没有唯一性索引则默认建立一个隐藏主键做聚簇索引 MyISAM主键则不是聚簇索引，只是普通唯一性索引。 如果有需要聚簇在一起的数据，使用该字段做聚簇索引；否则尽可能使用无意义自增列做聚簇索引。优点物理上连续 顺序IO 可视为“数据表”，索引..

即建立索引时使用一个列 字段不能是表达式一部分 字段不能是函数的参数

将被索引的列进行hash计算，形成一个散列表，用于精确查找，不支持范围、排序、group by查找。自定义hash索引即自己实现hash计算和存储。在表中添加一个列，用来保存要被索引的字段的hash值。添加时对字段进行hash计算保存。当今高并发的场景下，不推荐mysql中进行条件判断、函数运算。所以不推荐使用，...

Innodb存储引擎支持事务，所以崩溃后可以通过事务日志恢复数据。数据存储在Innodb黑盒的表空间tablespace数据和索引存放在单独的文件中实现了标准的四个隔离级别默认RR，通过MVCC+间隙锁防止幻读间隙锁MVCC会锁定涉及到的数据行间隙锁会对索引中，间隙进行锁定，防止幻影行的插入回表Innodb主键为聚集索引，聚集索引的节点上存放了整行数据。其他索引为非聚集索引，非聚集索引叶子结点只存放聚集索引。回表即：当通过非聚集索...

tinyint 8bit -128-127/0-255 smallint 16bit mediumint 24bit int 32bit 21亿左右/42亿左右 bigint 64bit 9223...

存储引擎修改数据时只修改内存拷贝，再把该修改行为记录到磁盘上的事务日志中。而不是每次都将修改的数据本身持久化到磁盘。事务日志记录属于追加行为，顺序IO，而直接持久化数据本身需要频繁挪动硬盘磁头，属于随机IO。顺序IO比随机IO快很多。事务日志持久化后，内存中数据可以慢慢的刷回磁盘中。称之为预写式日志。如果事务只持久化到了事务日志并未刷回磁盘服务器崩溃，当数据库重启时会自动刷回这部分数据。...

MVCC—多版本并发控制原理：保存数据在某个时间点的快照。即不同时间点开启的多个事务，对于同一张表的同一个数据看得到有可能都不一样。Innodb的MVCC实现每行记录后面保存两个隐藏列，一个保存行的创建时间，一个保存行过期时间，虽然说是时间，但其实他们存储的是系统版本号。个人猜测是时间戳的毫秒数。 每当开启一个新的事务系统版本号会进行递增。也就是时间戳递增。当前系统版本号也会作为当前事务版本号。 SELECT会附加查询条件：a，查询行创建时间字段小于当前事务版本号的数据。保...

锁分类读锁read lock=共享锁 shared lock多个客户端可以在同一时间读取同一资源写锁white lock=排他锁 exclusive lock当某个线程获取到写锁时将阻塞其他线程获取读锁和写锁，直到放开。 写锁优先级高， 写锁插队，写锁请求会插队到读锁队列前面，而读锁请求不能插队到写锁前面。锁粒度表锁阻塞对表的所有增删改操作 强制表锁，例如Alter等ddl行锁最大程度支持并发 只在存储引擎层面实现...

数据允许范围内使用更小的数据类型占用更少的磁盘、内存、CPU缓存；消耗的Cpu时钟周期更少。尽可能选择简单数据类型简单数据类型占用更少CPU时钟周期。字符串的检验规则和排序规则更复杂。例如：状态字段使用整型代替状态字符串 使用Mysql内置的时间代替字符串保存时间。 用整型存储IP地址。避免字段可为NULLNull值会占用额外的存储空间。innodb会使用单独的bit来存储Null值。有NULL值的列建立索引，会导致固定大小的索引列变...

timestamp date time 占用4字节 占用8字节 与时区无关 与时区有关 格林尼治标准时间到现在的毫秒数 ANSI标准时间定义 1970-2038 1001-9999任意时间 timestamp精确到秒：可以通过timestamp(3)精确到毫秒 ...

varchar char 类型 可变字符串 定长字符串 空格 varchar会保留字符串末尾空格 默认去除末尾空格 空间分配 用多少分配多少，数据添加时根据实际长度分配存储空间 预先分配足够空间，没用到的空间，末尾补空格。总是分配足够的存储空间 ...