参考来源：康师傅：https://www.bilibili.com/video/BV1iq4y1u7vj?p=149
爱编程的大李子：https://blog.csdn.net/LXYDSF/article/details/126606855
一、EXISTS 和 IN 的区分
不太理解哪种情况下应该使用 EXISTS，哪种情况应该用 IN。选择的标准是看能否使用表的索引吗?
索引是个前提，其实选择与否还是要看表的大小。你可以将选择的标准理解为 小表驱动大表。在这种方式下效率是最高的。
比如下面这样：
# 当 B 小于 A 时用 IN
SELECT * FROM A WHERE cc IN (SELECT cc FROM B)
# 当 A 小于 B 时，用 EXISTS。因为 EXISTS 的实现，相当于外表循环。
SELECT * FROM A WHERE EXISTS (SELECT cc FROM B WHERE B.cc = A.cc)结论：哪个表小就用哪个表来驱动，A 表小就用 EXISTS ，B 表小就用 IN
二、COUNT(*) 与 COUNT(具体字段) 效率
在MySQL中统计数据表的行数，可以使用三种方式 SELECT COUNT(*)、SELECT COUNT(1) 和 SELECT COUNT(具体字段)，使用这三者之间的查询效率是怎样的？
- COUNT() 和 COUNT(1) 都是对所有结果进行 COUNT，COUNT() 和 COUNT(1) 本质上并没有区别
- 在 InnoDB 引擎中，如果采用 COUNT(具体字段) 来统计数据行数，要尽量采用二级索引。因为主键采用的索引是聚簇索引，聚簇索引包含的信息多，明显会大于二级索引。对于 COUNT(*) 和 COUNT(1) 来说，它们不需要查找具体的行，只是统计行数，系统会自动采用占用空间更小的二级索引来进行统计。
如果有多个二级索引，会使用 keylen 小的二级索引进行扫描。当没有二级索引的时候，才会采用主键索引来进行统计。
三、SELECT *
在表查询中，建议明确字段，不要使用 * 作为查询的字段列表，推荐使用 SELECT <字段列表> 查询。原因：
- MySQL 在解析的过程中，会通过 查询数据字典 将 "*" 按序转换成所有列名，这会大大的耗费资源和时间。
- 无法使用 覆盖索引
四、LIMIT 1 对优化的影响
针对的是会扫描全表的SQL语句，如果你可以确定结果集只有一条，那么加上 LIMIT 1 的时候，当找到一条结果的时候就不会继续扫描了，这样会加快查询速度。
如果数据表已经对字段建立了唯一索引，那么可以通过索引进行查询，不会全表扫描的话，就 不需要加上 LIMIT 1 了。
五、多使用COMMIT
只要有可能，在程序中尽量多使用 COMMIT，这样程序的性能得到提高，需求也会因为 COMMIT 所释放的资源而减少。
COMMIT 所释放的资源：
- 回滚段上用于恢复数据的信息
- 被程序语句获得的锁
- redo / undo log buffer 中的空间
- 管理上述 3 种资源中的内部花费
六、普通索引 vs 唯一索引
查询过程
在查询过程中 普通索引 与 唯一索引 带来的性能差距比较小
更新过程：优先考虑普通索引
为了说明普通索引和唯一索引对更新语句性能的影响这个问题，介绍一下 change buffer。
当需要更新一个数据页时，如果数据页在内存中就直接更新，而如果这个数据页还没有在内存中的话， 在不影响数据一致性的前提下，InooDB 会将这些更新操作缓存在 change buffer 中 ，这样就不需要从磁盘中读入这个数据页了。在下次查询需要访问这个数据页的时候，将数据页读入内存，然后执行 change buffer 中与这个页有关的操作。通过这种方式就能保证这个数据逻辑的正确性。
将 change buffer 中的操作应用到原数据页，得到最新结果的过程称为 merge。除了 访问这个数据页 会触发 merge 外，系统有 后台线程会定期 merge。在 数据库正常关闭（shutdown） 的过程中，也会执行 merge 操作。
如果能够将更新操作先记录在 change buffer， 减少读磁盘 ，语句的执行速度会得到明显的提升。而且， 数据读入内存是需要占用 buffer pool 的，所以这种方式还能够 避免占用内存 ，提高内存利用率。
那么，什么条件下可以使用 change buffer 呢？
对干唯一索引来说，所有的更新操作都要先判断这个操作是否违反唯一性约束。比如，要插入 (k, v) value (4, 400) 这个记录，就要先判断现在表中是否已经存在 k=4 的记录，而这必须要将数据页读入内存才能判断。如果都已经读入到内存了，那直接更新内存会更快，就没必要使用 change buffer 了。
因此，唯一索引的更新就不能使用 change buffer，实际上也只有普通索引可以使用。
change buffer 用的是 buffer pool 里的内存，因此不能无限增大。change buffer 的大小，可以通过参数 innodb_change_buffer_max_size 来动态设置。这个参数设置为 50 的时候，表示 changebuffer 的大小最多只能占用 buffer pool 的 50% 。
如果要在这张表中插入一个新记录 (4,400) 的话，InnoDB的处理流程是怎样的？
第一种情况是，这个记录要更新的目标页在内存中。这时：
- 对干唯一索引来说，找到 3 和 5 之间的位置，判断为没有冲突，插入这个值，语句执行结束
- 对于普通索引来说，找到 3 和 5 之间的位置，插入这个值，语句执行结束。
这样看来，普通索引和唯一索引对更新语句性能影响的差别，只是一个判断，只会耗费微小的CPU时间。
第二种情况是，这个记录要更新的目标页不在内存中。这时：
- 对于唯一索引来说，需要将数据页读入内存，判断到没有冲突，插入这个值，语句执行结束;
- 对于普通索引来说，则是将更新记录在 change buffer，语句执行就结束了。
将数据从磁盘读入内存涉及随机 I/O 的访问，是数据库里面成本最高的操作之一。change buffer 因为减少了随机磁盘访问，所以对更新性能的提升是会很明显的。
案例：
某个业务的库内存命中率突然从 99% 降低到了 75%，整个系统处于阻塞状态，更新语句全部堵住。而探究其原因后，发现这个业务有大量插入数据的操作，而他在前一天把其中的某个普通索引改成了唯一索引。
change buffer的使用场景
change buffer 只限于用在普通索引的场景下，而不适用于唯一索引。那么，现在有一个问题就是：普通索引的所有场景，使用 change buffer 都可以起到加速作用吗？
因为 merge 的时候是真正进行数据更新的时刻，而 change buffer 的主要目的就是将记录的变更动作缓存下来，所以在一个数据页做 merge 之前，change buffer 记录的变更越多（也就是这个页面上要更新的次数越多），收益就越大。
因此，对于写多读少的业务来说，页面在写完以后马上被访问到的概率比较小，此时 change buffer 的使用效果最好。这种业务模型常见的就是账单类、日志类的系统。
反过来，假设一个业务的更新模式是写入之后马上会做查询，那么即使满足了条件，将更新先记录在 change buffer，之后由干马上要访问这个数据页，会立即触发 merge 过程，这样随机访问 I/O 的次数不会减少，反而增加了 change buffer 的维护代价。所以，对于这种业务模式来说，change buffer 反而起到了副作用。
- 普通索引和唯一索引应该怎么选择？其实，这两类索引在查询能力上是没差别的，主要考虑的是对 更新性能 的影响。所以，建议你 尽量选择普通索引 。
- 在实际使用中会发现， 普通索引 和 change buffer 的配合使用，对于 数据量大 的表的更新优化还是很明显的。
- 如果所有的更新后面，都马上 伴随着对这个记录的查询，那么你应该关闭 change buffer 。而在其他情况下，change buffer 都能提升更新性能。
由于唯一索引用不上 change buffer 的优化机制，因此如果 业务可以接受 ，从性能角度出发建议优先考虑非唯一索引。但是如果"业务可能无法确保"的情况下，怎么处理呢？
- 首先， 业务正确性优先 。我们的前提是“业务代码已经保证不会写入重复数据”的情况下，讨论性能问题。如果业务不能保证，或者业务就是要求数据库来做约束，那么没得选，必须创建唯一索引。 这种情况下，本节的意义在于，如果碰上了大量插入数据慢、内存命中率低的时候，给你多提供一个排查思路。
- 然后，在一些“归档库”的场景，你是可以考虑使用唯一索引的。比如，线上数据只需要保留半年， 然后历史数据保存在归档库。这时候，归档数据已经是确保没有唯一键冲突了。要提高归档效率， 可以考虑把表里面的唯一索引改成普通索引。
