xsgnzb的专栏

json列能添加多值索引，提高了json的查询性能。同时因为索引要指定列的类型，索引列就不能使用任意类型，这会失去一部分schemaless的能力。需要注意的是，使用cast函数添加索引时，要选择合适type，不然会出现类型转换失败的异常。

起因是线上报了一个错误信息，Deadlock found when trying to get lock;try restarting transaction，这是Mysql检测到死锁后，自动回滚了事务引发的异常。spring框架里打印了异常堆栈，所以很快就定位到哪一行代码出了问题。看了代码逻辑，只有insert的时候会加一个行锁，死锁要有两个锁被多个线程账户等待，才会发生。就算有并发的情况，同时插入两条一样的记录，第二个事务也是处于等待锁的状态，等待锁超时后就报获取锁超时，也不会发生死锁。

要判断主从严格一致的成本是很高的，用到GTID来判断主从延迟，对代码的侵入性很高，而且要额外的查询GTID和判断GTID是否同步，性能也会受到影响。如果业务场景对一致性要求很高，为了简化编程，还不如直接查主库。如果对一致性要求不高，直接读从库，或者等待1秒也是不错的方式。

读写分离是快速提高数据库性能的手段，主库只负责写入，从库负责查询。但在性能得到提升的同时，编程的复杂度就会提升。由其碰到主从同步延迟的情况，在数据写入后，在从库无法读取到最新数据，会对业务逻辑造成很大的影响。那么，我们如何发现主从延迟对业务有什么延续呢，那就需要人为的制造延迟，将问题暴露出来。

在Mysql的查询优化里有一条经验，在联合查询时，SQL里要把小表放在大表的前面。小表是指数据量少的表。这个经验的原理是什么呢？这就要从Mysql的遍历方式开始说起。

这里的新版本并不是说一行记录会拷贝成多份，记录只存最新的一条，然后之前的版本会各自对应一条undo log，日志里会记录变更内容的原始值。这时会把修改先记录到log buffer，在提交事务时，先把redo log的状态设置为prepare并存入磁盘，然后提交binlog存入磁盘，最后将redo log设置为commit状态存日磁盘。另一个是用于数据库复制，通过将binlog传给其他数据库副本，然后再执行binlog中的sql实现数据的同步，构建出一套高可用的数据库服务。可以查看日志是否开启。

Innodb引擎支持以事务的方式执行SQL，事务包含ACID四个特性，分别是原子性、一致性、隔离性和持久化。

总结一下Mysql Innodb索引相关的知识，索引是以空间换时间的方式来加快查询速度。本质是将查询涉及的字段单独拎出来减少查询的基数和减少磁盘io次数，先做了排序可以用更高效的查询算法。同时索引也有一些弊端，需要占用额外的空间，还不少。数据写入时，维护索引的数据排序，要消耗cpu。随着索引数量增加，查询优化器要评估每个索引的效率，对于用不到的索引的评估时间，影响查询效率。