weixin_42118323的博客

记录 MySQL 服务器启动和关停服务时候的信息，包括 MySQL 实例在运行中遇到错误、警告等，不仅仅会记录错误、警告信息，还会记录 MySQL 启动InnoDB的表空间文件、如何初始化自己的存储引擎，初始化buffer pool等信息，这里说的错误日志并不会记录我们 SQL 执行时候的发生的错误信息，这里的错误日志记录的基本是 MySQL 自身进程发生的错误，跟就是的 SQL 语句执行错误无关。log_error_verbosity：日志记录等级，对错误日志进行过滤，对应的值分别为 1、2、3。

分析：既然要获取最新的数据，id自增，时间也是顺序的，最新的数据是不是意味这就是 id 或者时间最大的那条数据？最近项目中迭代一个旧的功能，再原有的设计上进行功能拓展（因成本等原因，不考虑项目重构），其中设计到了这么一个场景，同一个业务 ID 在同一张表中有 N 条数据，需要查询出最新的那一条数据。结果显而易见，获取到了最大的那条数据，功能已经实现，但是子查询的效率比较低，我们还有没有更高效的方法呢？很明显还是没有获取到最新的一条数据，该方案仍然不可行，那怎么样才可以实现呢？test 表是主键自增的。

MRR，全称 Multi-Range Read Optimization，直译就是多范围读取优化，可以知道它是对范围读取的优化，MRR 是对索引读取的优化，提高索引的查询性能，原理是充分利用磁盘预读机制，把磁盘随机读取，转换为磁盘顺序读取，查询是否使用 MRR 由MySQL 优化器决定，一般不要强行干预。我们知道MRR 是对索引读取的优化，实际上 MRR 是通过对缓冲区的索引记录排序，把随机读取转换为顺序读取。注意：磁盘旋转速度快，耗时少，寻道速度慢，耗时久。如有不正确的地方请各位指出纠正。

这个时候可能就是索引下推出场的时候，索引下推的精髓就是使用索引列来过滤条件，我们可以暂时抛弃索引的一些命中原则，就假设索引是一张数据表，我们使用条件在索引表中查询主键id，前面说了，假设一个查询只用了联合作用中间的那个字段，就无法使用联合索引，那我么使用了索引下推，就可以过滤一部分数据出来，返回 Server 层的数据会更少，减少了回表次数，提高了查询效率。索引下推(Index Condition Pushdown，简称ICP)，使用索引下推，能够减少回表查询次数，减少 IO次数，提高查询效率。

每一个技术经理，都会要求项目组成员不要使用 select * from，那么使用 select * from 会有什么问题呢？select * from 带来的问题？覆盖索引直接无法使用。增加查询分析器解析成本。增减字段，容易与resultMap 配置不一致。无用字段增加网络消耗、磁盘IO开销。第一条是我自己加上去的，后面是三条是引用阿里巴巴Java开发手册，如下：【强制】在表查询中，一律不要使用 * 作为查询的字段列表，需要哪些字段必须明确写明。说明： 1） 增加查询分析器解析成本。

发现 user_code 为 TC-00000001 的出现了两条数据，我们前面已经创建了 user_code、age 的唯一索引，为什么还会允许出现重复数据呢？难道是唯一索引失效了？对比上面两次 insert 操作，我们发现 user_code 为 TC-00000001 存在一条 age 为 null 的数据，我在一张表里设置了唯一索引，但是我发现还是出现了重复数据，这是什么情况呢，难道唯一索引失效了？很明显唯一索引生效了，也就是说上面的问题，并非是唯一所以失效导致的。

【强制】不要使用 count(列名)或 count(常量)来替代 count()， count()是 SQL92 定义的 标准统计行数的语法，跟数据库无关，跟 NULL 和非 NULL 无关。说明： count(*)会统计值为 NULL 的行，而count(列名)不会统计此列为 NULL 值的行。如果再面试中，你回答会扫描全表，那不好意思，可能面试官只能要你回去等通知了。count（）函数使用小建议：无特殊要求的时候，建议无脑使用 count（*）。列值没有为空的时候，三种查询结果一致。

Read View 是事务执行快照读产生的视图，在事务执行快照读的时候，系统会以当前时刻生成一个快照，以此来维护系统此时活跃的事务id，用来做可见性判断，当某个事务进行快照读的时候，我们根据 Read View 来判断当前事务可以读取哪个版本的数据，然后就去该数据的 undo log 里面找数据，当然也可能是读取最新的数据。MVCC 解决的是读写并发问题，而更新丢失是写写并发问题，MVCC不能解决更新丢失问题，更新丢失依赖数据库的隔离级别来解决。如有不正确的地方请各位指出纠正。注意事务ID 是递增的。

数据库事务是是一个不可分割的数据库操作序列，这些操作要么全部执行，要么全部不执行，是一个不可分割的操作。事务由事务开始与事务结束之间执行的全部数据库操作组成。事务需要满足四大特性，简称ACID，以此来保证数据一致性。如有不正确的地方请各位指出纠正。

结论：in 和 not in 都可以走索引，并非很多资料所说 in查询走索引，not in 查询不走索引，但是还是可以看出来，in 查询可以命中跟多的索引，对应的效率也会高一些，具体是 in 查询还是用 not in 查询要根据实际情况而定，总之就是需要合理设计索引，多看SQL执行计划。我们常说的SQL优化，简单来说就是索引优化，通过合理创建索引，调整SQL语法等，来提升查询效率，想要进行SQL优化，就必须知道索引的原理，而且能够看懂SQL的执行计划。如有不正确的地方请各位指出纠正。

我们常说的SQL优化，简单来说就是索引优化，通过合理创建索引，调整SQL语法等，来提升查询效率，想要进行SQL优化，就必须知道索引的原理，而且能够看懂SQL的执行计划。覆盖索引中包含了全部的的返回字段了，就无需回表查询，只需要扫描覆盖索引树就能到的查询结果，这里要结合覆盖索引的底层数据结构去理解，才会比较容易理解。索引中包含了查询返回列的所有字段，就叫做覆盖索引。如有不正确的地方请各位指出纠正。

总结：最左前缀法则会根据联合索引字段顺序依次去更where 后的筛选条件进行对比，直到出现跳字段为止，比如本案例跳过了age字段，就只能使用 index_name_age_address 索引中的 user_name 字段，where 条件中打乱联合索引的字段顺序是没有问题的，这里就不做演示了，有兴趣的可以去验证一下。我们常说的SQL优化，简单来说就是索引优化，通过合理创建索引，调整SQL语法等，来提升查询效率，想要进行SQL优化，就必须知道索引的原理，而且能够看懂SQL的执行计划。证明隐藏索引生效了。

我们常说的SQL优化，简单来说就是索引优化，通过合理创建索引，调整SQL语法等，来提升查询效率，想要进行SQL优化，就必须知道索引的原理，而且能够看懂SQL的执行计划。总结：同样的SQL在不同的在不同数据的情况下会使用不同的索引，因此我们更要谨慎的设计索引，写完SQL一定要看执行计划。如有不正确的地方请各位指出纠正。

SQL的执行计划，通俗来说就是SQL的执行情况，一条SQL语句扫描哪些表，那个子查询先执行，是否用到了索引等等，只有当我们知道了这些情况之后才知道，才可以更好的去优化SQL，而这个过程MySQL帮助我们生成好了，这就是执行计划。key_len：表示索引使用的字节数，通过这个值可以算出索引使用了哪些列，不同类型的数据在MySQL中占用的字节数如下，供参考。根据对比可以看出explain、desc 都可以看SQL的执行计划。如果字段允许为空，则额外需要一个字节去记录是否为空。如有不正确的地方请各位指出纠正。

如果当某个字段很长，而且查询又很频繁，如果使用全字段索引的话，就会很占空间，这个时候就可以使用前缀索引，有效的缩小了索引文件的大小，可以让一页存放更多的索引，从而提高了查询速度。不一定，如果查询返回的字段全部命中了索引，也就是覆盖索引，这个时候就无需回表查询。如有不正确的地方请各位指出纠正。

隐藏索引功能可以作为一个SQL调优的小技巧，通过隐藏索引用来测试索引的性能，验证索引的必要性，避免了频繁删除新建索引，SQL调优完成，如果不影响性能再真正地删除索引。按索引的存储结构分类，索引可以分为主键索引和二级索引（辅助索引），普通索引、联合索引、覆盖索引都可以理解为二级索引的某一种。PRIMARY KEY，当一张表的某个列是主键的时候，该列就是主键索引，一张表只允许有一个主键索引，主键所在的列不能为空。最基本的索引类型，没有限制，可以为空，可以有多个。也称复合索引，就是在多个列上建立的索引。

索引是什么？索引是帮助MySQL高效获取数据的排好序的数据结构，因此可知索引是数据结构。概念很抽象，但是类比生活中的例子就很容易理解，比如一本厚厚的书，我们想取找某一小节，我们可以根据目录去快速找到对应的章节，其实这个目录就可以叫这本书的索引，而数的目录又分为大章节小章节，如果倒着看是不是很像一棵树呢？常见树的数据结构及特点：二叉树：二叉树是每个节点最多有两个子节点的树结构，通常有左子树和右子树，左右子树是有顺序的，左子树的值要小于父节点，右子树的值要大于父节点。二叉树示意图：极端情况下二插

锁是计算机协调多个进程并发访问贡献资源的一种机制，MySQL数据库的锁机制简单来说，就是数据库为了保证访问共享数据的一致性的一种机制，有锁存在就一定存在锁冲突，锁冲突也是影响数据库并发访问性能的一个重要因素，因此锁对数据库而言显得尤其重要。

在查阅资料寻求解决方案的时候，看到部分资料说。

MySql Group by 数据丢失问题分析