优化

前言 一问 可以明显看到方案一更直观，但是方案二就没有它的优点了吗？ 二问 采用方案一的写法： 采用方案二的写法： 大家感觉到不同了吗？ 在方案一中，由于i+1的问题，如果我们习惯的写i < arr.

想一下，我们要在一本书里快速找到一篇文章，怎么做呢？就是找到目录，目录上有文章标题和对应页码，根据页码可以快速帮我们找到想要的文章。试想一下，如果没有目录的话你在去查找就很难了，你要从头开始往后查找，

当我们执行一条修改的sql语句时，执行步骤如下图所示： 可以看到在第二步的时候在undo日志中写入了旧值，在五步和第六步分别写入了redo和binlog日志。 那么它们具体如何实现的呢？ 一、redo

一、定义 一组操作要么全部成功，要么全部失败，目的是为了保证数据的最终一致性。 二、特性 原子性：当前事务的操作要么同时成功，要么同时失败。原子性由undo log日志来实现 一致性：使用事务的最终目

一、锁分类 性能上分乐观锁和悲观锁，乐观锁适合读较多的场景，悲观锁适合写较多的场景 粒度上分表锁、页锁（只支持BDB存储引擎）和行锁 操作上分读锁、写锁和意向锁 读锁(共享锁) 针对同一份数据，多个读

我们所写的SQL查询性能要考虑到真实的业务场景，有的SQL在实际生产环境下查询变慢，就要去分析优化他，首选就是采用explain这个mysql自带工具，它非常方便只需要在sql前加上explain关键